Spring til indhold
← Bloggen

Overvejer I server-side tracking til GA4? Start med problemet.

Serverside tagging

Server-side tracking er ikke det naturlige næste trin, bare fordi I allerede bruger GA4. Det er det rigtige næste trin, når I kan pege på et problem, som en servercontainer faktisk kan løse.

Min anbefaling er derfor enkel: Beskriv problemet før løsningen. Ellers får I mest af alt en dyrere måde at sende de samme uklare events på.

Hvad ændrer server-side tracking?

Ved almindelig browsertracking sender hjemmesiden data direkte til eksempelvis Google Analytics. Med server-side tagging går data først til en servercontainer, som I kontrollerer, og derfra videre til de valgte modtagere. Googles egen introduktion til server-side tagging beskriver klienter, tags og servercontainerens rolle i det forløb.

Det giver et kontrolleret mellemled. Her kan I validere, ændre og begrænse data, før de sendes videre. I kan også bruge et førstepartsdomæne og flytte noget arbejde væk fra browseren.

Men servercontaineren ser kun det, den modtager. Hvis et køb bliver registreret to gange i browseren, eller et lead mangler en klar definition, bliver fejlen ikke mere korrekt af at tage en tur gennem en server. Den får bare bedre infrastruktur.

Find den konkrete grund

Start med at skrive én eller flere grunde ned. De skal kunne efterprøves. Det kan eksempelvis være, at I vil:

  • sende færre oplysninger til en bestemt leverandør
  • validere parametre og værdier på ét sted
  • samle browser- og backendhændelser i en kontrolleret datastrøm
  • gøre driften af tags og destinationssystemer mere ensartet
  • forbedre robustheden i en konkret, dokumenteret browsersituation

»Vi vil have bedre data« er ikke præcist nok. Hvilke data? Bedre på hvilken måde? Og hvilket andet system skal vise, om det lykkedes? Uden de svar kan I ikke afgøre, om server-side tracking gav en reel forbedring.

Beslut, hvad serveren må modtage

Et førsteparts-endpoint gør ikke data anonyme, og det ændrer ikke formålet med indsamlingen. Gennemgå derfor hvert vigtigt event og dets parametre, inden I bygger.

  • Hvilken brugerhandling beskriver eventet?
  • Hvilke felter er nødvendige for det konkrete formål?
  • Hvilke felter skal fjernes eller omdannes?
  • Hvilke platforme må modtage eventet?
  • Hvad skal ske ved hvert samtykkevalg?
  • Hvor længe findes data i logs, køer og backups?

Den gennemgang er også en god anledning til at opdage oplysninger, som aldrig burde være endt i en analyseforespørgsel. De er lettere at stoppe før implementeringen end at forklare bagefter.

Test ét helt forløb

Vælg én vigtig handling, for eksempel et gennemført køb eller en indsendt formular. Følg den hele vejen fra brugerens klik til rapporten:

  1. Kontrollér eventet og parametrene i browseren.
  2. Se præcis, hvad servercontainerens klient modtager.
  3. Kontrollér de ændringer, servercontaineren foretager.
  4. Se hver udgående forespørgsel og dens svar.
  5. Kontrollér hændelsen i destinationssystemet.
  6. Sammenlign med ordren, bookingen eller formularen i kildesystemet.

Gentag testen med de relevante samtykkevalg, browsere og fejlscenarier. En grøn preview-skærm i GTM er nyttig. Den er ikke alene et bevis på, at målingen er korrekt.

Browserbegrænsninger kræver præcise løfter

Safari begrænser allerede flere former for lagring og tracking. WebKit beskriver blandt andet fuld blokering af tredjepartscookies og tidsgrænser for visse former for scriptoprettet lager i sin oversigt over tracking prevention. Den konkrete virkning afhænger af domæner, trafikvej og browseradfærd.

Lov derfor ikke, at server-side tracking »løser Safari« eller gør målingen cookieløs. Test det konkrete setup, og beskriv den forbedring, I faktisk kan dokumentere. Server-side tracking er heller ikke en genvej uden om samtykke.

Drift er en del af løsningen

Når servercontaineren er et led i målingen, skal nogen eje den. Aftal overvågning, omkostninger, adgang, opdateringer, logning og handling ved fejl. Skriv også ned, hvem der må tilføje en ny destination.

Start med problemet og ét vigtigt event. Kan I dokumentere en meningsfuld forbedring fra kilde til rapport og samtidig drive løsningen forsvarligt, har I et grundlag for at udvide. Hvis ikke, har piloten stadig gjort sit arbejde: Den har sparet jer for at flytte hele rodet op i skyen.

Andreas Solgaard

Andreas Solgaard driver Datamine og hjælper virksomheder med tracking, AI og data. Han bygger digitale løsninger, integrerer AI i arbejdsgange og holder workshops.