Indhold
Serverside tracking betyder, at tracking-data går gennem jeres egen server, før det sendes videre til Google, Meta og de andre værktøjer. I stedet for at hver eneste tag kører i den besøgendes browser, sender browseren én strøm af data til jeres server, og serveren bestemmer, hvad der sendes hvorhen. Det giver mere stabile data, mere kontrol og ofte en hurtigere side.
Her er, hvad serverside tracking er, hvordan det virker, hvad det kan og ikke kan, hvad det kræver og koster, og hvornår det er besværet værd. Det er ikke en måde at komme uden om samtykke, og det skriver vi tydeligt nedenfor. Hvordan samtykke og cookies hænger sammen, står i GDPR og cookies.
Klientside og serverside
| Klientside (almindelig) | Serverside | |
|---|---|---|
| Hvor kører tags | I den besøgendes browser | På jeres egen server |
| Hvem modtager data | Hvert værktøj direkte fra browseren | Jeres server, som sender videre |
| Kontrol | Hvert tag kan sende det, det vil | I bestemmer, hvad der sendes hvorhen |
| Påvirkes af | Annonceblokkere, browserbegrænsninger og langsomme scripts | Mindre, når serveren ligger på jeres eget domæne |
| Opsætning | Enkel | Kræver en server og mere teknisk arbejde |
Sådan virker det
Den mest udbredte løsning er serverside tagging i Google Tag Manager. Ifølge Googles dokumentation kører en servercontainer på en server, I selv styrer, typisk i Google Cloud eller hos en udbyder, der er specialiseret i det. Browseren sender data til serveren, en såkaldt klient i containeren tager imod og laver det om til hændelser, og tags i containeren sender dem videre til GA4, Google Ads, Meta Conversions API og andre.
Google anbefaler at lægge serveren på jeres eget domæne, for eksempel data.jeresdomæne.dk. Så foregår kommunikationen mellem browseren og jeres eget website, ikke med en række tredjeparter.
Hvad det giver
- Mere stabile data. Færre hændelser går tabt på grund af annonceblokkere og browsere, der begrænser tredjepartsscripts.
- Kontrol over data. Google skriver, at kun I har adgang til data på serveren, til I vælger at sende dem videre. I kan fjerne oplysninger, før de forlader jeres server, for eksempel IP-adresser eller dele af en URL.
- Bedre data til annoncering. Køb og henvendelser kan sendes til Google Ads og Meta Conversions API fra serveren, med de oplysninger, I har lov til at bruge. Se Meta Pixel og Conversions API.
- Længere levetid for cookies. Safari begrænser cookies, der sættes med JavaScript, til syv dage. Cookies sat af jeres egen server kan i mange tilfælde leve længere, så en besøgende, der kommer igen efter to uger, genkendes. Det afhænger dog af opsætningen: Safari begrænser også cookies fra servere, der ser ud til at tilhøre en tredjepart, for eksempel via CNAME-opsætninger.
- Hurtigere side. Færre scripts i browseren betyder mindre arbejde for den besøgendes telefon. Effekten afhænger af, hvor mange tags I havde i forvejen. Se hurtig hjemmeside.
Det kan det ikke
- Det fjerner ikke kravet om samtykke. Data om besøgende, der ikke har sagt ja, må ikke bruges til markedsføring, uanset om de sendes fra browser eller server. Serverside tracking skal styres af det samme samtykke.
- Det retter ikke en dårlig opsætning. Tracker I det forkerte, tracker I det forkerte fra serveren.
- Det giver ikke 100 procent data. Det giver flere og mere stabile data, men aldrig alt.
- Det er ikke gratis eller “sæt og glem”. Serveren koster penge og skal vedligeholdes.
Hvad det kræver og koster
- En servercontainer i Google Tag Manager, ved siden af den almindelige webcontainer.
- Hosting i Google Cloud eller hos en udbyder, der er specialiseret i serverside tagging. Prisen afhænger af trafikken. I vores erfaring koster det for de fleste mindre og mellemstore websites fra et par hundrede til et par tusinde kroner om måneden.
- Et subdomæne på jeres eget domæne, der peger på serveren.
- Opsætning af tags for GA4, Google Ads, Meta og andre, med samtykke.
- Test og løbende tjek, så I opdager, hvis noget holder op med at virke.
Hvornår er det besværet værd?
| Giver mening | Kan vente |
|---|---|
| Webshops og virksomheder, der bruger mange penge på annoncer | Små sites med få besøg og lille annoncebudget |
| Når I kører både Google Ads og Meta og vil sende konverteringer fra serveren | Når den almindelige tracking ikke er på plads endnu |
| Når I vil have kontrol med, hvilke data der forlader jeres website | Når ingen kan vedligeholde opsætningen |
| Når mange tags gør siden langsom | Når der kun er ét eller to tags |
Rækkefølgen er vigtig: Først en klientside-opsætning, der tracker de rigtige ting med samtykke. Så serverside tracking oven på. Hvordan Tag Manager virker, står i Google Tag Manager.
De fejl, vi oftest ser
- Serverside bruges til at omgå samtykke. Ulovligt, og det er ikke det, det er til.
- Serveren ligger på et fremmed domæne. Så mister I en stor del af fordelen.
- Dobbelt tælling. Hændelser sendes både fra browser og server uden deduplikering.
- Ingen overvågning. Serveren går ned eller løber tør for kapacitet, og ingen opdager det.
- Serverside før grundopsætningen. En dyr løsning oven på tracking, der tæller det forkerte.
Tjekliste: serverside tracking
- Er klientside-trackingen på plads og korrekt først?
- Styres serverside tracking af det samme samtykke som resten?
- Ligger serveren på et subdomæne af jeres eget domæne?
- Bliver hændelser, der sendes fra både browser og server, deduplikeret?
- Er det besluttet, hvilke data der fjernes, før de sendes videre?
- Er der overvågning og en ansvarlig for serveren?
Hvordan vi sætter serverside tracking op, står under serverside tracking.
Kilder
- Google for Developers, An introduction to server-side tagging.
- WebKit, Intelligent Tracking Prevention 2.1, 2019.
- WebKit, CNAME Cloaking and Bounce Tracking Defense, 2020.
