O tom, proč se konverze cestou z prohlížeče ztrácejí, jsem tu už psal. Tenhle text je o patro níž: jak měření skutečně stavím, když má být podkladem pro řízení kampaní podle zisku. Co se posílá, odkud, jak se to deduplikuje, jak do toho zapadá souhlas a podle čeho poznám, že čísla sedí. Technické je na tom všechno kromě rozhodnutí, která zůstávají na marketingu.
// SECTION_01 // TRI_UROVNE
Tři úrovně měření a co která ještě unese
Pojem „server-side" se používá pro dvě dost odlišné věci a rozdíl mezi nimi rozhoduje o tom, jestli se dostanete k úplným datům, nebo jen k čistším.
| ÚROVEŇ | ODKUD ODCHÁZÍ UDÁLOST | KDE NARAZÍ |
|---|---|---|
| Tag v prohlížeči | Skript na děkovací stránce | Blokátory, Safari, zavřený tab, redirect z platební brány |
| Server-side GTM | Váš kontejner, ale spouští ho pořád tag z prohlížeče | Když se stránka nenačte, událost nevznikne |
| Měření z backendu | Objednávkový systém e-shopu | Potřebuje vývoj a uložené identifikátory kliku |
Server-side GTM je dobrý krok. Zpřehlední, co odchází ven, prodlouží životnost cookies a ubere práci prohlížeči. Jenom nevyřeší ten hlavní problém: pořád čeká, až se v prohlížeči něco stane. Objednávka přitom v tu chvíli existuje v databázi e-shopu bez ohledu na to, jestli zákazník dokoukal děkovací stránku.
OBJEDNÁVKA VZNIKÁ V DATABÁZI E-SHOPU. VŠECHNO OSTATNÍ JE JENOM DOHAD, ŽE SE TO STALO.
Doména rozhoduje o tom, jak dlouho vám vydrží cookie
Pokud server-side GTM nasadíte, tak jedině s vlastní doménou na stejném kořeni jako web, třeba ss.vasobchod.cz. Bez ní z toho máte přesměrovaný provoz a nic navíc. Důvod je v tom, jak Safari zachází s cookies, a čísla jsou nemilosrdná.
Past: výchozí adresa hostingu měřicího serveru se skoro nikdy netrefí do stejné podsítě jako váš web. Safari to vyhodnotí jako maskovanou doménu a ustřihne cookie na sedm dní, i když technicky odchází ze serveru. Nejspolehlivější je proto obsluhovat měření na cestě přímo pod hlavní doménou, tedy vasobchod.cz/mereni, kde tahle otázka odpadá.
Sedmidenní okno zní nevinně, ale u zboží, kde se lidé rozmýšlejí dva týdny, znamená, že polovina cesty k nákupu zmizí. A protože sedmidenní cookie je pořád cookie, chová se to navenek jako fungující měření: data chodí, jen jsou nekompletní tak, aby si toho nikdo nevšiml.
// SECTION_02 // ZKRESLENI
Nejde o to, že dat je míň. Jde o to, která chybí
Kdyby se ztrácela náhodná pětina objednávek, dalo by se s tím žít a dopočítat to. Jenže ztráty nejsou náhodné. Systematicky chybí lidé na Safari, lidé s blokátory, platby, které se vracejí přes bránu, a mobilní nákupy dokončené v aplikaci banky. To je konkrétní řez vašimi zákazníky.
Algoritmus se pak učí, že tihle lidé nekonvertují, a přestává na ně sázet. Chyba v měření se tím přelije do nákupu médií a začne se sama potvrzovat. Proto beru měření z backendu jako předpoklad, ne jako vylepšení: bez něj nemá smysl řešit ani cíle, ani segmentaci.
// SECTION_03 // ARCHITEKTURA
Jak to stavím
Kritický je krok 1. Bez uloženého identifikátoru kliku nemá platforma jak objednávku spojit s reklamou a máte přesná data, která nikdo neumí přiřadit.
Identifikátor kliku ukládám hned při vstupu na web, ne až v košíku. Cesta k objednávce často vede přes několik návštěv a mezitím se parametr z adresy dávno ztratí. Cookie musí být first-party a nastavená ze serveru, jinak jí Safari ustřihne životnost na sedm dní.
Samotné odeslání dělám z backendu e-shopu po zaplacení nebo po přijetí objednávky, podle toho, co u daného klienta znamená obchod. Když má e-shop vysoký podíl nezaplacených objednávek na dobírku, posílám až po expedici a rozdíl si hlídám v reportu.
// SECTION_04 // CO_SE_POSILA
Co v té události musí být
Položky objednávky jsou to, na čem stojí segmentace produktů podle zisku. Bez nich víte, kolik objednávka vydělala, ale ne na čem.
Hodnotu posílám dvakrát: jednou jako tržbu, jednou jako hrubý zisk, a to jako dvě samostatné konverzní akce. Díky tomu se dá bidding přepnout na zisk a přitom neztratíte historii obratu, na kterou je klient zvyklý v reportech.
Osobní údaje jen v hashi, a ve správném tvaru
E-mail a telefon do reklamního systému neposílám v čitelné podobě. Hashuju je na svojí straně, obvykle SHA-256, a teprve hash odchází ven. Tomu se říká rozšířené konverze a je to dneska hlavní způsob, jak spárovat objednávku se zákazníkem, kterému mezitím vypršela cookie.
- Normalizace před hashem — malá písmena, oříznuté mezery; jinak se stejný e-mail rozpadne na dva různé otisky
- Telefon v mezinárodním tvaru — bez mezer a bez závorek, s předvolbou: 420777123456
- Jméno, příjmení, PSČ a země — bez nich je párování výrazně slabší, právě tahle čtveřice se doplňuje k hashi
- Bez souhlasu se neposílá nic z toho — ani hash, protože hash pořád identifikuje konkrétního člověka
- Jen jednou — když už rozšířené konverze posíláte z prohlížeče, neposílejte je zároveň ze serveru na stejnou akci
// SECTION_05 // DEDUPLIKACE
Deduplikace: jedna objednávka, jedna konverze
Ve chvíli, kdy vedle sebe běží měření z prohlížeče i ze serveru, hrozí, že se objednávka započítá dvakrát. Nafouknutá čísla jsou horší než chybějící, protože vypadají jako úspěch.
- ID objednávky posílám vždycky a jako klíč používám to samé v každé platformě, ať se dá porovnávat
- V GA4 hlídám transaction_id, které deduplikuje nákupy uvnitř zvoleného okna
- U Google Ads spoléhám na ID transakce v konverzi; při importu offline konverzí musí sedět s tím, co odešlo online
- U Mety se páruje event_id mezi pixelem a Conversions API, jinak se událost počítá dvakrát
- Nejjistější varianta je posílat nákup výhradně ze serveru a v prohlížeči ho vypnout úplně; míň pohyblivých dílů, míň překvapení
// SECTION_06 // SOUHLAS
Souhlas se tím neobchází
Tohle si potřebuju říct natvrdo, protože se to pravidelně plete: přesun měření na server není způsob, jak obejít cookie lištu. Pravidla se řídí tím, jaká data zpracováváte a k čemu, ne tím, ze kterého počítače odejdou. Když návštěvník odmítne marketingové cookies, neposílám identifikátory ani osobní údaje a je jedno, odkud by odcházely.
Co server-side měření reálně přináší, je spolehlivost u lidí, kteří souhlas dali. Právě u nich se dneska ztrácí nejvíc dat kvůli technice, ne kvůli právu. Zbytek řeším Consent Mode v2: bez souhlasu odchází jen anonymní signál bez identifikátorů a Google si chybějící konverze dopočítá modelováním. U klientů to nastavuju tak, že výchozí stav neměří nic a teprve souhlas otevírá jednotlivé kategorie.
Consent Mode přitom umí dva režimy a rozdíl mezi nimi stojí peníze. V základním se měřicí kód bez souhlasu vůbec nespustí, takže o odmítnuvších návštěvnících nevíte nic a Google nemá z čeho modelovat. V pokročilém se kód spustí vždycky, ale bez souhlasu odesílá jen anonymní signál bez jakéhokoliv identifikátoru: že se něco stalo, přibližně odkud a na jaké stránce. Z těchhle signálů pak Google dopočítá chybějící konverze podle chování lidí, kteří souhlas dali.
V účtech, kde odmítne souhlas většina lidí, je ten rozdíl v reportovaných konverzích v řádu desítek procent. Proto u klientů v Evropě volím pokročilý režim: základní vám tiše zahodí data o návštěvnících, které jste už zaplatili.
// SECTION_07 // VRATKY
Vratky, storna a doplatky
Objednávka není konečný stav. Část se stornuje, část se vrátí, u dobírek část nikdo nevyzvedne. Pokud se do reklamního systému hlásí jen vznik objednávky, algoritmus se učí na penězích, které jste nikdy neviděli. U módy nebo elektroniky, kde se vrací klidně pětina zboží, to není detail.
Řeším to úpravou hodnoty konverze zpětně, přes ID objednávky. Google Ads na to má dva různé zásahy a je docela zásadní vybrat správný.
Praktický důsledek: pokud do konverzí neposíláte ID objednávky, opravy jsou u části provozu nemožné. Proto ho posílám vždycky, i když ho zrovna k ničemu jinému nepotřebuju.
U produktů s vysokou vratkovostí navíc počítám s očekávanou mírou vrácení už v hrubém zisku, aby bidding nejel měsíc na číslech, která se za tři týdny propadnou. U módy to běžně znamená ponížení hodnoty o pětinu ještě předtím, než se první balík vrátí.
// SECTION_08 // OBJEM_A_ZPOZDENI
Než na tom postavíte bidding: objem dat a zpoždění
Přesná data ještě nejsou data, na kterých se dá optimalizovat. Než přepnu kampaně na ziskovou konverzi, chci vidět aspoň sto konverzí s hodnotou zisku, ideálně víc. Pod tou hranicí algoritmus nemá z čeho odhadnout, které kliky vedou k ziskovým objednávkám, a chová se, jako by mu chyběl signál — protože mu chybí.
Druhá věc, se kterou se počítá málokdy, je zpoždění. Konverze poslané ze serveru se v účtu nezobrazí okamžitě: zpracování obvykle trvá do dvanácti hodin a u identifikátorů z iOS klidně tři dny. Když v pondělí ráno hodnotíte víkend, díváte se na neúplná čísla a snadno vypnete něco, co ve skutečnosti fungovalo.
- 2 až 4 týdny sběru, než začnu podle zisku řídit; do té doby ho jen sleduju vedle obratu
- Kontrola na objednávkách během té doby, ne až po přepnutí
- Hodnocení po týdnech, ne po dnech, dokud se zpoždění nesrovná
- Přechod po krocích — cíl snižuju postupně během několika dní, ne skokem; podrobně to popisuju v článku o POAS
// SECTION_09 // OVEROVANI
Jak si ověřuju, že to sedí
Měření, které nikdo nekontroluje, se rozbije potichu. Nejčastěji při aktualizaci šablony e-shopu nebo výměně platební brány, a přijde se na to za měsíc podle propadu výkonu.
Denní kontrolu řeším skriptem, který porovná objednávky v databázi s tím, co dorazilo do GA4, a když rozdíl přeleze práh, pošle upozornění. Levnější než ztracený měsíc.
Před nasazením vždycky projedu pár testovacích objednávek celou cestou a podívám se na ně v ladicím režimu: dorazila událost, sedí hodnota, sedí zisk, přiřadil se klik. Teprve pak se přepíná bidding. Stejnou logiku používám i u měření jako kódu, kde je celý setup verzovaný a dá se vrátit zpátky.
// SECTION_10 // KDY_STACI_MENE
Kdy tohle všechno nepotřebujete
Kompletní vlastní pipeline dává smysl od určité velikosti. U menších e-shopů volím levnější patra: hotový modul pro danou platformu, který objednávky posílá ze serveru, nebo server-side GTM jako mezikrok. Pořadí, ve kterém to řeším, je pořád stejné.
- Nejdřív úplnost — ať se měří všechny objednávky, i kdyby zatím bez zisku
- Pak identita — uložený identifikátor kliku a rozlišení nového zákazníka proti databázi
- Potom hodnota — nákladová data a hrubý zisk u objednávky
- Nakonec bidding — přepnutí kampaní na zisk, teprve když předchozí tři body sedí
Většina účtů, které přebírám, má tohle pořadí obrácené: nejdřív chytrý bidding, potom možná někdy měření. Vypadá to jako zkratka, ale je to nejdražší cesta, protože platíte za rozhodnutí, která algoritmus dělá na děravých datech.