Indholdsfortegnelse
TL;DR
Med en god Server-side tracking setup, kan du spore op til 21,87% flere hændelser end med en ren client-side tracking.


Dette kan 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.
Har du brug for hjælp med implementering, eller forbedringer til dit Server-side setup? Så kan du altid sende mig en mail.
Introduktion til Server-side tracking (server-side tagging)
Server-side tracking/tagging er (blandt andet) en metode til at spore brugernes hændelser på en hjemmeside. Denne metode er blevet mere udbredt på det sidste og det skyldes primært ændringer i hvordan forskellige browsere håndterer privacy og tracking.
Det er særligt håndteringen af cookies (heriblandt WebKits fokus på privacy, med bl.a. deres IntelligentTrackingPrevention), der har sat skub i brugen af Server-Side tracking.
Her kan du få et overblik om hvordan forskellige browsere håndterer cookies.
Modsat Client-side tracking, så er server-side mindre afhængig af en browser (eksempelvis Safari) til at videresende informationer til en 3.parts platform (som FB eller Google).
Dette giver en række fordele når det eksempelvis kommer til cookie-levetid, sidehastighed, mere kontrol over hvilket data man deler samt bedre forudsætninger til at undgå ad-blockers og andre browser forhindringer.
I Server-side tracking, bliver dataen sendt fra en server til en anden server, og er ikke nødvendigvis afhængig af en browser som mellem-led.

Med andre ord, så er du langt mindre afhængig af hvordan forskellige browsere håndterer og videreformidler dataen.
At flytte tracking fra client-side (browser afhængig) til server-side (delvis browser uafhængig) har mange fordele, men der er mange ting, som man skal være opmærksom på og det er ikke uden kompleksitet.
Jeg har prøvet at forklare koncepterne på et niveau hvor alle kan være med, så læs videre og bliv klogere på Server-side tracking.
Forskellen mellem Client-side og Server-side
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), så skal du også sørge for at denne cloud server peger på en subdomæne af din hjemmeside, det gør du gennem din domænes DNS indstillinger (så den eks peger på ss.dinhjemmeside.dk).
Server-side Cons
Server-side lyder jo umiddelbart fantastisk, men der er ting som du skal være opmærksom på.
1. Det er ikke gratis (i de fleste tilfælde)
Der er oftest hosting omkostninger forbundet med at at opsætte en Cloud server. Prisen varierer afhængig af forbrug men regn minimum med en omkostning på ca. 200 kr. om måneden.
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.




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).


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).


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.


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).


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.


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.
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.
Igennem Google Cloud er prisen ca. 858 dkk pr. måned. (baseret på deres standard anbefaling af du køber 3 x instances af 286 dkk hver).
Gennem Stape kan du muligvis nøjes med at betale 143 dkk pr.måned (op til 500 000 requests).
Det plejer at være rimeligt for en hjemmeside af en mellem størrelse.
Uanset så skal man være opmærksom på at der er en månedlig omkostning.
Men det er 100% pengene værd.
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 kan jeg anbefale at se disse videoer: