Serverside tracking bliver konkret, når du sidder med gårsdagens ordrer i den ene fane og en rapport med et andet omsætningstal i den anden. Forskellen kan skyldes andet end selve sporingen: returneringer, tidszoner, samtykke eller forskellige måder at opgøre salg på. Med et serverbaseret mellemled kan du styre, hvilke hændelser der sendes videre, og hvordan de behandles. Men først skal du beslutte, hvad tallene skal bruges til. Ellers flytter du blot uklarhederne fra browseren til serveren.
Giv serverside tracking en konkret arbejdsopgave
Begynd med den situation, der skaber ekstra arbejde. Måske bruger du hver mandag tid på at forklare, hvorfor annonceværktøjet viser en anden omsætning end ordresystemet. Eller måske bliver et køb registreret to gange, når kunden genindlæser kvitteringssiden. Det er to forskellige problemer, som kræver hver sin undersøgelse. Formulér derfor en præcis opgave. Det kan eksempelvis være, at et betalt køb kun må udløse én købshændelse hos hver relevant modtager.
Serverside tracking betyder i denne sammenhæng, at hændelsesdata behandles på en server, før de eventuelt sendes til analyseværktøjer eller annonceplatforme. Data kan komme fra browseren, ordresystemet eller begge steder. Serveren ved ikke automatisk, hvad der er et gyldigt salg. Den følger de regler, du har sat op. Aftal derfor også, hvem der afgør, hvilke ordrestatusser der skal udløse en hændelse. Den beslutning bør træffes af en person, der kender betalingsforløbet, og ikke alene af den, der opsætter sporingen.
Fastlæg, hvad et køb og et beløb betyder
En ordre på 800 kr. kan optræde med forskellige beløb i forskellige systemer. Ét sted indgår fragt, et andet sted er den trukket fra. Moms kan være med i den ene rapport og udeladt i den anden. Før du leder efter tekniske fejl, skal definitionerne derfor være skrevet ned. Beslut, om købsværdien skal omfatte moms og fragt, og hvordan rabatter skal indregnes. Felterne i dataopsætningen skal afspejle de valg.
Tidspunktet kræver samme præcision. En ordre kan være oprettet klokken 23.58, selv om betalingen først bliver bekræftet efter midnat. Hvis ordresystemet bruger oprettelsestidspunktet, mens analyseværktøjet bruger betalingstidspunktet, havner salget på forskellige datoer. Vælg en fast hændelse som grundlag, og dokumentér tidszonen. Skeln desuden mellem faktisk omsætning og den omsætning, et annonceværktøj tilskriver en annonce. Sidstnævnte afhænger også af værktøjets tilskrivningsregler og den periode, det måler over. Selv korrekt overførte køb giver derfor ikke nødvendigvis identiske tal i alle rapporter.
Brug ordre-id til at undersøge dubletter
Når samme køb sendes fra både browseren og serveren, kan modtageren i nogle opsætninger genkende de to hændelser som det samme køb. Det kræver, at modtagerens regler for dubletkontrol bliver fulgt. Et fælles hændelses-id kan være nødvendigt, men feltnavne, tidsfrister og øvrige krav varierer. Antag derfor ikke, at et ordre-id alene løser problemet. Kontrollér kravene hos hver modtager, og hold ordre-id og hændelses-id adskilt i dokumentationen, hvis de har forskellige funktioner.
Følg derefter et enkelt køb gennem hele forløbet. Find tidspunktet for betalingen, browserens eventuelle afsendelse, serverens modtagelse og svaret fra modtagersystemet. Genindlæs også kvitteringssiden, og undersøg, hvad der sker, når serveren modtager samme besked igen. Nogle betalings- og ordresystemer sender beskeder igen, hvis de ikke får den forventede kvittering. Løsningen skal kunne håndtere gentagelser uden at behandle dem som nye salg. Gem kun de oplysninger, der er nødvendige for fejlsøgningen, og begræns adgangen til dem. Serverbaseret behandling af hændelsesdata er også emnet på https://serverside-tracking.dk/
.
Lad samtykke følge data gennem serverside tracking
At flytte behandlingen til en server fjerner ikke kravene til samtykke, information eller behandlingsgrundlag. Reglerne afhænger blandt andet af formålet, oplysningerne og den konkrete tekniske løsning. Hvis din opsætning kræver samtykke til en bestemt måling eller videregivelse, skal serveren respektere valget. Den må ikke blot sende hændelsen videre, fordi browserens begrænsninger ikke længere står i vejen. Samtykkestatus skal kunne knyttes til den relevante behandling og kontrolleres dér, hvor data sendes videre.
Afprøv særskilt et besøg uden samtykke, et besøg med relevante tilvalg og et forløb, hvor valget ændres. Undersøg både, hvilke oplysninger der når serveren, og hvad der forlader den. En e-mailadresse bliver ikke automatisk anonym, fordi den hashes. Fjern derfor overflødige felter, og fastlæg, hvor længe fejllogge og hændelsesdata skal gemmes. Få løsningen vurderet juridisk, hvis der er tvivl om behandlingsgrundlag, leverandørroller eller overførsler. En teknisk gennemgang kan ikke alene afklare de spørgsmål.
Håndter annulleringer og returneringer særskilt
Et registreret køb fortæller ikke hele historien om en ordres værdi. Kunden kan annullere inden afsendelse, returnere én vare eller få refunderet fragten. Hvis du bruger købstal til at vurdere indtjening, skal disse ændringer indgå i dit rapporteringsgrundlag. Det betyder ikke nødvendigvis, at alle modtagere skal have alle ændringer. Nogle værktøjer understøtter refunderinger eller justeringer, mens andre kræver en anden håndtering. Undersøg mulighederne, før du tilrettelægger en fælles arbejdsgang.
Tag eksempelvis en ordre på 1.200 kr., hvor kunden senere får 300 kr. tilbage. Den oprindelige købshændelse bør ikke uden videre sendes igen med værdien 900 kr. Det kan blive opfattet som endnu et køb. Brug i stedet modtagerens metode til rettelser, hvis der findes en. Bevar forbindelsen til den oprindelige ordre, og skeln mellem hel og delvis refundering. Hvis rettelser kun håndteres i dit interne rapporteringssystem, skal det fremgå tydeligt for den, der sammenligner tallene.
Aftal, hvem der reagerer, når data mangler
En serverløsning kan stoppe med at sende data, selv om webshoppen fortsætter med at modtage ordrer. Adgangsoplysninger kan udløbe, et felt kan skifte navn, eller en ændring i betalingsforløbet kan betyde, at en hændelse ikke længere udløses. Placér derfor ansvaret for fejlmeldinger hos en bestemt person eller funktion, og aftal en stedfortræder. En besked i en indbakke, ingen læser, hjælper ikke den medarbejder, der næste morgen skal bruge rapporten.
Overvåg både tekniske fejl og usædvanlige ændringer i datamængden. En server kan godt svare uden fejl, selv om købsværdien mangler. Sammenlign derfor med et relevant grundlag, eksempelvis antallet af betalte ordrer, men tag højde for samtykke og andre kendte forskelle. Ved en fejl bør du kunne se, hvornår den begyndte, hvilke modtagere der er berørt, og om hændelser kan gensendes forsvarligt. Aftal også, hvem der godkender en gensendelse, så et forsøg på at udfylde et hul ikke ender med at skabe dubletter.