Co je server-side tracking? Průvodce pro e-shopy

Server-side tracking znamená, že konverzní události, například nákup, se do reklamních platforem odesílají ze serveru, a ne jen ze skriptu v prohlížeči nakupujícího. U e-shopu server odesílá každou objednávku do Meta, TikToku nebo Googlu prostřednictvím jejich API, takže se prodej nahlásí i tehdy, když je pixel v prohlížeči zablokovaný nebo se vůbec nenačte.

Tento průvodce vysvětluje rozdíl mezi pixelem v prohlížeči a server-side trackingem, sleduje data od kliknutí na reklamu až po reklamní platformu a ukazuje, co serverová událost obsahuje. Zabývá se také deduplikací, server-side taggingem, souhlasem a tím, jak poznat, zda ho váš e-shop potřebuje. Samotné nastavení na Shopify najdete v článku server-side tracking na Shopify.

Pixel v prohlížeči vs. server-side tracking

Pixel v prohlížeči je kus JavaScriptu od reklamní platformy. Běží na vašich stránkách a posílá události ze zařízení nakupujícího přímo platformě: zobrazení stránky, přidání do košíku, nákup na poděkovací stránce. Funguje jen tehdy, když se skript načte, spustí a dosáhne platformy dřív, než nakupující stránku opustí.

Server-side tracking přesouvá odesílání na server. Událost může vycházet z dat, která váš obchod už má, například ze zaplacené objednávky, a server ji odešle do API platformy. Meta toto API nazývá Conversions API a TikTok ho nazývá Events API. Google Ads používá enhanced conversions, které ke konverzi přidávají hashovaná data zákazníka.

Provoz obou dává platformě nejúplnější data. Událost z prohlížeče přidává cookies a kontext stránky. Serverová událost dorazí, i když prohlížeč selže. Společné ID události zajistí, že platforma započítá každý nákup jen jednou.

Jak server-side tracking funguje?

Server-side tracking pro e-shop má dvě poloviny. První polovina probíhá v prohlížeči: když nakupující přijde z reklamy, skript uloží ID kliknutí z URL. Druhá polovina probíhá na serveru: když je objednávka zaplacena, server toto ID kliknutí propojí s objednávkou a odešle nákup.

Zachycení kliknutí

Reklamní platformy přidávají do URL vstupní stránky ID kliknutí: fbclid u Meta, ttclid u TikToku, gclid u Google Ads a msclkid u Microsoft Ads. ID kliknutí je nejsilnější vazba mezi prodejem a reklamou, která ho způsobila, a proto se musí uložit už při prvním zobrazení stránky. Parametry UTM přidávají názvy kampaně, sady reklam a reklamy ve formátu, který ovládáte vy.

Spárování objednávky

Server pak potřebuje vědět, který návštěvník objednávku vytvořil. Nejspolehlivějším propojením je hodnota, která putuje s košíkem do objednávky, například ID návštěvníka uložené v košíku. Jiné metody jsou slabší: e-mailová adresa, kterou návštěvník zadal dříve na webu, nebo stejná IP adresa a prohlížeč zaznamenané krátce před objednávkou. Každá platforma pro e-shopy nabízí jiné možnosti. Náš průvodce pro další e-shopy uvádí metody, které ROASaurus používá pro jednotlivé platformy.

Odeslání události

Nakonec server odešle nákup do API každé platformy. Událost obsahuje hodnotu objednávky, ID kliknutí a údaje o zákazníkovi, které platformě pomohou najít osobu, jež klikla. Pokud platforma nefunguje nebo vrátí chybu, dobré nastavení to zkusí později znovu, takže se nákup neztratí.

Co obsahuje serverová událost?

Každá platforma má vlastní názvy polí, ale událost nákupu nese všude stejné druhy dat. Zkrácený příklad pro Meta Conversions API:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

Hashování přemění e-mailovou adresu na řetězec znaků pevné délky. Stejná adresa dá vždy stejný řetězec, ale řetězec adresu neprozradí. Platforma používá hashované hodnoty jen k hledání shody mezi svými vlastními uživateli. Takto lze nákup spárovat s osobou, která reklamu viděla nebo na ni klikla, i když její prohlížeč pixel zablokoval.

Jak funguje deduplikace?

Když pixel i server odešlou stejný nákup, musí ho platforma započítat jen jednou. Obě kopie nesou stejný název události a stejné ID události, například order-1042. Meta dvojici porovná a ponechá jednu kopii, pokud druhá kopie dorazí do 48 hodin po první.

Většina dvojího započítávání pochází ze dvou odesílatelů, kteří nesdílejí ID. Typický případ je vlastní aplikace platformy v e-shopu a samostatný trackovací nástroj, které oba posílají nákupy s vlastními ID. Náš článek nápovědy o předcházení dvojímu započítání uvádí obvyklé příčiny a řešení.

Server-side tagging vs. odesílání z dat objednávky

Pojem server-side tracking se používá pro dvě různá řešení. Obě odesílají události ze serveru, ale začínají na různých místech.

Server-side tagging, například serverové kontejnery Google Tag Manager

U server-side taggingu posílá prohlížeč své události na váš vlastní server místo ke každému dodavateli zvlášť. Dobře známým příkladem je serverový kontejner Google Tag Manager. Běží ve vašem vlastním projektu Google Cloud nebo v jiném prostředí, které si zvolíte. Přijímá požadavky z prohlížeče a jeho tagy předávají data do Google Analytics, Meta a dalším dodavatelům. Vy rozhodujete, jaká data kam půjdou, a server může běžet na subdoméně vašeho webu.

Události stále začínají v prohlížeči. Pokud je tag v prohlížeči zablokovaný nebo se poděkovací stránka nikdy nenačte, serverový kontejner nemá co předat. Server také sami provozujete, platíte a aktualizujete.

Odesílání z dat objednávky

Druhý přístup vychází při odesílání nákupu ze záznamu objednávky ve vašem obchodě. Obchod nahlásí zaplacenou objednávku serveru přes webhook nebo API a server ji odešle každé připojené platformě. Prohlížeč je potřeba jen dříve, k uložení ID kliknutí, když nakupující přijde na web.

Oba přístupy lze kombinovat. Mnoho e-shopů sbírá zobrazení stránek a události přidání do košíku v prohlížeči a nákup odesílá z dat objednávky. Nákup je událost, kterou reklamní platformy používají k vykazování ROAS a k optimalizaci biddingu, takže právě ta musí být nejúplnější.

Co server-side tracking řeší a co neřeší?

Souhlas stále platí

Server-side tracking je způsob doručování dat, ne způsob, jak obejít pravidla ochrany soukromí. Pokud zákon vyžaduje souhlas pro marketingové cookies nebo sledování, tento požadavek se týká dat, která sbíráte, ať vedou k platformě jakoukoli cestou. Přesunutí trackeru na váš server nemění to, s čím návštěvník souhlasil.

Atribuce zůstává specifická pro každou platformu

Každá platforma stále připisuje nákupy podle vlastních oken a pravidel. Serverové události dávají každé platformě lepší data, ale součty napříč Meta, TikTokem a Googlem se i tak mohou dát dohromady na víc, než jsou tržby vašeho obchodu. Chcete-li kanály porovnávat podle jednotných pravidel, použijte pro všechny jeden atribuční model, například modely v atribuci ROASaurus.

Potřebuje váš e-shop server-side tracking?

E-shop, který utrácí významný rozpočet za placené reklamy na sociálních sítích nebo ve vyhledávání, z něj obvykle má prospěch. Nejsilnější je tento případ, když platí několik z těchto bodů:

• Reklamní platforma přijímá zřetelně méně událostí nákupu, než kolik má váš obchod webových objednávek. Náš průvodce blokátory reklam a trackingem ukazuje, jak tento rozdíl změřit.
• Mnoho vašich návštěvníků používá Safari na iPhonu nebo Macu, kde cookies nastavené skripty vydrží nejvýš 7 dní. Viz Safari ITP a reklamní tracking.
• Nakupující často nakoupí až několik dní po prvním kliknutí na reklamu.
• Platba se dokončí mimo váš web nebo se objednávky platí později, například u dobírky nebo bankovního převodu.
• Optimalizujete kampaně na nákupy nebo hodnotu nákupu, takže platforma potřebuje ke svému učení každý prodej.

Takto mění mezera rozhodnutí v praxi. Ukázkový e-shop má za měsíc 1,000 webových objednávek. Jeho pixel Meta nahlásil 820 událostí Purchase, takže 18% objednávek se z prohlížeče do Meta nikdy nedostalo.

ROAS bodu zvratu tohoto e-shopu je 2.5 a Ads Manager ukazuje na datech z pixelu ROAS 2.3. Podle těchto čísel kampaně prodělávají. Pokud by se objednávky z reklam přehlédly ve stejné míře 18%, je skutečný ROAS asi 2.3 ÷ 0.82 = 2.8, tedy nad bodem zvratu. To je horní odhad, protože ne každá chybějící objednávka pocházela z reklamy. Přesto ukazuje, jak může mezera v trackingu způsobit, že zisková kampaň vypadá jako ztrátová.

Server-side tracking je méně důležitý pro e-shop, který neinzeruje nebo utrácí za reklamy velmi málo.

Jak ROASaurus odesílá server-side události

ROASaurus při příchodu na web zachytí 19 ID kliknutí a šest polí UTM a uloží je spolu s first-party ID návštěvníka. Každý nákup ze zaplacených objednávek vašeho obchodu odesílá do Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll a Outbrain. Na Shopify se konverze Google Ads odesílají z pokladny Shopify. Pixely v prohlížeči mohou běžet vedle serverových událostí se stejným ID události a Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin a Spotify je deduplikují. Každé doručení a odpověď platformy jsou uvedeny v Event log.

Více se dočtete na stránce server-side tracking nebo najděte svůj e-shop na stránce integrací.

Zdroje

1. Meta for Developers: Conversions API
2. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
3. Meta for Developers: Customer Information Parameters
4. Google for Developers: An introduction to server-side tagging
5. Google Ads Help: About enhanced conversions

V ROASaurus

• Server-side tracking v ROASaurus
• Souhlas a soukromí
• Předcházení dvojímu započítání

Čtěte dál