Práce s cestami
Očekávaný stav a jak číst rozdíly
Nahraná journey se při každém skenu přehraje a skener zapíše, co se v každém kroku poslalo do dataLayer a analytickým nástrojům. Samo o sobě to nic neříká. Užitečné to začne být až ve chvíli, kdy je s čím porovnávat. Tím měřítkem je očekávaný stav: záznam toho, jaké události a parametry má který krok posílat.
Tenhle návod vysvětluje, jak očekávaný stav vzniká, co se s ním porovnává a co ne, a co udělá kliknutí u nalezené změny.
Jak vzniká očekávaný stav
Očekávaný stav se nepíše ručně. Vezme se z prvního skenu, kterému se dá věřit. Než takový sken přijde, běží zahřívací fáze a v detailu testu je vidět tohle upozornění:

Sken je pro založení použitelný, když:
- skončil ve stavu „Dokončeno“,
- prošel všechny nahrané kroky a žádný z nich neselhal ani nebyl přeskočen,
- každý krok skončil na stránce, která je nahraná, ne jinde,
- každý cíl našel podle vaší nahrávky, tedy nahraným nebo záložním selektorem, a ne podle textu, souřadnic nebo náhradního prvku, který si přehrání odvodilo samo,
- u žádného kroku nečeká návrh opravy,
- aspoň polovina kroků naměřila aspoň nějaké analytické události.
Z prvního takového skenu se očekávaný stav zapíše, jak je. Tenhle sken sám žádné změny nehlásí, protože se stává měřítkem. Porovnávat se začne až od dalšího skenu.
Když několik skenů po sobě tyhle podmínky nesplní, upozornění se změní na „Monitoring této journey neběží“ a napíše, co je potřeba udělat. Obvykle přenahrát journey nebo zjistit, proč přehrávání nedojede do konce.
Co se porovnává
Pro každý krok skener porovná tři věci: jestli přišly stejné události, jestli nesou stejné parametry a jestli má každý parametr stejný typ v JavaScriptu (text, číslo, true/false, pole, objekt). Vnořené objekty se porovnávají po jednotlivých položkách, třeba ecommerce.items[].price.
Hodnoty se neporovnávají. Journey při každém průchodu klidně přidá do košíku jiný produkt, takže item_id i price se mění, a to je v pořádku. Změna z 1290 na 990 proto nic nehlásí. Když ale value místo čísla přijde jako text "990", je to změna typu.
Dvě upřesnění. Prázdná hodnota (null, undefined, prázdný text) se nebere jako typ, takže přechod do ní ani z ní se nehlásí. A u požadavků na servery nástrojů skener vynechává parametry, které se mění při každém načtení, jako časová razítka nebo náhodné identifikátory. Z pushů do dataLayer vynechává jen vlastní události a klíče Google Tag Manageru (gtm.*) a pushe bez názvu události, například volání pro souhlas nebo konfiguraci.
Výjimka: hodnoty souhlasu
U souhlasu hodnota rozhoduje. Skener čte signály Google Consent Mode (adStorage, analyticsStorage, adUserData, adPersonalization) z parametrů gcs a gcd, které posílají tagy Googlu, a porovná je s očekávaným stavem. Když se v kroku, kde byl signál granted, objeví denied (nebo naopak), sken to nahlásí jako „Změna souhlasu“.
Očekávané hodnoty souhlasu se vedou zvlášť pro každou zemi, ze které sken běží. Když skenujete z nové země, první použitelný sken z ní hodnoty souhlasu teprve zapíše. Pokud skener hodnotu přečíst nedokáže, nahlásí „Souhlas nepřečten“. To je selhání měření, ne chyba vašeho webu.
Jaké rozdíly sken hlásí
| V dashboardu | Hodnota v API |
|---|---|
| Událost odebrána | missing_event |
| Událost přidána | extra_event |
| Parametr odebrán | missing_param |
| Parametr přidán | extra_param |
| Změna typu | param_type_changed |
| Událost posunuta | event_drifted |
| Změna souhlasu | consent_value_changed |
| Souhlas nepřečten | consent_unreadable |
| Krok neověřen | step_not_reached |
Červeně jsou označené jen dva typy: „Událost odebrána“ a „Změna souhlasu“. V obou případech web přestal dělat to, co očekávaný stav tvrdí. Ostatní změny jsou upozornění, které je potřeba posoudit. „Parametr přidán“ je jen informace. „Krok neověřen“ a „Souhlas nepřečten“ znamenají, že jsme nemohli měřit, a nic neříkají o vašem webu.

Posun o krok a povinné události
Událost patří ke kroku, během kterého přišla. Pomalý tag se proto občas ozve až v dalším kroku. Aby z toho nevznikla dvojice „odebrána“ a „přidána“, platí tolerance ±1 krok. Událost, která přišla o krok vedle, se hlásí jako „Událost posunuta“.
Na povinné události purchase, begin_checkout, add_payment_info, consent_update, consent_default se tolerance nevztahuje. Když je vlastní měření webu (dataLayer, Google Analytics 4, Google Tag Manager) nepošle ve svém kroku, sken je nahlásí jako „Událost odebrána“, ne jako posunuté. Stejně pojmenované události, které posílají jiné nástroje samy od sebe, pod toto pravidlo nespadají.
Když se krok při přehrávání nedokončí, chybějící události v něm se webu nepřičítají. Sken místo nich ukáže jeden řádek „Krok neověřen“.
Které nástroje se hlídají
Změny se hlásí jen u sledovaných nástrojů. Ve výchozím nastavení je to dataLayer, Google Analytics 4 a Adobe Analytics. Další nástroje zapnete v nastavení „Sledované nástroje“. Nově zachycený nástroj se tam objeví v sekci „Nově detekováno — rozhodněte“. DataLayer se sleduje vždy.
Co udělají tlačítka u změny
- „Označit jako správné“ zapíše změnu do očekávaného stavu. Chybějící nebo přebývající událost či parametr se zapíše jako volitelný: jeho přítomnost ani nepřítomnost se pak už nehlásí, ale typ se kontroluje dál, kdykoli se objeví. Změna typu zapíše nový typ, změna souhlasu novou hodnotu a posunutá událost se přesune do kroku, kde se objevila. „Schválit vše“ udělá totéž pro všechny čekající změny: v panelu změn kroku pro daný krok, v liště skenu pro celý sken.
- „Ignorovat“ změnu přestane hlásit. Ignorování celé události platí i pro její budoucí parametry.
- „Označit jako chybu“ nechá změnu vést jako „Známá regrese“, dokud ji některý další sken nepřestane nacházet.
Proč první očekávaný stav musí zkontrolovat člověk
Očekávaný stav se zapíše z prvního použitelného skenu přesně tak, jak ho sken naměřil. Skener neví, jak má vaše měření vypadat. Ví jen, jak vypadalo tehdy. Pokud web už v tu chvíli posílal value jako text, v potvrzení objednávky chyběl purchase nebo byl signál souhlasu granted dřív, než měl, stane se z toho očekávaný stav. Další skeny pak hlásí jen odchylky od chyby, ne chybu samotnou.
Proto po skončení zahřívací fáze otevřete sken, ze kterého se očekávaný stav založil, a projděte krok po kroku:
- jsou v krocích události, které tam patří, například
purchasev kroku s potvrzením objednávky, - mají klíčové parametry správný typ, například
valuejako číslo, - odpovídají signály souhlasu tomu, co návštěvník v tu chvíli na liště zvolil.
Když něco nesedí, opravte web. Další sken opravu ukáže jako změnu a vy ji zapíšete tlačítkem „Označit jako správné“. Jen počítejte s tím, že událost nebo parametr, který přibyl, se schválením zapíše jako volitelný a jeho pozdější výpadek se hlásit nebude. Nejvíc proto získáte, když je měření v pořádku už před prvním skenem.