Serverside tracking bliver konkret, når du skal undersøge, hvorfor en betalt ordre mangler i dit analyseværktøj, eller hvorfor det samme køb bliver registreret to gange. I stedet for kun at sende oplysninger direkte fra browseren til analyseværktøjet lader du en server modtage og behandle hændelserne først. På den måde kan du styre, hvilke oplysninger der sendes videre. Det kræver dog klare aftaler om hændelser, samtykke og kontrol. Et praktisk sted at begynde er at følge én ordre hele vejen fra betaling til rapport.

Begynd med de hændelser, du faktisk bruger

En opsætning bliver hurtigt uoverskuelig, hvis du registrerer hvert klik uden at vide, hvad oplysningerne skal bruges til. Begynd med de handlinger, der indgår i dine daglige beslutninger. For en webshop kan det være produktvisning, tilføjelse til kurv, påbegyndt betaling og gennemført køb. For en virksomhed med en tilbudsformular kan det i stedet være en indsendt henvendelse. Hændelserne kan behandles på serveren, før de sendes til analyseværktøjet; klik her for at se, hvordan den behandling foregår med serverside tracking.

Beskriv hver hændelse med almindelige ord, før du vælger tekniske feltnavne. Tæller et køb som gennemført, når kunden åbner kvitteringssiden, eller først når betalingen er bekræftet i ordresystemet? Det er ikke nødvendigvis det samme tidspunkt. Kunden kan lukke fanen efter betalingen, og kvitteringssiden kan blive genindlæst.

Notér også, hvilke oplysninger der skal følge med. Ved et køb vil ordrenummer, beløb og valuta ofte være relevante. Aftal, hvordan moms, fragt og rabatter skal indgå i beløbet. Hvis ordresystemet viser 625 kr., mens analyseværktøjet viser 500 kr., kan forskellen skyldes moms snarere end en teknisk fejl. Det skal være afklaret, før I begynder at sammenligne rapporterne.

Hvor skal serverside tracking hente sine oplysninger?

Betegnelsen serverside tracking fortæller ikke i sig selv, hvor en hændelse opstår. Browseren kan sende en hændelse til din server, som derefter sender udvalgte oplysninger videre. Ordresystemet kan også give besked direkte, når en betaling bliver registreret. De to veje afhænger af forskellige dele af opsætningen, og det har betydning for den daglige drift.

Kommer hændelsen fra browseren, kan den stadig blive påvirket af, at siden lukkes, forbindelsen afbrydes, eller den nødvendige kode ikke bliver indlæst. En server som mellemled fjerner ikke automatisk de problemer. Kommer beskeden fra ordresystemet, skal du til gengæld tage højde for forsinkede betalinger, annulleringer og beskeder, der bliver sendt igen efter en fejl.

Vælg derfor en tydelig kilde til hver handling. Lad eksempelvis ordresystemets betalingsbekræftelse være grundlaget for køb, mens browseren registrerer produktvisninger. Hvis det samme køb sendes ad begge veje, skal opsætningen følge modtagerens metode til dubletkontrol. Det kræver typisk en fælles hændelsesidentifikator. Et ordrenummer i et vilkårligt felt er ikke nødvendigvis nok til at forhindre dobbeltregistrering.

Lad samtykket følge med hele vejen

En server er ikke en genvej uden om reglerne om cookies og personoplysninger. Kravene afhænger blandt andet af formålet, hvilke oplysninger du behandler, og om der lagres eller tilgås oplysninger på brugerens udstyr. Flytter du behandlingen fra browseren til en server, skal du stadig kunne forklare, hvad der sker, og på hvilket grundlag.

I praksis skal brugerens valg styre de relevante dataoverførsler. Hvis en besøgende afviser statistik eller markedsføring, må serveren ikke blot videresende de samme hændelser til de pågældende formål, som hvis der var givet samtykke. Beskriv også, hvordan opsætningen skal reagere, når brugeren ændrer sit valg under besøget.

Gennemgå derefter de enkelte felter. En sideadresse kan indeholde en e-mailadresse eller andre personoplysninger i sine parametre, selv om ingen bevidst har oprettet et særskilt felt til dem. Fjern unødvendige oplysninger, før de sendes videre. Hashning gør ikke automatisk personoplysninger anonyme. Afklar desuden, hvem der har adgang, hvor længe oplysningerne gemmes, og hvilke aftaler der skal indgås med leverandørerne. Søg konkret juridisk rådgivning, hvis behandlingsgrundlaget eller ansvarsfordelingen er uklar.

Test serverside tracking med en rigtig arbejdsgang

En teknisk forhåndsvisning kan vise, at en hændelse bliver sendt, men ikke i sig selv, om hele forløbet virker. Lav en testordre med en vare, en rabatkode og en leveringspris, så du kan kontrollere de felter, der ofte giver forskelle. Brug helst et testmiljø eller en tydeligt markeret testordre, som håndteres efter den normale procedure.

Følg derefter hændelsen gennem hvert led. Kontrollér først, at kilden opretter den. Se så, om serveren modtager den med korrekt tidspunkt, valuta og identifikator. Kontrollér til sidst, at modtageren accepterer den. At en besked er sendt, betyder ikke nødvendigvis, at den er godkendt. Selv en accepteret hændelse kan være et stykke tid om at blive synlig i standardrapporten.

Gentag testen med afvist samtykke, genindlæsning af kvitteringssiden og en afbrudt betaling. Afprøv også, hvad der sker, når den samme besked leveres to gange. Skriv det forventede resultat ned før hver test. Så kan du skelne mellem en manglende hændelse, der skyldes en fejl, og en, som netop ikke skal registreres.

Giv den løbende kontrol en fast plads

Når opsætningen er i drift, skal nogen have ansvaret for at holde øje med den. Det behøver ikke være en omfattende daglig opgave. En fast ugentlig kontrol kan tage udgangspunkt i tre spørgsmål: Modtages de forventede hændelser, bliver nogen afvist, og er der kommet nye felter med i overførslerne? Ændringer i betalingsforløbet eller samtykkeløsningen bør følges op med en særskilt kontrol.

Sammenlign køb i analyseværktøjet med betalte ordrer fra samme periode, men forvent ikke automatisk, at tallene er ens. Samtykkevalg, tidszoner, behandlingstid og forskellige definitioner af omsætning kan give forskelle. Annonceværktøjers tilskrivning af køb er desuden noget andet end en optælling i ordresystemet. Undersøg derfor ændringer i et kendt mønster frem for at betragte enhver afvigelse som en fejl.

Aftal, hvem der reagerer på fejl, og hvor de bliver dokumenteret. En brugbar fejlbesked indeholder tidspunkt, hændelsestype og en teknisk identifikator uden unødvendige personoplysninger. Notér også ændringer i opsætningen med dato og formål. Hvis antallet af registrerede køb falder efter en opdatering af betalingsmodulet, har den ansvarlige dermed et konkret sted at begynde fejlsøgningen.