Indholdsfortegnelse
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.
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)
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.
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?
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), 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
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 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 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 kan jeg anbefale at se disse videoer:
