Server-side tracking: hvad det løser, og hvad det ikke gør

Server-side tracking bliver solgt på to måder, og begge er misvisende. Den ene lyder som om det er en måde at komme uden om samtykke. Den anden lyder som om det giver hundrede procent måling tilbage. Ingen af delene passer.

Her er hvad det faktisk gør.

Hvad der ændrer sig teknisk

I en klassisk opsætning sender browseren data direkte til Google, Meta og hvad der ellers er sat op. Hver platform får sin egen forbindelse, sit eget script og sin egen cookie.

Med server-side tracking sender browseren i stedet data ét sted hen: til en container, du selv driver, typisk på et subdomæne under dit eget domæne. Derfra afgør du, hvad der bliver sendt videre til hvem.

Tre ting følger af det:

• Færre tredjepartsscripts i browseren. Det er godt for hastigheden og for Core Web Vitals.
• Førstepartskontekst. Cookies sat fra dit eget domæne overlever de begrænsninger, browsere lægger på tredjepartscookies — mest mærkbart i Safari.
• Kontrol over dataudvekslingen. Du kan se, filtrere og berige, hvad der forlader huset. Det er både en teknisk og en juridisk fordel.

Hvad du realistisk får ud af det

Det tal, folk gerne vil have, er "hvor meget mere måler vi?". Det ærlige svar er, at det afhænger af udgangspunktet.

Typisk ser jeg 5-20 procent flere målte konverteringer blandt brugere, der i forvejen har givet samtykke. Gevinsten er størst hos webshops med mange Safari- og iOS-brugere, og hos sites med lange overvejelsesforløb, hvor en syv dages cookie-levetid klipper attributionskæden over.

Den anden gevinst er ofte større og bliver nævnt sjældnere: berigelse. Når konverteringen sendes fra din server, kan du hænge oplysninger på, som browseren aldrig har haft — dækningsbidrag, om det er en ny eller eksisterende kunde, om ordren blev returneret to uger senere. Det er forskellen på at optimere annoncering mod omsætning og at optimere mod indtjening.

Hvad det ikke gør

Det fritager ikke for samtykke. Server-side flytter hvor behandlingen sker, ikke om du har lov. Har brugeren sagt nej, skal der ikke sendes personhenførbare data — heller ikke fra din egen server. Setuppet skal bygges sammen med Consent Mode og din samtykkeløsning, ikke ved siden af.

Det redder ikke data fra afvisninger. Siger fyrre procent nej til statistik, mangler du stadig fyrre procent. Modelleret data kan udfylde noget af hullet i platformenes egne rapporter, men det er estimater, og de skal behandles som estimater.

Det gør ikke tallene ens. GA4, Meta og dit økonomisystem vil fortsat vise forskellige tal, fordi de tæller forskellige ting over forskellige perioder. Server-side gør forskellen mindre og — vigtigere — forklarlig.

Det, der oftest går galt

Samtykket bliver ikke koblet ordentligt på. Containeren sender videre, uanset hvad brugeren har svaret. Det er den alvorligste fejl, og den er nem at lave, fordi alt ser ud til at virke.

Deduplikering mangler. Kører browser- og serverhændelser parallelt i en overgangsperiode uden fælles event-id, tælles konverteringer to gange. Så ser tallene fantastiske ud i en måned, og ingen tør bruge dem bagefter.

Ingen overvåger containeren. En server-side container er infrastruktur. Den kan løbe tør for kapacitet, fejle på en udrulning eller stille og roligt begynde at afvise hændelser. Uden overvågning opdager man det, når nogen undrer sig over en graf tre uger senere.

Alt bliver sendt videre. Fristelsen til at sende hele ordreobjektet til enhver platform er stor, fordi det er nemt. Det er også præcis den slags, der er svær at forsvare, når nogen spørger, hvilke data der forlader virksomheden.

Hvad det koster at drive

En container på Google Cloud Run koster typisk 300-1.500 kr. om måneden afhængigt af trafik. Det er ikke det store beløb, men det er en fast omkostning og en driftsopgave, der skal have en ejer.

Selve opsætningen ligger for en almindelig webshop i omegnen af tre til seks ugers arbejde, hvis samtykke, deduplikering og validering skal være i orden. Går det væsentligt hurtigere, er der som regel skåret et af de tre hjørner.

Hvornår det ikke er svaret

• Trafikken er lille. Under nogle tusinde konverteringer om året ændrer forskellen mellem 90 og 98 procent målt data ingen beslutning. Pengene er bedre brugt et andet sted.
• I bruger ikke de tal, I allerede har. Bedre måling løser ikke, at ingen kigger på rapporterne. Start med at bruge det, der er.
• Grundopsætningen er i stykker. Er events navngivet inkonsekvent og transaktioner målt forkert, giver det ingen mening at flytte problemet over på en server. Ryd op først — det er billigere og virker med det samme.

En fornuftig rækkefølge

1. Få styr på samtykkeløsningen og dokumentér, hvad der indsamles på hvilket grundlag.
2. Ryd op i den eksisterende måling: navngivning, transaktioner, dubletter.
3. Sæt server-side op parallelt med det eksisterende, og kør begge dele i to til fire uger.
4. Sammenlign mod ordredata fra økonomisystemet — ikke mod den gamle måling.
5. Sluk det gamle, når forskellen kan forklares.

Punkt fire er det, der oftest springes over, og det eneste sted man kan afgøre, om det nye setup er bedre. Alt andet er at sammenligne to målinger med hinanden og håbe på det bedste.