Målingen i en webshop bliver ofte dårligere over tid, selv om man “ikke har ændret noget”. Adblockere, strengere browserregler og flere samtykkekrav betyder, at især køb og checkout-events let forsvinder fra GA4 og annonceplatforme. Resultatet er typisk skæve ROAS-tal, svagere algoritmer i Meta og Google Ads og sværere beslutninger i hverdagen.
Server-side tracking er en praktisk måde at få mere stabil data på, uden at man skal gå på kompromis med samtykke og dataminimering. Her flytter man dele af sporingen fra brugerens browser til en kontrolleret serveropsætning, hvor man kan filtrere, strukturere og sende data videre på en mere robust måde.
Hvad server-side tracking betyder for en webshop
Server-side tracking betyder, at events fra webshoppen sendes til et endpoint, som I selv kontrollerer (typisk en GTM server-side container på et subdomæne). Derfra sendes de videre til GA4, Meta (Conversions API) og evt. andre systemer.
I praksis giver det jer to vigtige ting:
- Mere kontrol med dataen (hvad sendes, og hvornår sendes det).
- Mindre afhængighed af, om brugerens browser tillader scripts og tredjepartskald.
Det er ikke en “magisk bypass” af samtykke. Hvis brugeren siger nej til statistik eller marketing, skal opsætningen respektere det. Server-side gør det bare lettere at håndhæve reglerne konsekvent og undgå tilfældige tab af data.
Typisk arkitektur: web-container + server-container
De fleste webshops ender med en todelt opsætning:
- En web-GTM container (i browseren), som lytter på dataLayer og sender et enkelt kald videre.
- En server-GTM container (i skyen), som modtager kaldet, fortolker det via clients og sender videre til GA4 og Meta.
Det er en god model, fordi den stadig passer til et marketingteam, der er vant til GTM, men flytter de mest følsomme dele (tokens, API-kald og datarens) væk fra browseren.
En typisk dataflow-kæde ser sådan ud: webshop-event → dataLayer → web-GTM → server-endpoint → server-GTM → GA4/Meta.
GA4 + Meta CAPI: event-struktur og deduplikation
Når GA4 og Meta skal have de samme konverteringer, handler det om ensartede eventnavne, stabile parametre og korrekt deduplikation.
Meta kræver i praksis, at man arbejder med et event_id, når man kører både Pixel og CAPI, så samme køb ikke tælles to gange. GA4 kræver omvendt, at e-commerce-parametre (værdi, valuta, varer) er sat rigtigt, så rapporter og attribution ikke knækker.
Når det er sat op ordentligt, kan man typisk få:
- bedre match rate i Meta (især hvis man bruger hashede identifiers, når man har grundlag for det)
- mere pålidelige purchase-events
- færre “huller” i data ved langsomme forbindelser og browser-luk
Samtykke, GDPR og Consent Mode v2 i praksis
En server-side opsætning skal designes efter samtykke, ikke omvendt. Det betyder, at jeres CMP (cookie-banner) skal sende klare signaler til sporingen, og at både web- og server-containere skal respektere dem.
Consent Mode v2 bruges ofte til at styre, om GA4 må bruge cookies, og om marketing-tags må sende data, når brugeren ikke har givet samtykke. Samtidig skal I stadig have orden i:
- databehandleraftaler (Google, Meta og CMP)
- dataminimering (send kun det, der er nødvendigt)
- hosting og adgangskontrol (gerne EU-region til serverdelen)
- dokumentation i privatlivspolitik og behandlingsfortegnelse
Server-side tracking gør det også lettere at filtrere uønskede parametre fra, før data sendes videre. Det er en fordel, når man vil undgå, at PII ved en fejl havner i analytics.
Hvornår det giver mening (og hvornår det ikke gør)
Server-side tracking passer sjældent som “første skridt”, hvis man endnu ikke har styr på basic tracking: korrekt GA4 e-commerce, rene UTM’er, fornuftige events og stabilt cookie-setup.
Det giver typisk mening, når I kan nikke ja til flere af disse punkter:
- I bruger betalt annoncering aktivt: og har brug for stabile konverteringssignaler til algoritmerne.
- I ser afvigelser i køb: mellem webshop-systemet og GA4/Meta, som påvirker rapportering og budget.
- I har et samtykke-setup: og vil sikre, at det håndhæves konsekvent i hele tracking-kæden.
- I vil have mere kontrol: over hvilke data der sendes til hvilke leverandører.
Nogle webshops ender med en hybrid, hvor enkelte kritiske events sendes både client-side og server-side, mens resten holdes simpelt.
Client-side vs. server-side: kort overblik
| Område | Client-side tracking | Server-side tracking |
|---|---|---|
| Datatab | Mere sårbar over for adblockere og browserbegrænsninger | Ofte mere stabil eventlevering |
| Hastighed | Flere scripts i browseren kan påvirke performance | Browseren kan nøjes med færre kald |
| Sikkerhed | IDs og konfiguration er mere synlig | API-secrets kan holdes på server |
| Compliance-styring | Sværere at filtrere og ensrette på tværs | Lettere at rense/validere før afsendelse |
| Drift | Mindre teknik, færre moving parts | Kræver hosting, logning og overvågning |
Opsætning: sådan tilrettelægges arbejdet
En god opsætning handler mindre om “at få det til at virke” og mere om at få det til at virke stabilt om 3, 6 og 12 måneder. Derfor starter man typisk med en trackingplan og en teknisk afklaring, før der bygges.
En typisk proces kan se sådan ud:
- Kort audit af nuværende GA4, GTM, Pixel/CAPI og CMP
- Event- og parameterplan (hvad er “køb”, og hvad skal sendes med)
- Opsætning af server-container (cloud eller hostet solution) og subdomæne
- Mapping og tagging til GA4 og Meta CAPI, inkl.
event_id-strategi - Consent Mode v2 kobling og test af “granted/denied” scenarier
- QA mod webshopdata (ordrer, omsætning, refunderinger) og go-live
Drift: det der holder dataen ren
Når opsætningen er live, skal den holdes skarp. Små ændringer i tema, checkout, app-plugins eller CMP kan flytte rundt på events, uden at nogen opdager det før uge-rapporten ser mærkelig ud.
Derfor giver det mening at have faste rutiner for drift og kontrol:
- Daglig eller ugentlig sanity check: køb i webshop vs. køb i GA4 og Meta.
- Logning og fejlfinding: kig på fejlrate, timeouts og event-volumen i servermiljøet.
- Versionsstyring i GTM: ændringer dokumenteres og kan rulles tilbage.
- Samtykke-tests: test scenarier med afvist marketing/statistik, især efter CMP-opdateringer.
Webshopplatforme og setups der ofte passer godt
Server-side tracking kan laves på mange platforme, men nogle miljøer er mere oplagte end andre, fordi man kan få en stabil dataLayer og klare e-commerce events.
Det ses ofte på:
- Shopify
- WooCommerce
- Headless shops med egen checkout
- Webshops med Klaviyo, Meta Ads og Google Ads som faste kanaler
Samarbejdsform og prisstruktur
Mange vælger at få hjælp både til opsætning og til drift, fordi tracking ellers ender som et engangsprojekt, der langsomt forfalder. Andre vil selv sidde med hænderne i GTM, men have en fast sparringspartner til review, QA og fejlretning.
Et bureau som The Morning Show arbejder typisk med abonnementsbaserede aftaler uden binding (fra 1.990 kr./md.), hvor man kan vælge mellem rådgivning, løbende drift eller en kombination med undervisning af teamet. Det gør det lettere at starte i det små og udvide, når setup og behov vokser.
Få en konkret vurdering af jeres tracking-setup
Hvis I vil vide, om server-side tracking vil give jer bedre og mere stabil måling, er det smart at starte med en kort gennemgang af jeres nuværende GA4, samtykke og konverteringssetup. Derfra kan man hurtigt vurdere, om gevinsten står mål med kompleksiteten, og hvilke events der bør prioriteres først.