Jak nastavit Conversion API

Pixel v prohlížeči hlásí méně konverzí, než jich reálně máte, a algoritmus se pak učí ze zkomolených dat. Conversion API posílá události ze serveru, takže Meta vidí i to, co blokátor nebo Safari cestou zahodí.

Prohlížeč zahodí i třetinu konverzí a vy o tom nevíte

Pixel v prohlížeči je jediný zdroj dat jen na papíře. Safari zkracuje životnost cookies na sedm dní, iOS maže identifikátory po vypnutí aplikace, blokátory reklam zastaví skript ještě před načtením a část lidí odejde ze stránky dřív, než se událost stihne odeslat. Na klientských účtech, které přebírám, se ztráta pohybuje mezi 20 a 40 procenty odeslaných formulářů.

Conversion API je druhý kanál. Událost neodesílá skript v prohlížeči, ale váš server nebo serverless funkce, tedy prostředí, kam blokátor nedosáhne. Odeslání proběhne i v momentě, kdy člověk zavře záložku hned po odeslání formuláře. Výsledkem není magické zvýšení tržeb, ale úplnější obraz toho, co se na webu skutečně stalo.

Rozdíl se projeví do dvou týdnů. Kampaň s podílem serverových událostí kolem devadesáti procent optimalizuje na širší vzorek a cena za lead klesá typicky o 10 až 25 procent. U klienta z logistiky se po zapojení CAPI zvedl počet přiřazených poptávek ze 41 na 63 za měsíc, přitom rozpočet zůstal stejný.

Co si připravit, než napíšete první řádek kódu

Nasazení CAPI není o kódu, ale o přípravě. Devadesát procent problémů vzniká tím, že se začne posílat dřív, než je jasné, které události mají smysl a kdo bude generovat jejich identifikátory. Sepište si nejdřív seznam akcí, které vedou k penězům. U servisní firmy to bývá odeslaný formulář, klik na telefon a rezervace termínu.

Token řešte přes systémového uživatele v Business Manageru, ne přes svůj osobní účet. Osobní token přestane platit ve chvíli, kdy si změníte heslo nebo vám někdo odebere práva, a měření tiše umře. Systémový uživatel s rolí správce datového zdroje běží dál i po personální změně ve firmě.

• Přístup správce k Business Manageru a k datovému zdroji, ze kterého vezmete Pixel ID
• Systémový uživatel a jeho access token, nikdy ne osobní token pod vaším účtem
• Místo, odkud budete odesílat: edge funkce, backend aplikace nebo endpoint přímo ve webu
• Seznam událostí, které skutečně řídí byznys, typicky Lead, Purchase, Contact a Schedule
• Rozhodnutí, kdo generuje event_id, protože ho musí znát prohlížeč i server
• Souhlas s měřením vyřešený v cookie liště, jinak nemáte právní základ pro odeslání dat

Deduplikace přes event_id: bez ní si každý lead počítáte dvakrát

Když stejnou událost posílá prohlížeč i server, Meta musí poznat, že jde o jeden a týž skutek. Slouží k tomu dvojice event_name a event_id. Identifikátor musí vzniknout jednou, typicky na stránce při odeslání formuláře, a stejná hodnota musí doputovat do prohlížečové i serverové zprávy, jinak se párování nikdy nechytne.

V praxi to dělám tak, že na frontendu vygeneruji náhodné ID, předám ho do fbq jako eventID a zároveň ho pošlu v těle požadavku na svůj endpoint. Server ho jen převezme a vloží do payloadu. Okno pro spárování je 48 hodin, takže odeslání ze serveru klidně o pár vteřin počká.

Nejčastější tichá chyba: server si ID vyrobí sám, protože ho z frontendu nedostane. Deduplikace pak nikdy nezafunguje a v reportu máte dvojnásobek poptávek. Poznáte to jednoduše, počet konverzí je najednou přesně dvakrát vyšší než počet záznamů v databázi. Než začnete slavit, porovnejte si obě čísla.

Match rate: kolik lidí se vůbec podaří spárovat

Serverová událost je k ničemu, pokud ji Meta nepřiřadí ke konkrétnímu člověku. Míra shody se ukazuje v Events Manageru jako kvalita shody událostí na stupnici do deseti. U poptávkových webů beru jako slušnou hodnotu 6,5 a výš, u e-shopů s objednávkou 8. Pod pěti se optimalizace chová nahodile.

Skóre zvednete tím, co posíláte, ne tím, kolik toho posíláte. Každý identifikátor musí být před odesláním normalizovaný a zahashovaný algoritmem SHA-256. Email převeďte na malá písmena a ořízněte mezery, telefon zapište v mezinárodním tvaru bez plus a bez mezer. Kdo hashuje neupravený vstup, posílá v podstatě náhodná čísla.

Šest chyb, které nacházím na cizích účtech

Přebírám měření po jiných dodavatelích poměrně často a chyby se opakují. Skoro nikdy nejde o špatný kód, ale o detail ve formátu dat nebo o zapomenutý testovací režim. Následující seznam projděte dřív, než začnete ladit cokoliv složitějšího, obvykle je viník schovaný mezi prvními třemi body.

Kontrolu dělám vždy na živých datech, ne na testovacím účtu. Otevřu si Test Events, odešlu skutečný formulář a sleduji, jestli dorazí obě verze události se stejným ID. Pokud se objeví dvě samostatné položky bez značky o deduplikaci, vím, že párování nefunguje, a nemusím dál hádat.

• Hash počítaný z neupraveného vstupu, tedy Jan.Novak@Firma.cz místo jan.novak@firma.cz
• Telefon odeslaný jako 777 123 456 bez předvolby a s mezerami, shoda pak nesedí
• Nové event_id vyrobené na serveru, takže se s prohlížečem nikdy nepotká
• Parametr action_source nastavený na website i u události z telefonátu
• Chybějící event_source_url, kvůli které se událost nepřiřadí k žádné stránce
• Testovací kód test_event_code zapomenutý v produkci, data pak končí jen v testovací záložce

Cena, doba nasazení a kontrola po spuštění

Nasazení Pixelu a Conversion API včetně deduplikace, testu a předání dokumentace dělám za 6 900 Kč. Práce zabere jeden až dva dny podle toho, jak je web postavený. Na statickém webu s jedním formulářem jsem hotový za dopoledne, u e-shopu s vlastním košíkem počítejte s celým dnem navíc.

Pokud web teprve vzniká, měření zapojuji rovnou při stavbě. Web od 19 990 Kč má měření připravené v základu, u Growth Systemu od 39 900 Kč k tomu patří i napojení na CRM a reporty. Samostatné doměření staršího webu je vždycky dražší, protože se musím vrtat v cizím kódu.

Měření není věc, kterou nastavíte a zapomenete. Meta mění pravidla, prohlížeče zkracují cookies a web se v čase upravuje. V rámci péče za 2 990 Kč měsíčně kontroluji kvalitu shody a duplicity jednou měsíčně, protože rozbité měření se pozná až podle rostoucí ceny za lead, tedy pozdě.

• U události svítí v Events Manageru deduplikace jako aktivní a počet duplicit klesl k nule
• Kvalita shody je u události Lead alespoň 6,5 z 10, u Purchase raději 8
• Podíl událostí posílaných jen ze serveru je pod 15 procent, jinak nefunguje prohlížečová část
• Payload obsahuje fbc pokaždé, když člověk přišel z reklamy s parametrem fbclid
• V testovacím režimu vidíte obě verze události vedle sebe se shodným identifikátorem

Časté otázky

Musím mít Conversion API, když mi Pixel funguje?

Pixel funguje jen do chvíle, než ho někdo zablokuje. Podle logů z projektů, které spravuji, se prohlížečová událost neodešle u 20 až 40 procent lidí. Kampaň se pak učí z menšího vzorku a cena za lead roste. Serverové měření je dnes standard, ne nadstavba pro velké inzerenty.

Neporušuji odesíláním emailů ze serveru GDPR?

Ne, pokud máte souhlas s marketingovým měřením a odesíláte jen zahashované údaje. Data opouštějí server ve formě otisku SHA-256, tedy jako nečitelný řetězec. Podmínkou je funkční cookie lišta, která měření skutečně vypne, když člověk souhlas odmítne. Souhlas musí řídit i serverovou větev, ne jen skript v prohlížeči.

Jak dlouho trvá, než se zlepšení projeví v kampaních?

Prvních sedm dní jen sbíráte data a čísla vypadají zmateně, protože se mísí staré a nové měření. Rozdíl v ceně za lead čtěte nejdřív po čtrnácti dnech a porovnávejte stejně dlouhá období. U kampaní s malým objemem, tedy do dvaceti konverzí týdně, počítejte spíš s celým měsícem.