Er server-side tracking bedre end en browserpixel?

Det er mere komplet for køb, men virker bedst sammen med pixelen. Pixelen tilføjer browsercookies og sidekontekst, serveren tilføjer de ordrer, browseren missede, og et fælles event-id sørger for, at der kun er én kopi af hvert køb.

Virker server-side tracking med adblockere?

Køb, der sendes fra ordredata, bliver ikke påvirket, fordi shopperens browser ikke sender dem. Klik-id'et skal stadig gemmes i browseren ved landing, og first-party-indsamling gør det mere pålideligt.

Overholder server-side tracking GDPR?

Server-side tracking er en leveringsmetode, ikke et retsgrundlag. Samtykkereglerne gælder for dataene, uanset hvilken vej de tager, så følg den besøgendes valg, og spørg din juridiske rådgiver, hvilke data du må sende.

Hvad er forskellen på server-side tracking og server-side tagging?

Server-side tagging videresender browser-events gennem din egen server, for eksempel en Google Tag Manager-servercontainer. Server-side tracking fra ordredata starter købet fra ordren i din shop, så købet ikke afhænger af browseren.

Har jeg brug for en udvikler for at sætte server-side tracking op?

Ikke hvis du bruger en tjeneste, der forbinder til din shop og dine annonceplatforme via apps og logins. En selvhostet tag-server kræver, at nogen sætter den op, hoster den og holder den opdateret.

Hvad er server-side tracking? En guide til webshops

Vigtigste pointer

Server-side tracking sender konverteringsevents, som køb, fra en server til annonceplatformens API i stedet for kun fra en pixel i browseren.
Når købet sendes fra din shops ordredata, giver adblockere og en takkeside, der aldrig indlæses, ikke længere tabte salg.
Browseren er stadig nødvendig for at gemme klik-id'et ved landing, og pixelen kan køre ved siden af serveren med samme event_id, så hvert køb kun tæller én gang.
Server-side tagging, som en Google Tag Manager-servercontainer, starter stadig ud fra browser-events, så det kan ikke redde køb, som browseren aldrig sendte.
Server-side tracking er ikke en måde at omgå samtykke på: Privatlivsreglerne gælder for dataene, uanset hvilken vej de tager.

Server-side tracking betyder, at konverteringsevents, som et køb, sendes til annonceplatforme fra en server i stedet for kun fra et script i shopperens browser. For en webshop sender serveren hver ordre til Meta, TikTok eller Google via deres API'er, så salget bliver rapporteret, selv når browserpixelen er blokeret eller aldrig indlæses.

Denne guide forklarer forskellen på en browserpixel og server-side tracking, følger dataene fra annonceklikket til annonceplatformen og viser, hvad et server-event indeholder. Den dækker også deduplikering, server-side tagging, samtykke og hvordan du kan se, om din shop har brug for det. Til selve Shopify-opsætningen kan du læse server-side tracking på Shopify.

Browserpixel vs. server-side tracking

En browserpixel er et stykke JavaScript fra annonceplatformen. Det kører på dine sider og sender events fra shopperens enhed direkte til platformen: en sidevisning, en tilføjelse til kurven, et køb på takkesiden. Det virker kun, når scriptet indlæses, kører og når frem til platformen, før shopperen forlader siden.

Server-side tracking flytter afsendelsen til en server. Eventet kan starte ud fra data, din shop allerede har, som en betalt ordre, og serveren sender det videre til platformens API. Meta kalder dette API for Conversions API, og TikTok kalder det Events API. Google Ads bruger enhanced conversions, som føjer hashede kundedata til en konvertering.

Browserpixel

Kører i shopperens browser
Sender events direkte til annonceplatformen
Sætter og læser first-party-cookies, som _fbp for Meta
Sender intet, når scriptet er blokeret, eller siden ikke indlæses

Server-side tracking

Kører på en server, som du eller en tjenesteudbyder kontrollerer
Sender events til platformens API
Kan starte fra ordreposten i din shop
Afhænger ikke af, at takkesiden indlæses

De to metoder virker sammen. De fleste shops kører begge og lader platformen fjerne dubletterne.

Når begge kører, får platformen de mest komplette data. Browser-eventet tilføjer cookies og sidekontekst. Server-eventet når frem, selv når browseren svigter. Et fælles event-id sørger for, at platformen tæller hvert køb én gang.

Hvordan fungerer server-side tracking?

Server-side tracking til en webshop har to halvdele. Den første halvdel sker i browseren: Når en shopper lander fra en annonce, gemmer et script klik-id'et fra URL'en. Den anden halvdel sker på serveren: Når ordren er betalt, knytter serveren det klik-id til ordren og sender købet.

AnnonceklikPlatformen føjer et klik-id til URL'en, som fbclid, ttclid eller gclid.

LandingssideEt first-party-script gemmer klik-id'et og UTM'erne sammen med et besøgs-id.

Ordre betaltShoppen registrerer ordren og giver serveren besked, for eksempel med en webhook.

ServerMatcher ordren med den besøgende, hasher kundedata og bygger eventet.

Annonceplatformens APIModtager købet og matcher det med annonceklikket.

Købet starter fra ordreposten, ikke fra takkesiden. Kun klik-id'et skal gemmes i browseren.

Registrering af klikket

Annonceplatforme føjer et klik-id til landings-URL'en: fbclid for Meta, ttclid for TikTok, gclid for Google Ads og msclkid for Microsoft Ads. Klik-id'et er den stærkeste forbindelse mellem et salg og den annonce, der udløste det, så det skal gemmes ved den første sidevisning. UTM-parametre tilføjer kampagne-, annoncesæt- og annoncenavne i et format, du selv styrer.

Matching af ordren

Serveren skal derefter vide, hvilken besøgende der afgav ordren. Den mest pålidelige kobling er en værdi, der følger med kurven ind i ordren, som et besøgs-id, der er gemt på kurven. Andre metoder er svagere: en e-mailadresse, som den besøgende har indtastet tidligere på websitet, eller den samme IP-adresse og browser, set kort før ordren. Hver webshopplatform tilbyder forskellige muligheder. Vores guide til andre webshops viser de metoder, ROASaurus bruger pr. platform.

Afsendelse af eventet

Til sidst sender serveren købet til hver platforms API. Eventet indeholder ordreværdien, klik-id'et og kundedata, der hjælper platformen med at finde den person, der klikkede. Hvis en platform er nede eller returnerer en fejl, forsøger en god opsætning igen senere, så købet ikke går tabt.

Hvad indeholder et server-event?

Hver platform har sine egne feltnavne, men et købsevent bærer de samme slags data overalt. Her er et forkortet eksempel til Meta Conversions API:

Eksempel: et Purchase-event til Meta Conversions API

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793009700,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkout/thank-you",
    "user_data": {
      "em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
      "ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
      "fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
      "fbp": "fb.1.1792832529000.1234567890"
    },
    "custom_data": { "currency": "USD", "value": 84.00 }
  }]
}

Felt	Hvad det er	Hashet?
Eventnavn og tidspunkt	Purchase og tidspunktet, hvor ordren blev afgivet	Nej
Værdi og valuta	Ordreværdien, som platformen bruger til ROAS og værdibaseret budgivning	Nej
`event_id`	Et unikt id pr. event, det samme i browseren og på serveren, til deduplikering	Nej
E-mail, telefon, navn, adresse	Kundedata fra ordren, normaliseret og hashet med SHA-256	Ja
Klik-id (fbc, ttclid, gclid)	Id'et fra annonceklikket, gemt da shopperen landede	Nej
IP-adresse og user agent	Hjælper platformen med at matche eventet med en enhed	Nej

Kundedata hashes, før de forlader din server. Meta kræver, at IP-adressen, user agent og klik-id'er sendes uden hashing.

Hashing omdanner en e-mailadresse til en fast tekststreng. Den samme adresse giver altid den samme streng, men strengen afslører ikke adressen. Platformen bruger kun de hashede værdier til at søge efter et match blandt sine egne brugere. Sådan kan et køb matches med den person, der så eller klikkede på annoncen, selv når personens browser blokerede pixelen.

Hvordan fungerer deduplikering?

Når pixelen og serveren begge sender det samme køb, skal platformen tælle det én gang. Begge kopier har samme eventnavn og samme event-id, for eksempel order-1042. Meta sammenligner parret og beholder én kopi, så længe den anden kopi ankommer inden for 48 timer efter den første.

Purchase event_id=order-1042 browserModtaget fra pixelen

Purchase event_id=order-1042 serverSamme navn og id: tælles én gang

Purchase event_id=order-1043 serverPixelen blev blokeret: Serverkopien er den eneste

Purchase event_id=1044 serverBrowseren sendte order-1044: Id'erne er forskellige, så den tælles to gange

Deduplikering virker kun, når begge kopier bruger præcis det samme event-id.

Det meste dobbelttælling kommer fra to afsendere, der ikke deler id'er. Et typisk tilfælde er en platforms egen shop-app og et separat trackingværktøj, der begge sender køb med hver deres id. Vores hjælpeartikel om at undgå dobbelttælling viser de almindelige årsager og løsninger.

Server-side tagging vs. at sende fra ordredata

Begrebet server-side tracking bruges om to forskellige opsætninger. Begge sender events fra en server, men de starter forskellige steder.

Server-side tagging, som Google Tag Manager-servercontainere

Med server-side tagging sender browseren sine events til din egen server i stedet for til hver enkelt leverandør. Google Tag Manager-servercontaineren er et velkendt eksempel. Den kører i dit eget Google Cloud-projekt eller i et andet miljø, du selv vælger. Den modtager forespørgsler fra browseren, og dens tags videresender dataene til Google Analytics, Meta og andre leverandører. Du bestemmer, hvilke data der går hvorhen, og serveren kan køre på et subdomæne af dit website.

Events starter stadig i browseren. Hvis tagget i browseren er blokeret, eller takkesiden aldrig indlæses, har servercontaineren intet at videresende. Du skal også selv drive, betale for og opdatere serveren.

Afsendelse fra ordredata

Den anden tilgang starter købet fra ordreposten i din shop. Shoppen melder den betalte ordre til serveren via en webhook eller et API, og serveren sender den til alle forbundne platforme. Browseren er kun nødvendig tidligere, til at gemme klik-id'et, når shopperen lander.

	Server-side tagging	Afsendelse fra ordredata
Hvor købet starter	Et tag i browseren	Den betalte ordre i din shop
Takkesiden lukket for tidligt	Købet er tabt	Købet er sendt
Tag blokeret i browseren	Købet er tabt, medmindre first-party-endpointet kommer igennem	Købet er sendt
Efterkrav og eksterne betalingssider	Afhænger af takkesiden	Sendes, når ordren oprettes eller betales
Browsing-events (sidevisninger, tilføjelser til kurven)	Ja	Kræver en separat browser-collector
Hvem driver serveren	Dig: hosting og opdateringer	Dig eller en tjenesteudbyder

Server-side tagging forbedrer, hvordan browser-events leveres. Afsendelse fra ordredata gør købet uafhængigt af browseren.

De to tilgange kan kombineres. Mange shops indsamler sidevisninger og tilføjelser til kurven i browseren og sender købet fra ordredata. Købet er det event, som annonceplatformene bruger til at rapportere ROAS og optimere budgivning, så det er det event, der mest har brug for at være komplet.

Hvad løser server-side tracking, og hvad løser det ikke?

Det løser

Køb, der gik tabt, fordi en adblocker stoppede pixelen
Køb, der gik tabt, fordi takkesiden ikke blev indlæst
Køb fra betalingsmetoder, der afsluttes uden for dit website
Svag matching, ved at tilføje hashede kundedata til hvert event

Det løser ikke

Samtykke: En besøgende, der har afvist, er stadig en besøgende, der har afvist
Forskellige attributionsvinduer og attributionsmodeller pr. platform
Dobbelte afsendere, der bruger forskellige event-id'er
Klik-id'er, der aldrig blev gemt ved landing

Server-side tracking gør dataene mere komplette. Det ændrer ikke de regler, der gælder for dataene.

Samtykke gælder stadig

Server-side tracking er en måde at levere data på, ikke en måde at omgå privatlivsreglerne på. Hvor loven kræver samtykke til marketingcookies eller tracking, dækker kravet de data, du indsamler, uanset hvilken vej de tager til platformen. Hvis du flytter en tracker til din server, ændrer det ikke på, hvad en besøgende har sagt ja til.

Attribution forbliver platformspecifik

Hver platform tilskriver stadig køb med sine egne vinduer og regler. Server-events giver hver platform bedre data, men totalerne på tværs af Meta, TikTok og Google kan stadig give mere end din shops omsætning. For at sammenligne kanaler med ét regelsæt skal du bruge én attributionsmodel på tværs af dem alle, for eksempel modellerne i ROASaurus-attribution.

Har din shop brug for server-side tracking?

En shop, der bruger et betydeligt budget på betalte sociale annoncer eller søgeannoncer, har som regel gavn af det. Argumentet er stærkest, når flere af disse punkter passer:

Annonceplatformen modtager tydeligt færre købsevents, end din shop har webordrer. Vores guide til adblockere og tracking viser, hvordan du måler dette hul.
Mange af dine besøgende bruger Safari på iPhone eller Mac, hvor cookies sat af scripts højst holder i 7 dage. Se Safari ITP og annoncetracking.
Shoppere køber ofte dage efter det første annonceklik.
Betalingen afsluttes uden for dit website, eller ordrer betales senere, som ved efterkrav eller bankoverførsel.
Du optimerer kampagner efter køb eller købsværdi, så platformen har brug for hvert salg at lære af.

Sådan ændrer et hul beslutninger i praksis. En eksempelshop har 1,000 webordrer på en måned. Dens Meta-pixel rapporterede 820 Purchase-events, så 18% af ordrerne aldrig nåede Meta fra browseren.

Eksempelshop: køb, der nåede Meta på én måned

Webordrer i shoppen

1,000

Kun pixel

820

Pixel + server, deduplikeret

1,000

I dette eksempel misser pixelen alene 180 af 1,000 ordrer. Når køb sendes fra ordredata, lukkes hullet.

Shoppens break-even-ROAS er 2.5, og Ads Manager viser en ROAS på 2.3 ud fra pixeldata. Ud fra de tal taber kampagnerne penge. Hvis annoncedrevne ordrer blev misset med den samme rate på 18%, er den reelle ROAS omkring 2.3 ÷ 0.82 = 2.8, hvilket er over break-even. Det er et øvre skøn, fordi ikke hver manglende ordre kom fra en annonce. Det viser stadig, hvordan et trackinghul kan få en rentabel kampagne til at ligne et tab.

Server-side tracking betyder mindre for en shop, der ikke annoncerer, eller som bruger meget lidt på annoncer.

Sådan sender ROASaurus server-side events

ROASaurus registrerer 19 klik-id'er og seks UTM-felter ved landing og gemmer dem med et first-party-besøgs-id. Den sender hvert køb fra din shops betalte ordrer til Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll og Outbrain. På Shopify sendes Google Ads-konverteringer fra Shopify-checkout. Browserpixels kan køre ved siden af server-eventsene med samme event-id, og Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin og Spotify deduplikerer dem. Hver afsendelse og platformens svar vises i Event log.

Læs mere på siden om server-side tracking, eller find din webshop på siden integrationer.

Kilder

I ROASaurus

Læs videre

TrackingAdblockere og tracking: hvad din shop misterAdblockere stopper trackingpixels, så annonceplatforme går glip af køb. Se, hvilke events der går tabt, hvorfor server-side events ikke gør, og hvordan du måler dit tab.TrackingConsent Mode v2 og GDPR: hvad en webshop må sendeConsent Mode v2 for webshops: de fire samtykkesignaler fra Google, hvad EU-retten kræver, og hvad server-side tracking stadig må sende. Kun generel information.TrackingDobbelte købsevents: hvorfor salg tælles to gangeDobbelte købsevents puster konverteringer og ROAS op. Se årsagerne, hvordan Meta, TikTok, Snapchat, Pinterest og Reddit deduplikerer, og hvordan du løser det.