Den Ultimative Server-side Tracking Guide (2026)

Indhold

• Introduktion til Server-side tracking
• Hvad er server-side Tracking?
• Forskellen mellem Client-side og Server-side Tracking
• Opsætning af Server-side Google Tag Manager
• GA4 Server-side gennem Google Tag Manager
• Hvad kan du sende server-side?
• Meta Conversions API gennem ssGTM
• Længere cookie-levetid: sådan slår du Safari ITP
• Google Tag Gateway vs. server-side GTM
• Er besværet det værd?
• Debugging og overvågning
• Hvor meget koster Server-side tracking (Google Tag Manager)?
• Consent Mode v2: et krav, ikke bare “GDPR-venligt”
• Er server-side tracking GDPR-kompatibelt?
• Andre ressourcer og video guides

Introduktion til Server-side tracking

Server-side tracking, eller server-side tagging, er en metode til at spore brugernes handlinger på en hjemmeside ved at flytte dataindsamling fra brugernes browsere til en server. 

Det har vundet stigende popularitet på grund af nye teknologiske og juridiske udfordringer ved traditionel client-side tracking.

En kort afklaring, for der er meget forvirring om emnet: Google endte med ikke at fjerne tredjeparts-cookies i Chrome, og Privacy Sandbox blev lukket ned i oktober 2025. Cookies forsvinder altså ikke fra Chrome lige nu. Men presset på client-side tracking er stadig meget reelt. Det kommer bare fra Safari og Firefox (ITP), fra adblockers og fra samtykke, ikke fra en Chrome-deadline. Det er præcis dét, server-side tracking hjælper på.

Med en god server-side tracking-opsætning kan du spore helt op til 50 % flere hændelser end med en ren client-side tracking.

Server-side tracking åbner også for nye muligheder inden for API-integrationer og databerigelse, hvilket kan forbedre din datakvalitet og effektiviteten af dine marketinginitiativer. 

Her ser du et eksempel som viser data fra Meta Events Manager (med en stigning på 21,87% flere hændelser målt)

Eksempel fra en Server-side implementering og forskellen i antal hændelser ud fra Facebook Events Manager

Og her ser du et eksempel fra en Google Ads konto med en stigning på 85,05% i målt konverteringsværdi, når man sammenligner server-side tracking med andre metoder i samme periode.

85,04% stigning i Google Ads conv. value ved hjælp af GTM server-side + Enhanced Conversions (når man sammenligner med importeret transactions fra GA)

Med andre ord  kan Server-side tracking i sidste ende resultere i bedre resultater på dine performance kanaler (eks. Meta, Google, TikTok etc.), samt give dine analyseværktøjer og CRM systemer (eks. GA4 og Klaviyo) mere data til at træffe bedre beslutninger.

Hvad er server-side Tracking?

Overblik af en Server-side opsætning. Kilde: https://stape.io/blog/what-is-server-side-tracking

Server-side tracking er en teknologi, der kan integreres i din eksisterende tracking-løsning, som eksempelvis Google Tag Manager, for at imødekomme tekniske begrænsninger i forbindelse med dataindsamling.

Dataen behandles direkte på en server frem for på brugernes enheder, hvilket giver en mere robust og fleksibel løsning.

Denne metode reducerer afhængigheden af browsere, forbedrer datakvalitet og giver mulighed for bedre kontrol over, hvilke data der deles. Samtidig kan server-side tracking omgå ad-blockers og forskellige browserrestriktioner (som eks. ITP i Safari browsere).

Forskellen mellem Client-side og Server-side Tracking

For at kunne forklare hvordan server-side tagging fungerer, så er det vigtigt at forstå (læs: prøve at forstå 🫣

🫣

) hvordan Client-side (den tracking, som du kender) fungerer.

Client-side kort forklaret:

Når en hjemmeside loader, så loader alle de JavaScript kodestykker som der er tilknyttet på siden (yes, de lange kyrilliske alfabet lignende tekster som du kopierer og indsætter i eksempelvis Google Tag Manager eller sender til din udvikler – det kunne eksempelvis være Facebooks Pixel eller Google Analytics).

Anyways, koden bliver indlæst af din browser, den loader, indsamler noget data og sender den videre til en anden destination. 

Sammen med den hændelsesdata som koden indsamler som eks. når en sidevisning sker, så er der andre parametre som den også bruger.

Det kan eksempelvis være hvilken enhed der bliver brugt, og i nogle tilfælde meget mere som bliver lagret i en eller flere cookies.

Lad os tage Facebooks pixel som eksempel:

Facebook placerer to cookies på din browser, en fbp cookie og en fbc cookie (“førsteparts” cookies gennem JavaScript).

Den ene fortæller noget om hjemmesiden hvor pixel er placeret, den anden lagrer den unikke ‘Click id’ som følger ved alle kliks fra Facebook til en anden hjemmeside (kendetegnet i url’en med  ‘fbclid’).

Det er bl.a. disse informationer som Facebook bruger til at kunne spore hændelser, samt attribuere hændelser til bruger og derved annoncerne.

I dette scenarie er dataen meget afhængig af browseren. Da det er browseren der i høj grad kan bestemme hvilke informationer deles mellem browser -> pixel -> fb, samt hvor lang tid disse cookies skal leve.

Browseren kan eksempelvis både maskere denne ‘Click id’ samt begrænse levetiden på disse cookies, hvilket kan gøre det sværere for virksomheder at måle output af deres annonceringskroner.

Server-side kort forklaret:

Med Server-side setup, så kan du netop undgå nogle af disse begrænsninger som browseren skaber. Målet er at undgå at bruge browseren som eneste bindeled.

Så når du opsætter en Server-side setup, så sender du det data  som du indsamler fra din egen server til eks. Facebooks  server (et eksempel på en ren Server-side setup er når man eksempelvis bruger en plugin til Woocommerce eller Shopify, der implementerer Facebooks Conversions API, her deler du data direkte fra din CMS til Facebook).

En direkte Server til server forbindelse, er klart at foretrække, men langt mere krævende at sætte op, da kompleksitet varierer fra CMS til CMS, samt ville i langt de fleste tilfælde kræve udviklingsressourcer og vedligeholdelse (medmindre der findes 1-klik plugins, der kan klare dette for dig).

Problemet med plugins og 1-klik setups, er at de ikke nødvendigvis virker for alle. Så kræver dit setup noget fleksibilitet eller ændringer, så skal man finde en anden vej.

På samme måde som Google Tag Manager, kan være en løsning til at samle alle dine tracking scripts client-side, så kan Google Tag Manager server-side være svaret.

Server-side Google Tag Manager (ssGTM)

En måde hvorpå man kan implementere Server-side tracking er at bruge Google Tag Managers server-side container.

Hvis du har brugt Google Tag Manager før, så ville du også hurtigt forstå hvorfor det kan give mening at samle alt tracking i et tag management system.

Server-side Google Tag Manager kræver en cloud server (altså en form for hosting på samme måde som når du køber hosting til din hjemmeside). Du kan købe en cloud server direkte hos enten Google Cloud Platform, AWS eller gennem en underleverandør som eksempelvis Stape.

For at få et bedre setup (i forhold til cookie-levetid) skal du også sørge for, at din cloud server peger på et subdomæne af din hjemmeside. Det gør du gennem din domænes DNS-indstillinger, så den lever på eks. ss.dinhjemmeside.dk. I dag bruger de fleste Stape- og Cloud Run-opsætninger et CNAME (og eventuelt en AAAA/IPv6-record) med et CDN foran, frem for kun en enkelt A-record.

Server-side Cons

Selvom server-side tracking har mange fordele, så kan det være en kompleks og teknisk tung proces at implementere.

Det kræver også en vedvarende investering i serverhosting og teknisk vedligeholdelse.

Derudover er omkostningerne og opsætningstiden ofte uigennemsigtige.

1. Det er ikke gratis (i de fleste tilfælde)

Der er oftest hosting-omkostninger forbundet med en server-side opsætning. Prisen varierer efter forbrug, men den billige indgang (eks. Stape Pro) starter omkring 120-150 kr. om måneden. Vil du i stedet køre selv på Google Cloud Run, skal du regne med mere. Til gengæld findes der nu også en gratis mellemvej for Googles egne tags, Google Tag Gateway (mere om den længere nede).

2. Teknisk- og tidskrævende at implementere

Selvom der er mange fordele, så er det et forholdsvis nyt koncept indenfor mainstream tracking, så det er langt fra alle der forstår sig på det, og måske endnu færre der kan lave en ordentlig implementering.

3. Mulige fremtidige begrænsninger

Det er ingen hemmelighed at her er der tale om en kat-mus situation. Så lige nu, virker det fantastisk, men vi ved ikke hvor længe, da der kan opstå nye begrænsninger (her tænker jeg særligt på WebKits, og hermed Safari, iOS osv.).

Opsætning af Server-side Google Tag Manager

Hvis ikke du allerede har en almindelig Google Tag Manager konto, så skal du starte med at oprette en, hvilket er ret ligetil. 

For at oprette en Server-side container (med andre ord en Google Tag Manager, som skal bruges til dine Server-side tags) skal du blot tilgå ‘Admin’ fanen, og klikke på + knappen

Her vælger du ‘Server’ som target platform.

Derefter skal du tage stilling til, om du vil bruge en server  fra Google Cloud Platform (her kræver det at du sætter en op, og vælger du denne metode kan jeg anbefale at se på Simo’s GCP guide), eller om du vil bruge en anden udbyder.

Jeg kan personligt anbefale at vælge en EU server fra Stape.io, medmindre man allerede har en GCP setup og er godt inde i det.

Vælger du Stape eller lignende, skal du blot kopiere og gemme din ‘Container Config’ id, og så bare trykke på ‘Close’.

Nu skal du angive hvor din ssGTM lever, altså angive den url hvor din server bliver hostet.

Det gør du ved at gå ind under ‘Admin’ og så ‘Container Settings’.

Selve opsætningen af Stape er meget ligetil (opret en bruger, følg vejledningen, tilføj din container ID).

Du får en url af Stape (eller GCP) når du køber en server, men inden du bare bruger den url som de automatisk genererer for dig, så sørg for at forbinde det til en subdomæne af din domæne (så din Server lever på eks ss.dindomæne.dk) 

Med andre ord, skal du tilgå dine DNS indstillinger (hos din hjemmesidehost) og lave en A record, hvor du peger IP adressen til en subdomæne.

GA4 Server-side gennem Google Tag Manager

Der er mange forskellige måder at gøre det på, men her får du den nemmeste hvis du allerede har en Server side Google Tag Manager Container (bemærk at dette er blot et eksempel, og det kan sagtens

I din web Google Tag Manager container, tilføj eller ret i din GA4 configuration tag. 

Du skal tikke “Send to server container” og tilføje url’en på din Server-side GTM (valgfrit om du vil sende page views med din config tag, hvis du fjerner hak fra ‘send a page view when this configuration loads’, så skal du lave en ny GA4 tag, der sender page view events.

Skal du sende andre events end blot Page View, så skal du også lave disse i din web google tag manager container. 

Fordi de er tilknyttet til din configuration tag, behøver du ikke at foretage dig andet end at sende eventet med de nødvendige parametre.

Opsætning af GA4 configuration tag i web GTM

Opsætning af GA4 Purchase event tag i web GTM

Nu skal du åbne din Server-side Google Tag Manager container.

Her skal du klikke på ‘Clients’ og sørge for at du har en GA4 client. Hvis den ikke allerede er der, så tilføj en GA4 client (ved at trykke på ‘New’ og vælge GA4).

Opsætning af GA4 Client i ssGTM

Nu skal du klikke på ‘Tags’, klikke på ‘New’ og vælge en Google Analytics 4: GA4 tag. 

Her skal du blot indsætte din GA4 Measurement ID og vælge variablen ‘Event Name’ (da du kommer til at sende forskellige events). 

Opsætning af GA4 Client i ssGTM

Nu skal du klikke på ‘Variables’ og lave en ny variabel. Her vælger du ‘Client Name’, det er noget som vi skal bruge til at lave en trigger.

Opsætning af Client Name variabel i ssGTM

Sidst men ikke mindst, skal du lave en Trigger. Klik på ‘Trigger’ i menuen til venstre og så opret en Custom trigger.

Sæt hak i ‘Some Events’, og vælg Client Name skal være lig med GA4 (se billedet nedenunder).

Opsætning af GA4 trigger i ssGTM

Sidst men ikke mindst, så skal du knytte din trigger til din tag.

For at tjekke at du sender hændelser til GA4 korrekt, så kan du både åbne GA4s realtime report (eller debug mode), samt lave en preview på din Server-side GTM.

Når du laver previews i ssGTM, så åbner den et nyt vindue, men ikke automatisk din hjemmeside. Så du skal i en ny fane tilgå din hjemmeside for at kunne se aktivitet i din preview vindue.

Preview mode i ssGTM

For at kunne se hvilken forbedring Server-side GA4 har skabt, kan du sammenligne antal Purchases målt i GA4 med din backend tal. 

Forskellen skulle meget gerne være mindre, end med client-side implementering.

Hvad kan du sende server-side?

Når din server-side container først står, bliver den et centralt knudepunkt, du kan sende data videre fra til en lang række platforme:

• GA4 (som vist ovenfor).
• Meta (Facebook) Conversions API (CAPI), den absolut hyppigste grund til at folk bygger server-side. Mere om den lige nedenfor.
• Google Ads konverteringer og Enhanced Conversions.
• TikTok Events API, Pinterest, Snapchat og LinkedIn CAPI, typisk gennem færdige Stape-skabeloner.
• Databerigelse og webhooks: slå data op i eks. Firestore eller BigQuery, send offline-konverteringer fra dit CRM, eller skriv til Google Sheets.

Meta Conversions API gennem ssGTM

Meta CAPI er for de fleste den vigtigste gevinst ved server-side. I stedet for kun at sende Facebook-events fra browseren (hvor Safari, adblockers og manglende samtykke spiser en stor del), sender du dem server-til-server fra din egen container.

Nøglen er deduplikering. Du sender typisk det samme event både client-side (pixel) og server-side (CAPI) og giver dem et fælles event_id. Meta forstår så, at det er den samme hændelse, og tæller den kun én gang. Resultatet er flere matchede events uden dobbelttælling, som i eksemplet med +21,87% længere oppe.

Længere cookie-levetid: sådan slår du Safari ITP

En af de mest konkrete gevinster ved server-side er cookie-levetid. Safaris ITP kapper levetiden på cookies sat med JavaScript til 7 dage, og helt ned til 24 timer, hvis brugeren kom via et annoncelink med parametre i url’en.

Når din server i stedet sætter cookien som en almindelig HTTP-cookie fra dit eget subdomæne, rammer den ikke den samme begrænsning. Det betyder længere attribueringsvinduer og færre “nye” brugere, der i virkeligheden er tilbagevendende. Stape har værktøjer som Cookie Keeper og en Custom Loader (der serverer selve GTM-scriptet fra dit eget subdomæne), som hjælper yderligere mod adblockers.

Google Tag Gateway vs. server-side GTM

Det her forvirrer mange i 2026, så lad os skille det ad.

Google Tag Gateway (tidligere kaldt first-party mode) er en gratis funktion, hvor dine Google-scripts (gtag/GTM) serveres fra dit eget domæne i stedet for googletagmanager.com. Det hjælper mod ad- og script-blockers og forbedrer målingen af Google-produkter. Men det gælder kun Googles egne tags.

Server-side GTM er den fulde løsning: en container på din egen server, hvor du kan sende data videre til en hvilken som helst platform (Meta, TikTok osv.), berige data og styre præcis, hvad der bliver delt.

De to udelukker ikke hinanden. En moderne opsætning kombinerer dem ofte: Tag Gateway til at loade Google-scripts first-party, og server-side GTM til den tunge databehandling.

Er besværet det værd?

Server-side er ikke for alle. En simpel tommelfingerregel:

• Ja, sandsynligvis: du bruger reelle penge på paid media (Meta, Google, TikTok), og/eller en stor del af din trafik er Safari/iOS. Så tjener bedre data typisk investeringen hjem.
• Måske ikke endnu: du har lavt annoncebudget og få konverteringer. Så er en solid client-side opsætning med Consent Mode ofte nok til at starte med.

Debugging og overvågning

Ligesom i den almindelige GTM kan du bruge Preview mode på din server-container til at se, hvad der kommer ind, og hvilke tags der affyrer. Derudover bør du holde øje med dine requests (så du ikke bliver overrasket over regningen) og huske at skrue ned for logging på Cloud Run, hvis du kører selv, da det ellers er en af de største skjulte omkostninger.

Hvor meget koster Server-side tracking (Google Tag Manager)?

Prisen på “hosting” af din server, som skal bruges til din Google Tag Manager Server-side setup afhænger af antal “requests”. 

Med andre ord, hvor meget trafik og hvor mange hændelser du sender igennem.

Google Cloud (Cloud Run): server-side GTM kører i dag på Cloud Run (App Engine er den gamle måde). Google anbefaler 2-3 kørende instanser, og en realistisk produktionspris ligger på ca. 45 USD pr. instans, altså cirka 90-135 USD om måneden som udgangspunkt. Vær særligt opmærksom på logging, som let kan lægge ekstra oveni (regn med op mod 100 USD pr. 500.000 requests, hvis du lader alt logging stå til). Det kan heldigvis skrues ned.

Stape: den nemme vej. Stape har en gratis plan op til 10.000 requests om måneden. Derfra koster Pro omkring 17 USD om måneden (op til 500.000 requests), Business omkring 83 USD (5 mio.) og Enterprise omkring 167 USD (20 mio.). For de fleste små og mellemstore sites er Pro-planen rigelig.

(Priserne er cirka-tal fra midten af 2026 og kan ændre sig, så tjek altid Stape og Google Cloud for de aktuelle satser.) 

Skal du vælge? Stape er langt den nemmeste og billigste indgang. Cloud Run giver mere kontrol, men kræver mere teknisk arbejde og overvågning af omkostninger. Der findes også en tredje vej, hvor man selv hoster i Docker (eks. på Hetzner eller OVH), men det er kun for de teknisk stærke.

Uanset så skal man være opmærksom på at der er en månedlig omkostning. 

Men det er 100% pengene værd.

Consent Mode v2: et krav, ikke bare “GDPR-venligt”

Mange tror, at server-side i sig selv gør tracking lovligt. Det passer ikke. Server-side flytter, hvor data behandles, men du skal stadig have styr på samtykke.

Siden marts 2024 kræver Google, at du sender Consent Mode v2-signaler, når du bruger Google Ads eller Google Analytics på EU/EØS-trafik. Consent Mode v2 tilføjer signalerne ad_user_data og ad_personalization, og de skal også respekteres i din server-side opsætning (consent-aware tagging). Uden dem mister du remarketing og en stor del af din data på de brugere, der siger nej.

Kort sagt: server-side og Consent Mode v2 er to ting, du skal have styr på hver for sig, men de spiller sammen.

Er server-side tracking GDPR-kompatibelt?

Server-side tracking kan være GDPR-kompatibelt, hvis det implementeres korrekt. 

Data behandles på en server, som du har adgang til, hvilket giver bedre kontrol og sikkerhed (du kan eksempelvis bestemme blandt andet, hvor serveren bliver hostet henne eks. i EU).

Dette kan bestemt hjælpe med at overholde GDPR-krav.

Om noget er Server-side eller client-side er i sig selv ikke det vigtigste.  

Det vigtigste er at sikre lovligt grundlag for databehandling, indhente gyldigt samtykke og minimere dataindsamlingen i overensstemmelse med reglerne.

Er du nået hertil?

Damn! Tillykke det i sig selv er ret hardcore.

Andre ressourcer og video guides

Jeg kan også anbefale at læse denne yderst fyldestgørende, og mere teknisk guide fra Simo Ahava.

Derudover er Stapes egen 2026-guide til server-side tracking og Analytics Manias guide til server-side tagging begge stærke og opdaterede.

Derudover kan jeg anbefale at se disse videoer: