Sådan bevæger data sig gennem serverside tracking

Serverside tracking flytter en del af databehandlingen fra den besøgendes browser til en server, du har kontrol over. Browseren sender for eksempel en hændelse om et produktbesøg til en servercontainer. Her bearbejder opsætningen oplysningerne, før den sender udvalgte data videre til et analyseværktøj. Fejl opstår i overgangen mellem systemerne: En hændelse kan nå frem til serveren uden at blive accepteret hos modtageren.

Der er derfor forskel på, om browseren har sendt noget, og om modtageren har registreret det korrekt. En vellykket netværksanmodning dokumenterer kun det pågældende led. Den fortæller ikke, om hændelsen indeholder den forventede valuta, eller om modtageren afviser et felt. Bed om at få vist samme hændelse ved indgangen til servercontaineren og efter behandlingen hos modtageren.

Serverdelen erstatter heller ikke automatisk målingen i browseren. Klik og andre brugerhandlinger kræver fortsat en webcontainer eller tilsvarende kode, som registrerer handlingen og sender oplysningerne. Et køb kan komme fra butikkens ordresystem, mens et klik på en størrelsesvælger kommer fra browseren. Tegn de faktiske dataveje op med hændelsens oprindelse og den komponent, der sender den videre, og læs mere om serverside tracking her.

Opsætning af serverside tracking med tydelige datagrænser

En opsætning med servercontainer kræver selve containeren og en taggingserver, der kører på en valgt hostingplatform. Containeren beskriver behandlingen af hændelserne, og servermiljøet udfører arbejdet. Forskellen får betydning, når en ændring virker i testen, men den publicerede løsning stadig bruger en tidligere version. Kontrollér den aktive konfiguration og det miljø, som hjemmesiden faktisk sender til.

Du skal også afgrænse, hvilke oplysninger serveren må sende videre til hver modtager. Servercontaineren kan validere og filtrere felter, før data forlader dit miljø. En analysemodtager behøver for eksempel ikke alle oplysninger fra en ordre. Når videresendelsen bygger på udtrykkeligt valgte felter, følger et nyt felt i ordresystemet ikke ubemærket med hele vejen ud.

Testmiljøet kræver sin egen afgrænsning. Havner udviklernes prøveordrer i den almindelige rapportering, ligner de rigtige køb og forstyrrer den efterfølgende fejlsøgning. Markér testtrafikken tydeligt, og aftal, hvor opsætningen skal stoppe den. Et separat servermiljø hjælper kun, hvis testbutikken rent faktisk sender dertil. En kopieret konfiguration kan stadig pege på den samme modtager som den aktive butik.

Kræver serverside tracking stadig samtykke?

Ja, serverside tracking ophæver ikke samtykkekravet for cookies og lignende teknologier til besøgsstatistik eller personaliserede annoncer. Digitaliseringsstyrelsens vejledning fastslår, at samtykket som udgangspunkt skal være på plads, før indsamlingen gennem disse teknologier begynder. Et serverkald ændrer transportvejen, men giver ikke tilladelse til at indsamle oplysningerne. Undersøg derfor, hvad browseren sender, allerede inden den besøgende har taget stilling i samtykkeløsningen.

Samtykkets status skal følge med gennem den relevante behandling. Hvis browseren stopper et annoncetag, mens servercontaineren fortsætter med at sende den samme hændelse til annonceformål, stemmer de to dele ikke overens. Test et afslag og et begrænset samtykke ved at undersøge de faktiske udgående kald fra serveren. Beskeden i browserens testværktøj viser ikke nødvendigvis, hvad serveren sender videre.

Samtykke skal også kunne trækkes tilbage, og den besøgende skal have vedvarende adgang til at ændre sit valg. Din opsætning skal kunne håndtere, at en tidligere tilladelse ikke længere gælder for den efterfølgende behandling. Afprøv et besøg, hvor du først accepterer og derefter ændrer valget, og kontrollér de udgående kald ved en ny sidevisning og en senere købshændelse.

Hændelsesidentitet afgør håndteringen af dubletter

Den samme ordre kan blive sendt fra browseren og fra butikkens ordresystem. Det kan være tilsigtet, men modtageren skal kunne genkende, at der er tale om samme hændelse, hvis den understøtter deduplikering. Et fælles hændelses-id er ofte en del af den mekanisme. Det hjælper ikke, at begge forsendelser har et id, hvis browseren og serveren danner hver sit.

Hændelsens identitet skal følge den konkrete handling gennem systemet. For et køb er ordresystemet det naturlige sted at fastlægge sammenhængen, mens andre handlinger kræver en anden løsning. Undersøg modtagerens krav til deduplikering, før du vælger formatet. Nogle opsætninger kræver, at hændelsesnavn og id matcher, og modtagerens tidsvindue kan have betydning for forsinkede forsendelser.

Genforsøg er en særskilt fejlkilde. Får serveren ikke et tydeligt svar, kan den forsøge at sende igen, selv om modtageren allerede har registreret hændelsen. Genforsøget bør bevare hændelsens oprindelige identitet, når modtagerens mekanisme kræver det. Test også, hvad der sker, når du genindlæser kvitteringssiden. Den må ikke uden videre skabe et nyt køb, blot fordi browseren igen viser den samme ordrebekræftelse efter en afsluttet betaling.

Feltdefinitioner bestemmer rapporternes indhold

To teknisk gyldige købshændelser kan beskrive forskellige beløb. Butikken kan sende ordretotalen inklusive fragt, mens analyseopsætningen forventer varebeløbet uden fragt. Ingen af delene udløser nødvendigvis en fejlmeddelelse. Rapporten får blot et andet indhold end forventet. Skriv præcist ned, hvad købsfeltet indeholder, og brug samme definition i browserens hændelse og ordresystemets forsendelse.

Valuta og datatyper kræver samme omhu. Et beløb sendt som tekst med dansk decimalkomma kan blive behandlet anderledes end et numerisk felt i det format, modtageren forventer. Den besøgende ser stadig dansk prisvisning, selv om transportformatet følger integrationens specifikation. Hold visningsformatet adskilt fra dataværdien, og kontrollér beløbet i den rå hændelse.

Personoplysninger kan også gemme sig i tilsyneladende tekniske felter. Datatilsynet beskriver blandt andet cookie-id og IP-adresse som oplysninger, der kan være personoplysninger, selv uden et navn. En sideadresse kan desuden indeholde oplysninger, som din opsætning ikke bør sende videre. Gennemgå hele adressen og dens parametre. Et filter på et særskilt e-mailfelt fjerner ikke en e-mailadresse, som allerede står i adressens forespørgselsdel.

Fejlsøgning kræver spor uden fulde datakopier

Når en hændelse forsvinder, skal du vide, hvor i kæden det skete. En brugbar log viser hændelsens tekniske reference og modtagerens svarstatus uden at gemme hele indholdet. Fuld logning af alle felter giver flere detaljer, men skaber også endnu et sted med oplysninger om besøgende. Vælg de felter, du konkret har brug for under fejlsøgningen, og fastlæg en slettefrist for loggen.

En afvist hændelse er ikke det samme som en hændelse, der aldrig blev sendt. Afvisningen kan skyldes et ugyldigt felt. Manglende afsendelse kan derimod være den korrekte følge af den besøgendes samtykkevalg. Vises begge situationer blot som manglende køb, bliver fejlsøgningen misvisende. Med særskilte statusser ser du forskellen uden at åbne hver enkelt hændelses fulde indhold.

Ændringer bør kunne spores til en bestemt udgivelse. Når du retter et feltnavn, skal du kunne sammenholde tidspunktet med de første hændelser, der bruger det nye navn. Gem en kort ændringsbeskrivelse sammen med containerens version. Ved næste fejl kan du undersøge den relevante udgivelse og sammenligne en hændelse fra før ændringen med en fra efter.