Jak jsme migrovali 130 mediálních tagů na server a jak to celé dopadlo

Klient, u kterého jsme implementaci řešili, má část infrastruktury v Google Cloud Platform. Serverové GTMko mu běží v Cloud Run a jsou na něj směřovány hity z front-endových GTMs (klient měří z více domén). 

Hlavní migrace GA4 360 na serverové GTM proběhla již dříve. Dalším krokem byla serverová implementace pro mediální systémy: Google Ads, Facebook, Sklik a Bing. 

Důvodů pro migraci mediálních tagů bylo více:

• zrychlení webu díky přesunu médií na server (tj. lepší zákaznická zkušenost)

• bezpečnost - kontrola toho, co jednotlivé skripty posílají z webu za data

• pro uživatele se souhlasem příprava na nastavení zasílání osobních dat a jejich obohacování na serveru 

‍

Teoreticky brnkačka - Google Ads, Facebook i Bing mají serverové šablony. GA4 data na server už tečou, tj. použijeme tyto eventy k odpalování mediálních tagů. Určitě to bude jen klikačka - prostě nastavíme zrcadlově tagy na server. Jenomže vůbec :) 

‍

Trocha kontextu:

V době migrace bylo v obou hlavních GTM:

• 100 GA4 tagů

• 250 mediálních tagů

• to celé v rámci 7 top-level produktů

• dělených do 50 produktových skupin

• a ty dělené do 95 konkrétních produktů :)

‍

Všechny frontendové GTM kontejnery posílaly data do společného server-side GTM. Mediální tagy bylo tedy potřeba nejen přesunout, ale hlavně správně sesbírat z různých míst, konsolidovat jejich triggery a naming, a sloučit je pod správné konverze v jednotlivých systémech.

‍

Facebook: hybridní řešení CAPI

Facebook tagů bylo původně 54. S marketingem jsme se domluvili, že je co nejvíce sloučíme do několika obecnějších eventů – pro nastavování kampaní to bylo dostatečné. Cílem tedy bylo zjednodušovat. Jenže Facebook má rád hodně dat – a z různých směrů.

Klient svolil ke spuštění Facebook pixelu jak z browseru, tak ze serveru – tzv. hybridní řešení. Co to znamená a proč to dává smysl?

• Když pixel běží v prohlížeči, načte si na front-endu facebook knihovnu a získá spoustu informací o uživateli, včetně těch, které si sebere na pozadí.

• Když ho spouštíte na serveru, závisí na tom, co mu předáte. Je to bezpečnější způsob a méně citlivý na adblockery.

‍

Jak to vypadá v praxi:

1. Z browseru se odešle event (např. page_view) přímo do Facebooku. Musí obsahovat event_id – např. kombinaci timestampu a náhodného čísla (generujeme ve front-end GTM pomocí STAPE šablony).

Tato proměnná má v šabloně své místo v sekci More Settings.

2. Stejný trigger odešle paralelně event (např. GA4) na server – se stejným event_id (event variable).

3. Ze serveru se následně pošle stejný event do Facebooku pomocí Facebook šablony od STAPE. Event ID patří do části Server Event Data Override.

→ Facebook si události deduplikuje. Pokud přijde event z obou stran se stejným event_id, vezme si browserový. Když chybí, použije ten serverový.

Migrace vypadala jednoduše, ale znamenala ruční revizi všech 54 tagů – co sloučit, co zachovat, co přejmenovat a co přeposlat na server.

V některých případech jsme museli:

• sjednotit naming napříč dvěma hlavními GTM,

• vytvořit specifické triggery pro server,

• nebo posílat tzv. transportní tagy (pokud používáte k předání dat na server GA4 data stream).

‍

Představte si, že mediální remarketing spouštíte na gtm_consent_update. Ale tento event do GA4 neposíláte, tedy na serveru si na něj nesáhnete. A transportní tagy jsou GA4 eventy posílané na server jen kvůli spuštění mediálních tagů (neobsahují kompletní parametry). 

My jsme si je všechny označili stejným jménem, například sgtm_transport_gtmConsentUpdate. Na serveru je využili jako trigger pro mediální scripty, ale zároveň ho použili jako výjimku pro spouštění GA4 event data tagu.

‍

🛑 Ale pozor: pokud takový event odejde jako první v session, může přenášet session source / medium, a tím že ho z GA vyloučíte, vytvoří se vám v atribuci "not set".

‍

Těžce vydobyté :) tipy z praxe:

• Důsledně si hlídejte parametry, které přeposíláte.

• Například event_id možná nechcete ukládat do BQ nebo GA – pomocí transformací ho vylučte.

• Naopak některé parametry mohou způsobit "fail" tagu (např. lead_id, nebo facebookový parametr contents chybně zapsaný jako object místo array).

• Vždy kontrolujte Outgoing request v debug módu – jestli tam nic nehlásí chybu. Serverový debug není tak “výřečný” jako front-endový, nemusíte na chybu tak snadno přijít.

Pokud jste hybridní řešení FB CAPI nastavili dobře, ve FB event manageru se vám začne objevovat u jednotlivých eventů světle modrá linka, která značí data, jež přišla ze serveru. Obrázek níže ukazuje příklad perfektního výsledku, který splňuje nejvyšší FB požadavky - ze serveru je posíláno více eventů než z browseru, deduplikace funguje, nádhera :) 

‍

‍

Zde se díváme na event odeslaného formuláře, kde jsou běžně hodně zapojeny ad-blockery. Serverové řešení tady skóruje a zároveň FB může použít pro deduplikaci nejen event_id, ale navíc data jako zahashovaný email či telefon (pokud lze zasílat i osobní data, doporučujeme to udělat, např. s telefonem má Facebook výborný match rate). Zažila jsem eventy, kde bylo z browseru vícenásobně více eventů, protože byl server tag v GTM blokovaný kvůli consentu (?) a další libůstky.

U této migrace jsme se nakonec dostali na 33 eventů úspěšně deduplikovaných v hybridním CAPI řešení.

‍

Google Ads

Paralelně s nasazováním Facebooku jsme řešili nasazení Google Ads a Skliku. Google Ads a Sklik měly úplně jinou strukturu než FB tagy a tagů bylo mnohem více - u GAds to bylo 72 tagů a u Skliku také. Začalo nám opět kolečko s marketingem, které eventy ponechat, které sloučit a které nakonec doplnit. Tady jsme šli opačným směrem a ve výsledku bylo tagů více.

U Google Ads a Sklik není potřeba žádná deduplikace, tagy se spouští buď z browseru nebo ze serveru.

‍

Sklik

Sklik v době migrace neměl oficiální server-side šablonu. Pro klienta ji vytvořili kluci z Optimics a později ji dali k dispozici i veřejnosti. Šablona je snadno použitelná a její nastavení není o nic složitější než na front-endu.

Bing

Serverová šablona Bingu oproti front-endové obsahuje plno informací (včetně e-commerce), které můžete do mediálního systému posílat. Povinné jsou však jen ID systému (UET Tag ID) a název eventu.

‍

Consent

A jak je to s consentem? Facebook šablona od STAPE obsahuje volbu, zda posíláte na server již consentovaná data, nebo zda necháte na šabloně, aby se řídila dle consent parametru.

Google Ads na serveru přebírají consent mode parametr z front-endu, tedy do Google předávají informaci zda s daty lze nebo nelze pracovat.

‍

Sklik šablona od Optimics má v sobě zabudovanou integraci na Consent mode.

U Bingu na serveru v šabloně chybělo výslovné upozornění, jak se s consentem pracuje. Kontaktovali jsme tvůrce šablony, který slíbil, že ji doplní, a stalo se tak. V praxi to nyní funguje tak, že tag se odešle, ale s doplněným parametrem souhlasu či nesouhlasu.

‍

Summary 

Nešlo o technicky složitou migraci, ale bylo potřeba hodně testování a pečlivosti.

U každého tagu bylo potřeba otestovat, že trigger na serveru spustí tag správně, jinak by marketing přišel o konverze.

V době migrace Sklik oficiální server-side šablonu nenabízel. Pro klienta ji vytvořil tým Optimics a později ji zpřístupnil i veřejnosti (link).

Sklik i Bing a další tagy už si pak vzal na starosti hlavní analytik klienta - velký dík jemu i celému marketingovému týmu za skvělou spolupráci a podporu. Po několika měsících testování a zkoumání nastavení tagů se mi o nich i zdálo, a ráda jsem projekt předala dále.

‍

Seznamy použitých šablon + linky

Facebook Conversion API od STAPE (server tag)

Unique Event ID (front-end variable)

Google Ads Conversion Linker + Conversion Tracking (server standard tags)

Sklik template od Optimics (server tag)

Bing template (server tag)

Serverová migrace dnes může působit jako rutinní úkol – ale věřte, že to může být pořádná jízda :)