Din tracking taber data lige nu — ikke fordi den er sat forkert op, men fordi browseren er holdt op med at samarbejde. Her gennemgår jeg de tre måder at tracke på — ren browser, hybrid og ren server-side — med diagrammer, fordele og ulemper, og hvad der teknisk sker under motorhjelmen.
Server side tracking er tracking, hvor data sendes via din egen server i stedet for direkte fra brugerens browser til Google, Meta og andre. I stedet for at browseren råber direkte ud til ti forskellige tredjeparter, sender den ét sted hen — til din egen server-side container — som så afgør, hvad der skal videre, hvorhen, og med hvilke data.
Det giver dig mere kontrol, mere holdbar data og mindre tab til browserbegrænsninger. Det fjerner ikke kravet om samtykke (mere om den myte længere nede). For at forstå hvorfor det er blevet nødvendigt, er man nødt til at se på de tre arkitekturer ved siden af hinanden.
Stort set al webtracking falder i én af tre kategorier: ren browser-tracking (client-side), en hybrid af browser og server, eller ren server-side. De adskiller sig på ét grundlæggende spørgsmål: hvor bliver dine data sendt fra — og hvor mange led kan gå galt undervejs?
Den klassiske opsætning. Tags og pixels — Google-tagget, Meta-pixlen, GA4 — sidder i brugerens browser og sender data direkte til hver platform, hver gang noget sker. Det er hurtigt at sætte op og kræver ingen ekstra infrastruktur.
Problemet er, at browseren er et fjendtligt miljø. Et tredjeparts-script kan blokeres af en ad blocker, før det overhovedet loader. Cookies sat af scripts (3rd party-konteksten) lever kort tid under Safaris ITP — en gclid-cookie kan være væk efter 24 timer. Og lukker brugeren fanen, før pixlen fyrer, er konverteringen tabt. Du sender data fra det ene sted, du har mindst kontrol over.
Den mest udbredte og — for de fleste — den rigtige opsætning. Du beholder client-side tracking og tilføjer en server-side container. De vigtigste events sendes ad begge veje: pixlen fyrer som altid i browseren, og parallelt sender browseren også data til din egen server-container, der videresender til platformene via deres server-API'er (Metas Conversion API, Googles tilsvarende).
Det åbenlyse spørgsmål: tæller man så ikke den samme konvertering to gange? Nej — og det er her event_id-deduplikering kommer ind. Begge events sendes med det samme unikke event_id. Platformen ser id'et to gange, forstår at det er den samme hændelse, og tæller den én gang. Resultatet er det bedste fra begge verdener: den rige browserkontekst når frem når den kan, og server-pathen fanger det, browseren taber — uden dobbelttælling.
event_id sikrer, at konverteringen kun tælles én gang.Her fjerner du så meget som muligt fra browseren. Browseren sender én enkelt first-party request til din egen server-container (på dit eget subdomæne), og al videre måling sker server-side. Ingen tredjeparts-pixels at blokere, ingen scripts der tynger sideloaden.
Det giver maksimal kontrol og holdbarhed, men har en pris: noget browserkontekst er svær at rekonstruere server-side (visse interaktioner, visse signaler som platformene helst vil have fra klienten), og opsætningen er den mest krævende af de tre. I praksis ender selv "rene" server-side setups ofte med en lille client-side komponent for at bevare de vigtigste browsersignaler — hvilket i virkeligheden gør dem til en hybrid.
Side om side
| Ren browser | Hybrid | Ren server-side | |
|---|---|---|---|
| Datatab (ad blockers/ITP) | ⚠ Højt | ✓ Lavt | ✓ Lavest |
| Cookie-levetid | ⚠ Kort (ITP) | ✓ Lang (1st party) | ✓ Lang (1st party) |
| Browserkontekst | ✓ Fuld | ✓ Bevaret | ⚠ Delvist |
| Kontrol over data | ⚠ Lav | ✓ Høj | ✓ Højest |
| Opsætningskompleksitet | ✓ Lav | ⚠ Middel | ⚠ Høj |
| Risiko for dobbelttælling | ✓ Ingen | ⚠ Kræver dedup | ✓ Ingen |
| Kræver samtykke? | Ja | Ja | Ja |
Forskellen mellem arkitekturerne handler grundlæggende om hvem der sætter cookien og hvordan data transporteres. Et par begreber gør det hele klarere:
En cookie sat af et script fra et fremmed domæne (fx Googles tag) er en third-party cookie i den kontekst — og det er præcis dem, Safari ITP og browsere begrænser hårdest. Når din server-container sætter cookien fra dit eget subdomæne (typisk via et CNAME, så sgtm.ditdomæne.dk peger på Stape), er det en ægte first-party cookie. Den lever længere, og den kan sættes som HttpOnly, så browserens JavaScript — og dermed ITP's mest aggressive regler — ikke rører den.
Client-side sender data som et billede- eller fetch-kald fra browseren. Server-side sender i stedet via platformenes server-API'er: Metas Conversion API (CAPI), Googles tilsvarende, og Measurement Protocol til GA4. Det er HTTP-kald fra din server til deres — uden for browserens og ad blockernes rækkevidde.
I en hybrid er event_id limen. Det samme id sættes på både browser-eventet og server-eventet for én konvertering. Platformen matcher de to og tæller én gang. Sættes id'et forkert, risikerer du enten dobbelttælling eller tabte events — derfor er korrekt dedup-opsætning det vigtigste enkelte håndværk i en hybrid.
Server-side Google Tag Manager (sGTM) er den container, der modtager, beriger og videresender. Den skal hostes et sted — og Stape er den mest udbredte hosting, fordi den klarer skalering, first-party domæne og drift, så du ikke selv skal vedligeholde servere.
Det er ikke en trend for trendens skyld. Tre kræfter har gjort ren client-side utilstrækkelig:
Vigtigt
Server side tracking gør dig IKKE fri af GDPR eller cookie-samtykke.
Fordi data går via din egen server, tror nogen, at samtykke ikke længere er nødvendigt. Det er forkert. Sender du marketing-data til Google eller Meta, kræver det stadig brugerens samtykke — uanset om det sker fra browseren eller fra din server. Click IDs som gclid og fbclid er personhenførbare og kræver marketing-samtykke.
Consent Mode kan modellere de konverteringer, du mister fra brugere uden samtykke, men den erstatter ikke samtykke — den estimerer, hvad du ikke må måle direkte.
Server-side giver dig bedre kontrol og datakvalitet fra de brugere, der har sagt ja. Det er værdien — ikke et fripas.
For langt de fleste danske virksomheder og webshops er svaret en hybrid: du beholder den rige browserkontekst, fanger det browseren taber, og holder dig robust over for ITP og ad blockers — uden at gamble på, at server-side alene kan rekonstruere alt.
Men vær ærlig med dig selv: ikke alle har brug for det lige nu. Har du et lille annoncebudget og begrænset datatab, kan gevinsten være beskeden i forhold til opsætningsomkostningen. Bruger du derimod betydelige beløb på Google Ads eller Meta, og kan du se, at dine tal ikke stemmer, er en hybrid server-side opsætning ofte det, der flytter mest. En tracking audit kan afgøre det konkret for netop din opsætning.
Nej, men de hænger sammen. Conversion API (CAPI) er Metas specifikke API til at modtage server-side events. Server side tracking er infrastrukturen — din container — der blandt andet kan sende til Metas CAPI, men også til Google Ads, GA4 og andre. CAPI er én destination; server-side tracking er motoren, der leverer til dem alle.
Spørgsmål & svar
Se også