Nastavit měření zní jednoduše, jako párkrát kliknout a mít hotovo. Realita je ale klikací maraton přes tři různá rozhraní: GA4 Admin, Google Tag Manager a Search Console. Každé má jinou logiku, každé vyžaduje desítky kliknutí. Člověk nad tím stráví čas, snadno na něco zapomene, a hlavně: za měsíc už nikdo netuší, co a proč se nastavilo. Já na to šel úplně jinak. Celé měření jsem postavil z terminálu jako kód a nechal ho nasadit AI agent.
// SECTION_01 // REALITA
Nastavovat tyhle systémy je otrava
Nastavit tyhle systémy je docela otrava. Je to neustálé klikání mezi třemi platformami, každá má vlastní logiku a navíc se pořád mění. Sotva si zvyknete, kde co je, GA4 nebo GTM přehází rozhraní a učíte se to znovu. Ideál není klikat rychleji. Ideál je znát, jak to celé funguje, a mít agenty, kteří to nastavení udělají za vás. A v tom je ta pointa: agenti se postupně učí. Co dnes zabere čas, je příště hotové rychleji, a s každým dalším klientem se to zrychluje.
// SECTION_02 // CO_JSEM_NASTAVIL
Co jsem nastavil
Nastavil jsem kompletní a standardní základ měření:
- GTM kontejner s GA4 a měřením návštěvnosti
- Konverzi z poptávkového formuláře a k ní celý funnel mikro-konverzí (klik na CTA a z které sekce, začátek vyplňování, odeslání)
- Consent Mode v2 a vlastní cookie lištu ve svém designu, kde výchozí stav je nic neměřit
- Search Console s odeslanou sitemapou
U konverze z formuláře neměřím jen počet odeslání, ale sleduji celou cestu uživatele a vidím, kde lidé z procesu odcházejí. Žádná exotika, jen poctivý základ. Zajímavý je ale způsob, jakým to celé vzniklo.
// SECTION_03 // PROC_TERMINAL
Proč z terminálu, a co s tím má AI
Využil jsem toho, že Tag Manager API, GA4 Admin API i Search Console API existují. Místo ručního klikání jsem měření napsal jako kód a nechal AI agenta, aby ho z terminálu vykonal. Já jsem definoval zadání a AI agent poskládal potřebná volání API, ověřil je a nasadil. Přesně tohle je ta páka, díky které dnes jeden člověk zvládne práci za celý tým.
Kód má navíc vlastnosti, které naklikané nastavení nikdy mít nebude:
- Reprodukovatelnost. Nastavení je popsané, na dalším webu ho zopakuju za minuty.
- Verze a kontrola. Každou změnu v GTM jsem publikoval jako verzi, šla zkontrolovat před nasazením a kdykoliv vrátit zpět.
- Rychlost a nula překlepů. Co by bylo sto kliků, je pár volání API.
- Upřímnost. Když někde chybělo oprávnění, API mi přesně řeklo které.
„MĚŘENÍ, KTERÉMU VĚŘÍTE, NAPÍŠETE JAKO KÓD A NASADÍTE Z TERMINÁLU."
// SECTION_04 // OVERENI
Neskončil jsem u „mělo by to fungovat"
Poslední a nejčastěji přeskakovaný krok je ověření, že data opravdu tečou. Přímo na úrovni síťových požadavků jsem zkontroloval, že se konverze i mikro-konverze skutečně odesílají a že před souhlasem web mlčí. Nepotřebuji screenshot z rozhraní, chci vidět důkaz. Spousta měření tiše nefunguje celé měsíce jen proto, že si nikdo nedal práci je pořádně otestovat.
// SECTION_05 // TYPICKE_CHYBY
Co většina dělá špatně
- Nastavení nikdo nezdokumentuje. Když se za půl roku rozbije nebo se mění agentura, nemá to kdo rozklíčovat.
- Cookie lištu řeší jako záplatu na konci. Pak buď zablokuje i data, která šla měřit, nebo naopak nehlídá nic.
- Neověří, že měření reálně funguje. Stačilo by po nasazení poslat testovací konverzi a zkontrolovat, že hit opravdu odešel.
- Optimalizují na obrat místo zisku. V reportu to vypadá skvěle, i když se na tom dá prodělat.
// ZÁVĚR
Měření je inženýrská práce
Měření není políčko, které jednou zaškrtnete a zapomenete na něj. Když stojí na kódu, je konzistentní, přezkoumatelné a v případě potřeby ho rychle opravíte. Díky tomu se pak můžete spolehnout na čísla, podle kterých řídíte výkon a zisk vašeho byznysu. Přesně takhle to dělám u klientů: měření beru jako inženýrskou práci. Když má pevný základ, stojí na pevném základě i vaše rozhodování.