Marketing na Facebooku patrí stále mezi rozšírené spôsoby získavania zákazníkov. Naši klienti používali dlhé roky na sledovanie návštevníkov a optimalizáciu kampaní Facebook Pixel – tag v klientskom Google Tag Manageri (cGTM).
S prechodom na server-side tagging však prišla aj logická požiadavka presunúť marketingové tagy do serverového Google Tag Managera (sGTM) a používať Facebook Conversion API.
V server-side GTM existuje viacero tagov pre Facebook CAPI, ako napríklad tie od Stape, alebo Facebook Incubator.
Avšak, narazili sme pri nich na problém:
- Facebook Incubator – používa API verziu, ktorá by mala byť dostupná iba do 14. mája 2025 a nevieme, či bude tento tag aktualizovaný. Zároveň má obmedzenú funkcionalitu.
- Stape – vytvoril veľmi robustný a komplexný tag. Potrebovali sme však viac flexibility, aby sme mohli prispôsobiť riešenie pre naše špecifické potreby.
A tak vznikla potreba vytvoriť si vlastný FB Conversion API tag.
V nasledujúcich riadkoch vám prezradíme, s akými výzvami sme sa stretli, ako sme ich zvládli a aké parádne vychytávky sme do nášho tagu zakomponovali. Možno vás to inšpiruje skúsiť niečo podobné. 😅
Problémy a riešenia
1. Mapovanie názvov udalostí
Prvý problém, ktorý sme riešili bol, ako jednoducho “namapovať” názvy udalostí. Facebook má svoj zoznam odporúčaných názvov „AddToCart„, „CompleteRegistration,“ a podobne, ktorým zodpovedajú príslušné udalosti z Google Analytics.
Ale čo ak chcete udalosť pomenovať inak? Niektoré CAPI tagy túto možnosť ani neponúkajú. Buď použijete správny názov eventu, alebo sa vaša požiadavka neodošle.
Naše riešenie umožňuje používať názvy udalostí v tagu podľa potreby. Funguje nasledovne:
- Štandardné udalosti sú mapované automaticky.
- V rozhraní tagu je dostupné pole, kde môžeme zadať vlastný názov udalosti pre GA4 (napr. „custom_lead“) a jeho ekvivalent, ktorý sa odošle do Facebooku (napr. „Lead“).
- Ak sa nevyužije žiadna z vyššie uvedených možností, tag odošle údaje s pôvodným názvom udalosti v GA4.
Tento prístup nám zabezpečuje maximálnu jednoduchosť a flexibilitu pri mapovaní názvov udalostí, umožňujúc prispôsobenie podľa konkrétnych potrieb projektu.
2. Mapovanie používateľských dát
Druhým problémom bolo mapovanie používateľských dát, ktoré odosielame do serverového GTM pomocou premennej User-Provided Data. Bolo by krásne, keby Google a Facebook používali rovnakú štruktúru a formát dát. Nuž, nie je to tak.
Napríklad Google vyžaduje, aby telefónne číslo obsahovalo prefix „+“, zatiaľ čo Facebook požaduje číslo bez neho.
Aby sme sa vyhli manuálnemu mapovaniu týchto dát, vytvorili sme funkciu, ktorú je možné v tagu zapnúť. Táto funkcia automaticky číta používateľské dáta z prichádzajúceho requestu, upravuje ich podľa požiadaviek platformy a hashuje.
Okrem toho sme pridali možnosť prepísať alebo doplniť používateľské dáta priamo v rozhraní tagu. Takto môžeme napríklad doplniť chýbajúce emailové adresy alebo telefónne čísla.
Zaujímavosť – možno ste to už vedeli, možno nie: Facebook Pixel v klientskom GTM číta používateľské dáta iba raz, a to pri inicializácii tagu. Teda pri spustení prvého Pixel tagu na stránke.
Čo to znamená? Ak aj máte v klientskom GTM parádne nastavený Lead Pixel, ktorý odosiela všetky používateľské dáta z formulára (email, telefón, adresu), ale predtým sa už na stránke odpálil napr. PageView Pixel, máte smolu.
Používateľské dáta sa neodošlú. Neboli dostupné pri prvom evente na stránke, ktorým bol PageView.
CAPI týmto problémom netrpí. Ďalší plusový bodík pre serverové GTM. ✔
3. Ecommerce údaje
Pre eCommerce weby je nevyhnutné zabezpečiť správne odosielanie údajov o produktoch. To môže byť výzva, pretože Facebook odporúča používať pre jednotlivé ecommercové udalosti rôzne parametre.
Upravili sme preto náš tag tak, aby automaticky spracovával parametre z GA4 items objektu a transformoval ich do formátu kompatibilného s CAPI na základe konkrétnej udalosti.
S AddToCart udalosťou sa teda posielajú iné ecommercové parametre ako s Purchase.
Takýmto spôsobom sa výrazne minimalizuje manuálna práca pri príprave údajov (lenivosť, matka pokroku 😅), čím sa šetrí čas a znižuje riziko chýb. Zároveň sa zabezpečuje plná kompatibilita s požadovaným formátom Facebooku a efektívnejšie spracovanie udalostí v rámci CAPI integrácie.
4. Custom data
Každá implementácia má svoje špecifické požiadavky, a preto sme pridali možnosť odosielať vlastné parametre v rámci udalostí. Stačí ich jednoducho definovať v rozhraní tagu.
Nejde o žiadnu výnimočnú funkcionalitu, no umožňuje prepísať alebo vymazať akékoľvek parametre, ktoré tag automaticky načíta – vrátane používateľských. Vďaka tomu môžeme napríklad anonymizovať IP adresu, upraviť hodnotu objednávky alebo namiesto tržby posielať informáciu o zisku.
Extra funkcie
5. FB Data Object Builder
Jedným zo špecifických problémov, s ktorými sa občas stretávame, je obmedzený počet parametrov, ktoré je možné odoslať v GA4 tagu. Tento limit je momentálne stanovený na 25 parametrov na jednu udalosť.
Aby sme tento limit neprekračovali a nezapĺňali dostupné parametre údajmi, ktoré sú špecifické iba pre Facebook, vytvorili sme v klientskom GTM premennú s názvom Facebook Data Object Builder.
Táto premenná slúži na generovanie objektu nazývaného fb_data, ktorý môže obsahovať ľubovoľné parametre podľa potrieb. Vygenerovaný objekt následne vložíme do GA4 tagu ako reťazec znakov a odošleme do serverového GTM.
Náš CAPI tag dokáže tieto parametre automaticky načítať a spracovať, čím odpadá potreba vytvárať nové premenné v serverovom GTM. Týmto spôsobom si ušetríme prácu a niekoľko parametrov, ktoré môžeme využiť na iné dáta.
6. FB CAPI Monitoring v BigQuery
Na záver sme si nechali jednu bonusovú funkcionalitu – FB CAPI Monitoring.
Aby sme mali komplexný prehľad o odosielaných dátach, implementovali sme paralelné odosielanie requestov do BigQuery. Možno si poviete, že všetko potrebné predsa vidíte vo Facebook Manageri. Áno, aj nie.
Facebook Manager zobrazuje iba dáta, ktoré úspešne prijal, zatiaľ čo my do BigQuery posielame všetky dáta – vrátane tých, ktoré Facebook kvôli nejákej chybe odmietol – status code 400.
Týmto spôsobom môžeme jednoduchšie identifikovať prípadné problémy s implementáciou. Zozbierané dáta následne vizualizujeme v Looker Studio, kde ich kvalitu a konzistenciu sledujeme prostredníctvom prehľadného dashboardu.
Tabuľka a dashboard majú jedno špecifikum. Aby sme nemuseli v BigQuery pre klientov, ktorí posielajú do Facebooku vlastné dimenzie, vytvárať špeciálne tabuľky s novými stĺpcami, zapúzdrujeme tieto dáta do JSON objektu. V Looker Studiu potom tento objekt dokážeme rozložiť pomocou REGEX-u a vyextrahovať potrebné informácie.
Záver
Náš FB CAPI tag obsahuje ešte zopár drobných vychytávok, ktorým sa teraz nebudeme podrobnejšie venovať.
Radšej by sme chceli zdôraznili, že náš tag je optimalizovaný špecificky pre spracovanie dát z webu a webových aplikácií. Facebook CAPI pre mobilné aplikácie je samostatná kategória, do ktorej sa možno pustíme neskôr. S novou možnosťou server-side trackovania pre mobilné aplikácie je však motivácia výrazne väčšia.
Zaujalo vás naše riešenie? Napíšte nám na cibula@dase.sk a radi vám poskytneme náš FB CAPI tag spolu so schémou pre vytvorenie monitorovacej tabuľky v BigQuery. 🖖