Cíl, princip a pravidla, na kterých se BI tým dohodl na meetingu: jak ověřit, že odeslané eventy do DataLayer / GA4 / Gemius opravdu odpovídají tomu, co uživatel vidí v UI — a jak rozlišit technické selhání robota od skutečné BI chyby, kvůli které je potřeba budit lidi.
BI test musí prokázat, že tři věci dávají dohromady smysl: co uživatel vidí, jaké eventy mají vzniknout, a co bylo skutečně odesláno.
Test musí umět poznat:
Místo pevně zadaného očekávání [DataLayer, GA4, Gemius] robot nejprve detekuje UI evidenci a teprve potom určí, co je správně.
Robot očekává gallery event v odpovídajícím tvaru.
Robot očekává video nebo VPlayer event.
Robot očekává premium article eventy včetně Gemius eventů pro premium stav.
Robot očekává paywall event.
Robot nesmí vyžadovat gallery event. Tohle je hlavní obrana proti false-failům.
Robot rozhoduje na základě tří nezávislých signálů. Když si nesedí, je to chyba — buď v datech, v UI, nebo v BI měření.
Hlavní vstupní stránka domény.
Rubrika / sekce.
Standardní obsah bez paywallu.
Premium článek otevřený premium uživateli.
Premium článek pro nepremium usera.
Článek s vloženou galerií.
Bez galerie — nesmí vyžadovat gallery event.
Vlastní VPlayer instance v článku.
Stejný obsah, jiný UI flow — vyhodnocuje se zvlášť.
// UI evidence — výstup z robota před výběrem očekávaných eventů { hasArticleBody: true, hasPaywall: false, hasPremiumBadge: true, hasGallery: false, hasVideo: true, hasVPlayer: true, isLoggedIn: true, isPremiumUser: true, device: "desktop" }
Robot porovnává tři vrstvy: data → UI → eventy. Když si nesedí, ví, kde začít hledat.
Nejdřív zjistit, jestli je problém v datech, v UI, nebo v BI měření. Bez toho nelze klasifikovat.
premium=falseBI chyba v parametrech eventu. Data i UI sedí — selhal sběr.
Každé pravidlo říká: kdy má event vzniknout, kde, kolikrát a s jakými parametry.
{
logicalEvent: "Premium Article View",
appliesWhen: {
pageType: "article",
isPremiumArticle: true,
isPremiumUser: true
},
sources: {
dataLayer: {
eventName: "premium_article_view",
count: "exactlyOnce",
requiredParams: ["article_id", "page_type", "premium", "user_status"]
},
ga4: {
eventName: "premium_article_view",
count: "exactlyOnce",
requiredParams: ["article_id", "premium", "user_status"]
},
gemius: {
eventName: "premium_article_view",
count: "atLeastOnce"
}
}
}
U důležitých eventů nestačí, že existují — musí vzniknout v očekávaném počtu.
Uživatel kliknul jednou, do GA4 přišly dva eventy. Fail — všechna BI čísla budou nafouknutá.
| Pravidlo | Význam | Použití |
|---|---|---|
| exactlyOnce | Event musí vzniknout přesně jednou. | Page view, subscription click, konkrétní akce |
| atLeastOnce | Event musí vzniknout alespoň jednou. | Měření, kde retry nepřekáží (např. některé Gemius pingy) |
| maxOnce | Event může vzniknout maximálně jednou. | Volitelné eventy bez požadavku na existenci |
| zero | Event nesmí vzniknout vůbec. | Negativní pravidla — gallery na článku bez galerie |
Konkrétní seznam podmínek, kdy zazvoní Slack.
count pravidlo.Bez tohoto rozdělení Slack zarezne a alerty přestanou být užitečné.
Problém, který se dříve nevyskytoval. Příklad: article_view začal chybět na blesk.cz/article/123, v předchozích bězích byl v pořádku.
→ Do Slacku jako nový incident.
Příklad: Gemius event stále chybí na premium článcích. Poprvé detekováno 2026-05-20, počet opakování 4.
→ Bez nového incidentu — jen označit jako opakovaný problém.
Doporučený formát — všechno, co BI tým potřebuje, aby chybu okamžitě zařadil.
premium_article_view should be sent once.Identifikuje, kde a v jakém kontextu chyba vznikla.
Co konkrétně se stalo — missing / duplicate / param mismatch.
DataLayer / GA4 / Gemius — kde to selhalo.
Strukturovaně, ne prostý text. Aby šlo strojově porovnat.
Co bylo opravdu na stránce vidět v okamžiku měření.
Pokud je dostupné — pro porovnání data ↔ UI ↔ event.
Timestamp v ISO, časová zóna jednoznačná.
Status pro deduplication a Slack routing.
Klasifikace pro vlastnictví fixu.
Bez tohoto rozdělení BI tým dostane spoustu alertů, které nejsou BI problémy.
Test neproběhl správně. Možné příčiny:
Výsledek: Neoznačovat jako BI chybu. Reportovat jako test/system failure.
Test technicky proběhl, UI bylo zjištěno, ale BI event nesouhlasí. Příklady:
premium=falseVýsledek: Reportovat jako functional BI issue.
UI se může výrazně lišit — hlavně u galerií a videa. Stejné pravidlo na obou viewportech by generovalo falešné chyby.
Galerie může být přímo v článku, video player viditelný okamžitě, hover interakce dostupné.
Galerie může být schovaná, načtená lazy, mít jiný interaction flow. Některé eventy se odesílají později nebo vůbec.
Metodika musí pro každé pravidlo jasně říct, jestli platí pro desktop, mobile, nebo oboje. Bez toho se nedá garantovat smysluplný výsledek.
Premium, VPlayer a galerie jsou tři místa, kde se BI dnes nejčastěji rozchází s realitou.
Co kontrolovat:
premium a user_status parametryCo kontrolovat:
Co kontrolovat:
Pořadí je důležité — bez UI evidence a typu stránky robot neví, co očekávat.
Hodnota přijde dřív než kompletní pokrytí. Tahle minimální množina pokryje nejčastější regrese.
| # | Logické pravidlo |
|---|---|
| 1 | Article View |
| 2 | Premium Article View |
| 3 | Paywall View |
| 4 | Gallery View |
| 5 | Video / VPlayer Impression |
| 6 | Subscription Click |
| 7 | Login Success |
| 8 | Page View |
| # | Typ stránky |
|---|---|
| 1 | Standard article |
| 2 | Premium unlocked article |
| 3 | Premium locked article |
| 4 | Article with gallery |
| 5 | Article without gallery |
| 6 | Article with VPlayer |
| 7 | Category page |
| 8 | Homepage |
Tohle je text, který může jít ven beze změny.
BI Measurement Validation Methodology
The BI validation robot dynamically evaluates whether analytics events match the actual UI state of the tested page.
The test does not only check whether a configured event exists. It first identifies the page type, visible UI components, article metadata, user state, device type, and consent state. Based on this evidence, it determines which BI events are expected in DataLayer, GA4, and Gemius.
Each expected event can define required sources, required parameters, expected values, count rules, and UI conditions. The system reports missing events, duplicated events, incorrect parameters, and mismatches between UI state and analytics state.
Failures are classified into two groups:
Slack alerts are sent only for relevant BI issues and are grouped into new and repeated issues.
BI testy budou dynamicky kontrolovat, zda analytické eventy odpovídají tomu, co uživatel skutečně vidí na stránce.
Robot nejdříve rozpozná typ stránky, typ článku, UI prvky, stav uživatele, device a article metadata. Poté podle pravidel určí, jaké eventy mají vzniknout v DataLayer, GA4 a Gemius.
Systém bude hlásit chybějící eventy, duplicitní eventy, špatné parametry a nesoulad mezi UI a BI měřením. Alerty do Slacku budou rozdělené na nové a opakované chyby a zároveň na technická selhání robota a skutečné BI chyby.
Tohle je formát, který se dá rovnou předat implementaci a zároveň ho BI tým schvaluje řádek po řádku.
| Page type | UI condition | DataLayer | GA4 | Gemius | Count | Device | Notes |
|---|---|---|---|---|---|---|---|
| Premium article | premium badge visible + premium user logged in | premium_article_view | premium_article_view | premium_article_view | exactlyOnce | desktop / mobile | Validate Gemius |
| Article with VPlayer | video player visible | video_impression | video_impression | video_impression | atLeastOnce | desktop / mobile | Include VPlayer |
| Article without gallery | no gallery visible | no gallery_view required | no gallery_view required | no gallery_view required | zero · ignored | desktop / mobile | Prevent false fail |
| Article with gallery | gallery visible | gallery_view | gallery_view | optional / defined | exactlyOnce | desktop / mobile | Mobile differs |
Až bude tato tabulka odsouhlasena, je to nejlepší základ pro implementaci i pro dohodu s BI týmem o tom, co bude robot měřit jako první.