Očekávaný stav a jak číst rozdíly

Nahraná cesta 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ě. Založí se automaticky; dokud není hotový, je v detailu testu 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 nahrané stránce,
• 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.

Události, které se objevují jen občas, upozornění nespouštějí.

Když několik skenů po sobě tyhle podmínky nesplní, upozornění se změní na „Monitoring této cesty neběží“ a napíše, co je potřeba udělat. Obvykle nahrát cestu znovu 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 mají 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í. Cesta 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í

Barva změny je její závažnost. Červeně jsou kritické změny, typicky „Událost odebrána“ a „Změna souhlasu“: web přestal dělat to, co očekávaný stav předepisuje. Oranžově jsou varování, která je potřeba posoudit, například „Parametr odebrán“, „Změna typu“ nebo „Událost přidána“. Bíle je jen informace, například „Parametr přidán“. „Krok neověřen“ a „Souhlas nepřečten“ znamenají, že jsme nemohli měřit. Barvu mají podle závažnosti jako ostatní změny, o vašem webu ale nic neříkají.

Posunuté 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 proto vůbec nehlásí. Její parametry a souhlas se ale porovnávají dál a případnou změnu sken ukáže u kroku, kam událost řadí očekávaný stav. Totéž platí, když se o krok posune celá řada stejných událostí v po sobě jdoucích krocích. Událost, která se posunula o víc než jeden krok, sken hlásí jako „Událost posunuta“. Je to varování, takže u sledovaného nástroje může spustit upozornění jako kterákoli jiná změna.

Na povinné události purchase, begin_checkout, add_payment_info, consent_update, consent_default se tolerance nevztahuje. Když je vlastní měření webu (dataLayer, adobeDataLayer, 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í. Výjimkou je nákup v Adobe Analytics: požadavek do Adobe Analytics, jehož úspěšné události (success events) obsahují purchase, se počítá také jako povinný nákup.

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í

Zachycená data všech nástrojů zůstávají vidět v záložkách kroku. Změny vypisujeme a upozorňujeme na ně jen u nástrojů, které sledujete. Každý test ve výchozím stavu sleduje dataLayer, adobeDataLayer, Google Analytics 4, Adobe Analytics, každý jen pokud ho web používá. U mobilní aplikace k nim patří i její vlastní kontejner Google Tag Manager. Ve „Sledovaných nástrojích“ můžete jakýkoli nástroj zapnout i vypnout, včetně dataLayer; znovu zapnutý nástroj se sleduje od té chvíle. U nástroje s poznámkou „Může hlásit falešné změny“ zatím neproběhla naše kontrola šumu. Kontrola pull requestu na tomto seznamu nezávisí.

Co udělají tlačítka u změny

• „Správně“ zapíše změnu do očekávaného stavu tak, jak je teď. Přidaná událost nebo parametr se stane povinným, takže jeho pozdější výpadek se nahlásí; chybějící se z očekávaného stavu odebere. 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.
• „Může chybět“ u přidané nebo chybějící události či parametru ho zapíše jako volitelný: jeho přítomnost ani nepřítomnost se už nehlásí, ale typ se kontroluje dál, kdykoli se objeví.
• „Ignorovat“ změnu přestane hlásit. Ignorování celé události platí i pro její budoucí parametry.
• „Je to chyba“ nechá změnu vést jako „Známá regrese“, dokud ji některý další sken nepřestane nacházet.

Co tlačítko udělá, uvidíte po najetí myší nebo po přechodu klávesou Tab.

Proč první očekávaný stav musí zkontrolovat člověk

Očekávaný stav se zapíše z prvních použitelných skenů přesně tak, jak je skeny naměřily. 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 skeny, ze kterých se očekávaný stav založil, a projděte je krok po kroku:

• jsou v krocích události, které tam patří, například purchase v kroku s potvrzením objednávky,
• mají klíčové parametry správný typ, například value jako čí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 „Správně“. Nejvíc proto získáte, když je měření v pořádku už před prvním skenem.