Er server-side tracking bedre enn en nettleserpixel?

Den er mer komplett for kjøp, men fungerer best sammen med pixelen. Pixelen tilfører nettleser-cookies og sidekontekst, serveren tilfører bestillingene nettleseren gikk glipp av, og en felles event-ID sørger for at det bare finnes én kopi av hvert kjøp.

Fungerer server-side tracking med annonseblokkerere?

Kjøp som sendes fra bestillingsdata påvirkes ikke, fordi kundens nettleser ikke sender dem. Click id-en må fortsatt lagres i nettleseren ved landing, og førsteparts innsamling gjør det mer pålitelig.

Er server-side tracking GDPR-kompatibelt?

Server-side tracking er en leveringsmetode, ikke et rettslig grunnlag. Samtykkereglene gjelder dataene uansett hvilken vei de tar, så følg den besøkendes valg og spør din juridiske rådgiver hvilke data du kan sende.

Hva er forskjellen mellom server-side tracking og server-side tagging?

Server-side tagging videresender nettleser-events via din egen server, for eksempel en Google Tag Manager-servercontainer. Server-side tracking fra bestillingsdata starter kjøpet fra bestillingen i nettbutikken din, så kjøpet ikke avhenger av nettleseren.

Trenger jeg en utvikler for å sette opp server-side tracking?

Ikke når du bruker en tjeneste som kobler seg til nettbutikken og annonseplattformene dine gjennom apper og innlogginger. En selvdriftet tag-server krever noen som setter den opp, driver den og holder den oppdatert.

Hva er server-side tracking? En guide for nettbutikker

Hovedpunkter

Server-side tracking sender konverteringsevents, for eksempel kjøp, fra en server til API-et til annonseplattformen i stedet for bare fra en pixel i nettleseren.
Når kjøpet sendes fra bestillingsdataene i nettbutikken din, fører ikke annonseblokkerere og en takkeside som aldri lastes lenger til tapte salg.
Nettleseren trengs fortsatt for å lagre click id-en når besøkende lander, og pixelen kan kjøre ved siden av serveren med samme event_id, slik at hvert kjøp telles én gang.
Server-side tagging, for eksempel en Google Tag Manager-servercontainer, starter fortsatt fra nettleser-events, så den kan ikke hente tilbake kjøp som nettleseren aldri sendte.
Server-side tracking er ingen måte å omgå samtykke på: personvernreglene gjelder dataene uansett hvilken vei de tar.

Server-side tracking betyr at konverteringsevents, for eksempel et kjøp, sendes til annonseplattformer fra en server i stedet for bare fra et skript i kundens nettleser. For en nettbutikk sender serveren hver bestilling til Meta, TikTok eller Google gjennom API-ene deres, så salget rapporteres selv når nettleserpixelen er blokkert eller aldri lastes.

Denne guiden forklarer forskjellen mellom en nettleserpixel og server-side tracking, følger dataene fra annonseklikket til annonseplattformen og viser hva en server-event inneholder. Den tar også for seg deduplisering, server-side tagging, samtykke og hvordan du ser om nettbutikken din trenger det. For selve oppsettet på Shopify kan du lese server-side tracking på Shopify.

Nettleserpixel mot server-side tracking

En nettleserpixel er et stykke JavaScript fra annonseplattformen. Den kjører på sidene dine og sender events fra kundens enhet rett til plattformen: en sidevisning, et tillegg i handlekurven, et kjøp på takkesiden. Den fungerer bare når skriptet lastes, kjøres og når plattformen før kunden forlater siden.

Server-side tracking flytter sendingen til en server. Eventen kan starte fra data nettbutikken din allerede har, for eksempel en betalt bestilling, og serveren sender den til API-et til plattformen. Meta kaller dette API-et Conversions API, og TikTok kaller det Events API. Google Ads bruker enhanced conversions, som legger hashede kundedata til en konvertering.

Nettleser-pixel

Kjører i kundens nettleser
Sender events direkte til annonseplattformen
Setter og leser førstepartscookies, for eksempel _fbp for Meta
Sender ingenting når skriptet er blokkert eller siden ikke lastes

Server-side tracking

Kjører på en server som du eller en tjenesteleverandør kontrollerer
Sender events til API-et til plattformen
Kan starte fra bestillingsposten i nettbutikken din
Er ikke avhengig av at takkesiden lastes

De to metodene fungerer sammen. De fleste butikker kjører begge og lar plattformen fjerne duplikatene.

Å kjøre begge gir plattformen de mest komplette dataene. Nettleser-eventen tilfører cookies og sidekontekst. Server-eventen kommer fram selv når nettleseren svikter. En felles event-ID sørger for at plattformen teller hvert kjøp én gang.

Hvordan fungerer server-side tracking?

Server-side tracking for en nettbutikk har to halvdeler. Den første halvdelen skjer i nettleseren: når en kunde lander fra en annonse, lagrer et skript click id-en fra URL-en. Den andre halvdelen skjer på serveren: når bestillingen er betalt, kobler serveren click id-en til bestillingen og sender kjøpet.

AnnonseklikkPlattformen legger en click id til i URL-en, for eksempel fbclid, ttclid eller gclid.

LandingssideEt førstepartsskript lagrer click id-en og UTM-ene sammen med en besøks-ID.

Bestilling betaltNettbutikken registrerer bestillingen og gir serveren beskjed, for eksempel med en webhook.

ServerKobler bestillingen til den besøkende, hasher kundedata og bygger eventen.

Annonseplattformens APIMottar kjøpet og kobler det til annonseklikket.

Kjøpet starter fra bestillingsposten, ikke fra takkesiden. Bare click id-en må lagres i nettleseren.

Fange opp klikket

Annonseplattformer legger en click id til i URL-en til landingssiden: fbclid for Meta, ttclid for TikTok, gclid for Google Ads og msclkid for Microsoft Ads. Click id-en er den sterkeste koblingen mellom et salg og annonsen som utløste det, så den må lagres ved første sidevisning. UTM-parametere legger til navnene på kampanje, annonsesett og annonse i et format du selv styrer.

Matche bestillingen

Serveren må deretter vite hvilken besøkende som la inn bestillingen. Den mest pålitelige koblingen er en verdi som følger med handlekurven inn i bestillingen, for eksempel en besøks-ID som er lagret på handlekurven. Andre metoder er svakere: en e-postadresse den besøkende har skrevet inn tidligere på nettstedet, eller den samme IP-adressen og nettleseren sett kort før bestillingen. Hver nettbutikkplattform har ulike muligheter. Guiden vår for andre nettbutikker lister opp metodene ROASaurus bruker per plattform.

Sende eventen

Til slutt sender serveren kjøpet til API-et til hver plattform. Eventen inneholder bestillingsverdien, click id-en og kundedata som hjelper plattformen med å finne personen som klikket. Hvis en plattform er nede eller returnerer en feil, prøver et godt oppsett på nytt senere, så kjøpet ikke går tapt.

Hva inneholder en server-event?

Hver plattform har sine egne feltnavn, men en kjøpsevent har de samme typene data overalt. Her er et forkortet eksempel for Meta Conversions API:

Eksempel: en Purchase-event for 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	Hva det er	Hashet?
Eventnavn og tidspunkt	Purchase, og når bestillingen ble lagt inn	Nei
Verdi og valuta	Bestillingsverdien som plattformen bruker til ROAS og verdibasert budgivning	Nei
`event_id`	En unik ID per event, den samme i nettleseren og på serveren, for deduplisering	Nei
E-post, telefon, navn, adresse	Kundedata fra bestillingen, normalisert og hashet med SHA-256	Ja
Click id (fbc, ttclid, gclid)	ID-en fra annonseklikket, lagret da kunden landet	Nei
IP-adresse og user agent	Hjelper plattformen med å koble eventen til en enhet	Nei

Kundedata hashes før de forlater serveren din. Meta krever at IP-adressen, user agent og click id-er sendes uten hashing.

Hashing gjør en e-postadresse om til en fast tegnstreng. Den samme adressen gir alltid den samme strengen, men strengen avslører ikke adressen. Plattformen bruker de hashede verdiene bare til å lete etter en match blant sine egne brukere. Slik kan et kjøp kobles til personen som så eller klikket på annonsen, selv når nettleseren til vedkommende blokkerte pixelen.

Hvordan fungerer deduplisering?

Når pixelen og serveren begge sender det samme kjøpet, må plattformen telle det én gang. Begge kopiene har det samme eventnavnet og den samme event-ID-en, for eksempel order-1042. Meta sammenligner paret og beholder én kopi, så lenge den andre kopien kommer fram innen 48 timer etter den første.

Purchase event_id=order-1042 browserMottatt fra pixelen

Purchase event_id=order-1042 serverSamme navn og ID: telles én gang

Purchase event_id=order-1043 serverPixelen ble blokkert: serverkopien er den eneste

Purchase event_id=1044 serverNettleseren sendte order-1044: ID-ene er ulike, så den telles to ganger

Deduplisering fungerer bare når begge kopiene bruker nøyaktig den samme event-ID-en.

Det meste av dobbelttelling kommer fra to avsendere som ikke deler ID-er. Et typisk tilfelle er plattformens egen butikkapp og et separat trackingverktøy som begge sender kjøp med sine egne ID-er. Hjelpeartikkelen vår om å unngå dobbelttelling lister opp de vanligste årsakene og løsningene.

Server-side tagging mot å sende fra bestillingsdata

Begrepet server-side tracking brukes om to ulike oppsett. Begge sender events fra en server, men de starter på forskjellige steder.

Server-side tagging, for eksempel Google Tag Manager-servercontainere

Med server-side tagging sender nettleseren eventene sine til din egen server i stedet for til hver enkelt leverandør. Google Tag Manager-servercontaineren er et velkjent eksempel. Den kjører i ditt eget Google Cloud-prosjekt eller i et annet miljø du velger. Den mottar forespørsler fra nettleseren, og taggene i den videresender dataene til Google Analytics, Meta og andre leverandører. Du bestemmer hvilke data som går hvor, og serveren kan kjøre på et underdomene av nettstedet ditt.

Eventene starter fortsatt i nettleseren. Hvis taggen i nettleseren blir blokkert, eller takkesiden aldri lastes, har servercontaineren ingenting å videresende. Du drifter, betaler for og oppdaterer også serveren selv.

Å sende fra bestillingsdata

Den andre tilnærmingen starter kjøpet fra bestillingsposten i nettbutikken din. Nettbutikken melder den betalte bestillingen til serveren gjennom en webhook eller et API, og serveren sender den til hver tilkoblede plattform. Nettleseren trengs bare tidligere, for å lagre click id-en når kunden lander.

	Server-side tagging	Å sende fra bestillingsdata
Der kjøpet starter	En tagg i nettleseren	Den betalte bestillingen i nettbutikken din
Takkesiden lukket for tidlig	Kjøpet går tapt	Kjøpet sendes
Taggen blokkert i nettleseren	Kjøpet går tapt, med mindre førsteparts-endepunktet kommer gjennom	Kjøpet sendes
Betaling ved levering og eksterne betalingssider	Avhenger av takkesiden	Sendes når bestillingen opprettes eller betales
Nettlesingsevents (sidevisninger, tillegg i handlekurven)	Ja	Trenger en separat innsamler i nettleseren
Hvem som driver serveren	Du: hosting og oppdateringer	Du eller en tjenesteleverandør

Server-side tagging forbedrer hvordan nettleser-events leveres. Å sende fra bestillingsdata gjør kjøpet uavhengig av nettleseren.

De to tilnærmingene kan kombineres. Mange butikker samler inn sidevisninger og handlekurv-events i nettleseren, og sender kjøpet fra bestillingsdata. Kjøpet er eventen annonseplattformene bruker til å rapportere ROAS og optimalisere budgivningen, så det er den som mest trenger å være komplett.

Hva løser server-side tracking, og hva løser den ikke?

Det løser

Kjøp som gikk tapt fordi en annonseblokkerer stoppet pixelen
Kjøp som gikk tapt fordi takkesiden ikke ble lastet
Kjøp fra betalingsmetoder som fullføres utenfor nettstedet ditt
Svak matching, ved å legge hashede kundedata til hver event

Det løser ikke

Samtykke: en besøkende som har avslått, er fortsatt en besøkende som har avslått
Ulike attribusjonsvinduer og modeller per plattform
Doble avsendere som bruker ulike event-ID-er
Click id-er som aldri ble lagret ved landing

Server-side tracking gjør dataene mer komplette. Den endrer ikke reglene som gjelder for dataene.

Samtykke gjelder fortsatt

Server-side tracking er en måte å levere data på, ikke en måte å omgå personvernreglene på. Der loven krever samtykke for markedsføringscookies eller sporing, dekker kravet dataene du samler inn, uansett hvilken vei de tar til plattformen. Å flytte en tracker til serveren din endrer ikke hva en besøkende har sagt ja til.

Attribusjon forblir plattformspesifikk

Hver plattform krediterer fortsatt kjøp med sine egne vinduer og regler. Server-events gir hver plattform bedre data, men totalene på tvers av Meta, TikTok og Google kan likevel summere seg til mer enn omsetningen i nettbutikken din. For å sammenligne kanaler med ett sett regler bruker du én attribusjonsmodell på tvers av dem alle, for eksempel modellene i ROASaurus-attribusjon.

Trenger nettbutikken din server-side tracking?

En butikk som bruker et betydelig budsjett på betalte annonser i sosiale medier eller søk, har vanligvis nytte av det. Argumentet er sterkest når flere av disse punktene stemmer:

Annonseplattformen mottar tydelig færre kjøpsevents enn nettbutikken har nettbestillinger. Guiden vår om annonseblokkerere og tracking viser hvordan du måler dette gapet.
Mange av de besøkende dine bruker Safari på iPhone eller Mac, der cookies som settes av skript, varer i høyst 7 dager. Se Safari ITP og annonsetracking.
Kunder kjøper ofte dager etter det første annonseklikket.
Betalingen fullføres utenfor nettstedet ditt, eller bestillinger betales senere, som ved betaling ved levering eller bankoverføring.
Du optimaliserer kampanjer for kjøp eller kjøpsverdi, så plattformen trenger hvert salg å lære av.

Her er hvordan et gap endrer beslutninger i praksis. En eksempelbutikk har 1,000 nettbestillinger i en måned. Meta-pixelen rapporterte 820 Purchase-events, så 18% av bestillingene nådde aldri Meta fra nettleseren.

Eksempelbutikk: kjøp som nådde Meta i løpet av én måned

Nettbestillinger i butikken

1,000

Bare pixel

820

Pixel + server, deduplisert

1,000

I dette eksempelet går 180 av 1,000 bestillinger glipp hvis du bare bruker pixelen. Å sende kjøp fra bestillingsdata tetter gapet.

Break-even-ROAS for butikken er 2.5, og Ads Manager viser en ROAS på 2.3 ut fra pixeldata. Med disse tallene taper kampanjene penger. Hvis annonsedrevne bestillinger gikk glipp i samme takt på 18%, er den reelle ROAS-en omtrent 2.3 ÷ 0.82 = 2.8, som er over break-even. Det er et øvre anslag, fordi ikke alle manglende bestillinger kom fra en annonse. Det viser likevel hvordan et trackinggap kan få en lønnsom kampanje til å se ut som et tap.

Server-side tracking betyr mindre for en butikk som ikke annonserer, eller som bruker svært lite på annonser.

Slik sender ROASaurus server-events

ROASaurus fanger opp 19 click id-er og seks UTM-felt ved landing og lagrer dem sammen med en førsteparts besøks-ID. Den sender hvert kjøp fra butikkens betalte bestillinger 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-checkouten. Nettleserpixler kan kjøre ved siden av server-eventene med samme event-ID, og Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin og Spotify dedupliserer dem. Hver levering og plattformens svar er oppført i Event log.

Les mer på siden om server-side tracking, eller finn nettbutikken din på siden om integrasjoner.

Kilder

I ROASaurus

Les videre

TrackingAnnonseblokkere og tracking: hva butikken din taperAnnonseblokkere stopper tracking-pixler, så annonseplattformene går glipp av kjøp. Se hvilke events som går tapt, hvorfor server-side-events ikke gjør det, og hvordan du måler gapet ditt.TrackingConsent Mode v2 og GDPR: hva en nettbutikk kan sendeConsent Mode v2 for nettbutikker: de fire samtykkesignalene fra Google, hva EU-retten krever, og hva server-side tracking fortsatt kan sende. Kun generell informasjon.TrackingDupliserte kjøpsevents: hvorfor salg telles to gangerDupliserte kjøpsevents blåser opp konverteringer og ROAS. Se årsakene, hvordan Meta, TikTok, Snapchat, Pinterest og Reddit deduplikerer, og hvordan du løser det.