Jak měřím sám sebe: od kliku po podepsanou zakázku

Klientům roky říkám, že se marketing nedá řídit bez pořádných dat. Pak jsem se jednou podíval na vlastní web a zjistil, že o něm vím míň než o jejich e-shopech. Věděl jsem, kolik lidí přišlo. Nevěděl jsem, který článek je přiměl se ozvat, ani kolik mi ta poptávka nakonec vydělala. Tak jsem si postavil celý řetěz od reklamního kliku po podepsanou zakázku. Tady je, co jsem nastavoval, proč zrovna takhle, kde mě systémy zastavily a co z toho reálně mám.

// ŘETĚZ MĚŘENÍ 04 BODY

1. 01KlikIdentifikátor reklamy do cookie ze serveru, platnost 90 dní
2. 02PoptávkaUloží se ID, hashe a odkud člověk přišel
3. 03KvalifikaceUdálost do GA4 ze serveru, ne z prohlížeče
4. 04ZakázkaSkutečná hodnota zpátky do Google Ads

Můžu o měření napsat deset článků, ale dokud si celý řetěz sám nepostavím, jsou to poučky z dokumentace. Chtěl jsem narazit na ty samé zdi, na které narazí klientův vývojář, a mít na to odpověď dřív, než se zeptá.

Ukázalo se, že služby jsou na učení lepší poligon než e-shop. U e-shopu objednávka vznikne a hodnota je hned známá. U mě přijde poptávka, pak schůzka, pak nabídka a teprve za tři týdny se ukáže, jestli z toho něco je — a kolik. Tím jsem se musel poprat přesně s tou částí, kterou e-shop obejde: jak dostat hodnotu do systému zpětně, když už dávno nikdo nesedí u počítače.

MĚŘENÍ SE NELÁME V OKAMŽIKU KLIKU. LÁME SE VE CHVÍLI, KDY SE UKÁŽE, KOLIK TO VYDĚLALO.

Když někdo přijde z reklamy, má v adrese identifikátor kliku. U Googlu gclid, na iOS wbraid nebo gbraid, u Skliku sznaiid, u Mety fbclid. Je to lístek s pořadovým číslem té jedné návštěvy — nic o člověku, jen odkaz na konkrétní klik.

Ten lístek si musím schovat, protože v době, kdy mi člověk napíše, už dávno není v adrese. A tady je první místo, kde se to většině lidí rozbije: uloží ho JavaScriptem. Safari takové cookie ustřihne na sedm dní. U služeb, kde se lidé rozmýšlejí týdny, tím ztratíte polovinu cesty a nic nepoznáte, protože data pořád chodí — jen nekompletní.

FIG_01 // ŽIVOTNOST COOKIESAFARI

Cookie z JavaScriptu7 dní

Cookie ze serveru na cizí doméně7 dní

Cookie ze serveru pod vlastní doménouaž 400 dní

Moje řešení: drobný skript přečte identifikátor z adresy a pošle ho na endpoint pod stejnou doménou. Ten ho zapíše hlavičkou Set-Cookie — tedy ze serveru, ne z prohlížeče. Platnost 90 dní, protože delší stejně nemá smysl: konverzní okno Googlu je taky 90 dní.

Ukládám první i poslední dotek. Poslední proto, že ke konverzi se posílá klik aktuální v době poptávky. První proto, že mi říká, co člověka přivedlo — a to bývá něco úplně jiného. Když někoho přivede článek o měření a poptávku pak odešle po kliku na brandovou reklamu, podle posledního kliku bych si myslel, že vydělávám na brandu. Ve skutečnosti brand jen sklidil to, co vypěstoval obsah.

Celé se to spouští až po souhlasu s marketingovými cookies. Parametry si skript přečte hned při načtení stránky a drží si je v paměti — kdyby čekal, byly by pryč, protože člověk mezitím proklikne dál. Když souhlas nepřijde, nevznikne žádná cookie a žádný záznam.

Formulář na webu neposílá jen e-mail. Při odeslání se k poptávce přilepí identifikátor kliku z cookie, stav souhlasu a jednorázové ID události. Server z toho udělá jeden řádek v souboru, který leží mimo webroot — z internetu se k němu nedá dostat.

FIG_02 // CO SE UKLÁDÁ A CO NEZÁMĚRNÁ ASYMETRIE

Do souboru jde

ID poptávky a čas+

Jméno a e-mail+

Otisk e-mailu a telefonu+

První a poslední klik+

Stav souhlasu+

Zůstává jen v mailu

Text poptávky−

Telefon čitelně−

Cokoliv, co člověk napsal navíc−

Po 400 dnech se ze záznamu smaže i jméno, e-mail a identifikátory. Zůstane holá statistika.

Proč to dělím: co v souboru není, to nemůže uniknout. Text poptávky bývá to nejcitlivější, co mi lidé pošlou — rozpočty, problémy ve firmě, spory s dodavatelem. K měření ho nepotřebuju ani náhodou.

E-mail a telefon se ukládají i jako nevratný otisk, tedy SHA-256 po normalizaci. Reklamní systémy s ním umí spárovat člověka, kterému mezitím vypršela cookie, ale zpátky z něj kontakt nikdo nepřečte. Důležitý detail: normalizace musí proběhnout před hashováním. Malá písmena, oříznuté mezery, telefon v mezinárodním tvaru bez mezer. Jinak vám ten samý člověk vyjde pokaždé jinak.

A do mailu, který mi chodí, jsem si přidal řádek, který používám nejčastěji ze všeho:

To poslední číslo je budíček. Když se obchod protáhne přes tři měsíce, hodnotu zakázky už ke kliku nepřipíšu — Google ji odmítne, protože je mimo okno. Díky té jedné větě to vidím hned a vím, že u téhle poptávky musím řešit hodnotu dřív.

Konverzi z formuláře měřím ze serveru přes Measurement Protocol. Důvod je prostý: prohlížeč může odejít dřív, než tag odejde, a děkovací stránka se nemusí načíst vůbec. Server o tom, že poptávka vznikla, ví vždycky.

Je tam jedna past, na kterou se dá naletět: Measurement Protocol chce client_id. Když ho nepošlete, GA4 si vyrobí nového anonymního uživatele a vaše konverze se odtrhne od návštěvy, která ji přivedla. Zdroj, kampaň, celá cesta — pryč. Čtu ho proto z cookie _ga a spolu s ním i session_id, aby událost spadla do té správné návštěvy.

Druhá past je v ladění. Ostrý endpoint vrací HTTP 204 i na naprostý nesmysl, takže se tváří, že všechno funguje. Google má vedle něj ladicí endpoint, který místo toho vrátí konkrétní chybu. Udělal jsem si na to ve své správě tlačítko „Ověřit spojení s GA4" a doporučuju to samé komukoliv, kdo tohle staví.

Tohle je část, kterou u lead byznysů skoro nikdo nedělá, a přitom je v ní celá hodnota. Vznik poptávky ještě nic neznamená. Poptávka může být mimo obor, bez rozpočtu, nebo od někoho, kdo si jen sbírá nabídky. Zajímá mě, co se s ní stalo dál.

GA4 má pro to vestavěné události a já jsem zjistil, že přesně odpovídají tomu, jak s poptávkami reálně pracuju. Ve své správě přepnu stav a server pošle událost — se stejným client_id, takže se přiřadí ke stejnému člověku a ke kanálu, který ho přivedl.

FIG_03 // CESTA JEDNÉ POPTÁVKYCO ODEJDE A KDY

DEN 0 generate_lead Odeslaný formulář. Odchází ze serveru hned, bez hodnoty — tu ještě neznám.

DEN 3 qualify_lead Po hovoru přepnu stav na kvalifikovanou. Vím, že je to reálná příležitost.

DEN 21 close_convert_lead Podpis. Doplním částku a odejde konverze s reálnou hodnotou.

Každá událost odejde nejvýš jednou. U poptávky se ukládá, co už bylo odeslané, takže druhé uložení stejného stavu nic nepošle. Bez toho by stačilo dvakrát kliknout na Uložit a máte v datech dvě zakázky místo jedné.

Výsledek: v GA4 nevidím jen kolik poptávek přišlo z kterého zdroje, ale kolik peněz ten zdroj přinesl. To je rozdíl mezi „z organiku chodí nejvíc poptávek" a „z organiku chodí nejvíc poptávek, ale zakázky se rodí z těch pěti z vyhledávání".

Poslední článek řetězu a zároveň ten, kde jsem si nabil nos. Nahrávání konverzí z kliků má Google roky zavedené rozhraní, popsané ve stovkách návodů. Když jsem ho zavolal, přišlo:

Tedy: staré rozhraní je pro nové integrace zavřené. Kdo ho používal dřív, jede dál; kdo začíná teď, musí na Data Manager API. Každý návod, který k tomu na internetu najdete včetně letošních, popisuje cestu, která vám už nefunguje.

Nová cesta funguje dobře, jen jsem musel kombinaci parametrů najít pokusem. Dokumentace ji takhle pohromadě neuvádí, tak ať ji máte:

FIG_04 // CO MUSÍ SEDĚTDATA MANAGER API

operatingAccountúčet, kam konverze patří

loginAccountsprávcovský účet, přes který mám přístup

productDestinationIdčíselné ID konverzní akce, ne její název

Bez loginAccount„caller does not have permission“

A jedna věc navíc: pokud servisní účet, kterým se přihlašujete, má v reklamním účtu roli „jen čtení", API vrátí ACTION_NOT_PERMITTED. Ta chyba nezní jako problém s právy, ale je to přesně on. Stálo mě to půl hodiny a jednu špatnou domněnku, že mám nedostatečně schválený token.

Nahrávání běží u mě lokálně, ne na hostingu. Skript si ze správy vezme zakázky, které mají doplněnou hodnotu a ještě neodešly, pošle je a označí je jako nahrané. Přístupové údaje k reklamnímu API tak nikdy neopustí můj počítač — na sdílený hosting je nedám, protože ten servisní účet má práva ke všem účtům, které spravuju.

Ke každé konverzi posílám ID poptávky jako číslo objednávky. Nepotřebuju ho k ničemu dnes, ale bez něj se konverze nedá zpětně opravit — a to budu potřebovat ve chvíli, kdy zakázka padne nebo se změní její hodnota.

Identifikátor kliku zachytávám ze všech čtyř systémů. Odesílat konverze zpátky umím zatím jen do Googlu — a je poučné, proč.

FIG_05 // POKRYTÍ KANÁLŮSTAV K DNEŠKU

Google Ads klik · měření · konverze s hodnotou hotovo

Meta klik · pixel a události v prohlížeči 2 ze 3

Sklik jen zachycení kliku 1 ze 3

Microsoft Ads jen zachycení kliku 1 ze 3

Zachytávat klik se vyplatí i tam, kam zatím neumíte odesílat. Stojí to minutu práce a až tu druhou půlku dostavíte, máte historii místo prázdna.

U Mety mě zastavila věc, která s technikou nesouvisí. Pixel jsem měl z roku 2015 pověšený přímo na osobním reklamním účtu, ne pod obchodním portfoliem. A token pro Conversions API Meta vydá jen správci portfolia — takže dokud pixel žádné nemá, nemá kdo podmínku splnit. Založit nové portfolio nešlo, limit byl vyčerpaný staršími projekty.

Poučení, které si z toho beru pro klienty: zjistit vlastnictví pixelu dřív, než začnu cokoliv stavět. Pixel pověšený na osobním účtu je časovaná bomba, protože se s ním nedá dělat nic, co Meta váže na portfolio.

U Skliku je překážka jiná a férovější. Jejich nové měření nestojí jen na parametru v adrese, ale na dvou cookies, které zapisuje jejich vlastní skript. Dokumentace to říká natvrdo: skript v prohlížeči je nutný i pro odesílání ze serveru. Takže postup je opačný než u Googlu — nejdřív jejich měření na web, teprve pak server.

Celé tohle měření se chová podle souhlasu a je to napsané tak, aby to bez něj nešlo obejít ani omylem. Přesun měření na server totiž není způsob, jak obejít cookie lištu — pravidla se řídí tím, jaká data zpracovávám a proč, ne tím, ze kterého počítače odejdou.

• Bez marketingového souhlasu nevznikne cookie s identifikátorem kliku a k poptávce se neuloží ani otisk kontaktu
• Bez analytického souhlasu neodejde do GA4 žádná událost, ani ze serveru
• Tagy v prohlížeči mají kontrolu souhlasu vestavěnou, ne dopsanou vlastním kódem — o jedno místo, kde se dá udělat chyba, míň
• Do zásad zpracování jsem doplnil, co si k poptávce ukládám a na jak dlouho; většina webů tohle dělá a nenapíše nikde

Co server-side měření reálně přináší, není víc dat od lidí, kteří souhlas nedali. Je to spolehlivost u těch, kteří ho dali — a právě u nich se dnes nejvíc dat ztrácí kvůli technice, ne kvůli právu.

Nejde o hezčí grafy. Jde o čtyři otázky, na které jsem dřív odpovídal dojmem:

• Který obsah vede k poptávkám. Měřím přečtení článku i klik na tlačítko v něm. Bez toho bych to nezjistil, protože tlačítko odveze člověka na homepage a článek z dat zmizí.
• Co poptávku vytvořilo a co ji jen sklidilo. První a poslední dotek vedle sebe. Tohle rozhoduje, jestli budu sypat peníze do brandu, nebo do obsahu.
• Kolik zakázek se rodí z kterého kanálu. Ne poptávek — zakázek, s částkou.
• Kolik si můžu dovolit dát za poptávku. Až budu mít dvacet poptávek a pár podpisů, spočítám úspěšnost a z ní strop. Do té doby tam mám nulu, protože vymyšlené číslo je horší než žádné.

A jeden vedlejší efekt, který jsem nečekal: ve chvíli, kdy je řetěz hotový, se mění způsob, jakým o vlastním marketingu přemýšlím. Přestal jsem se ptát „kolik lidí přišlo na článek" a začal se ptát „kolik ten článek vydělal". Přesně tenhle posun se snažím vysvětlit klientům a je docela pikantní, že jsem si ho musel projít sám.

• Vlastnictví účtů řešit první. Pixel na osobním účtu a vyčerpaný limit portfolií mě zastavily až uprostřed práce. Deset minut kontroly na začátku by to odhalilo.
• Nevěřit textu chybové hlášky. „Nemáte oprávnění" u Googlu neznamenalo problém s tokenem, ale roli servisního účtu. Kód chyby říká pravdu, text mate.
• Ladicí endpoint používat od začátku. Ostrý vrací 204 na cokoliv. Kdybych ověřování postavil dřív, ušetřím si dvě slepé uličky.
• Počítat s tím, že návody jsou zastaralé. Zavřené rozhraní pro nahrávání konverzí je čerstvá změna, o které se zatím skoro nepíše.

Celé to zabralo jedno odpoledne, protože jsem věděl, co stavím. Když to samé stavím klientovi, počítám s několika dny — hlavně proto, že se čeká na přístupy, nákladová data a na vývojáře e-shopu. Technika je na tom ta jednodušší část.

Jestli tohle řešíte u sebe, začněte tím nejnudnějším krokem: zjistěte, kdo vlastní vaše účty a pixely. Zbytek je práce, tohle bývá zeď. A pokud chcete vidět, jak vypadá ten samý řetěz u e-shopu, popsal jsem ho v článku o měření objednávek z backendu a v textu o tom, jak dostat do biddingu skutečný zisk.