Är server-side tracking bättre än en webbläsarpixel?

Det är mer komplett för köp, men fungerar bäst tillsammans med pixeln. Pixeln tillför webbläsarcookies och sidkontext, servern tillför de ordrar som webbläsaren missade, och ett gemensamt händelse-id gör att en kopia av varje köp behålls.

Fungerar server-side tracking med annonsblockerare?

Köp som skickas från orderdata påverkas inte, eftersom köparens webbläsare inte skickar dem. Klick-id:t måste ändå sparas i webbläsaren vid landningen, och förstapartsinsamling gör det mer tillförlitligt.

Är server-side tracking förenligt med GDPR?

Server-side tracking är en leveransmetod, inte en rättslig grund. Samtyckesreglerna gäller datan oavsett vilken väg den tar, så följ besökarens val och fråga din juridiska rådgivare vilken data du får skicka.

Vad är skillnaden mellan server-side tracking och server-side tagging?

Server-side tagging vidarebefordrar webbläsarhändelser via din egen server, till exempel en server container i Google Tag Manager. Server-side tracking från orderdata låter köpet utgå från ordern i din butik, så köpet beror inte på webbläsaren.

Behöver jag en utvecklare för att sätta upp server-side tracking?

Inte när du använder en tjänst som ansluter till din butik och dina annonsplattformar via appar och inloggningar. En egenhostad tag-server kräver att någon sätter upp den, hostar den och håller den uppdaterad.

Vad är server-side tracking? En guide för webbshoppar

Det viktigaste

Server-side tracking skickar konverteringshändelser, till exempel köp, från en server till annonsplattformens API i stället för bara från en pixel i webbläsaren.
När köpet skickas från din butiks orderdata leder annonsblockerare och en tacksida som aldrig laddas inte längre till förlorade försäljningar.
Webbläsaren behövs fortfarande för att spara klick-id:t vid landningen, och pixeln kan köra vid sidan av servern med samma event_id så att varje köp räknas en gång.
Server-side tagging, till exempel en server container i Google Tag Manager, utgår fortfarande från webbläsarhändelser och kan därför inte återskapa köp som webbläsaren aldrig skickade.
Server-side tracking är inget sätt att kringgå samtycke: sekretessreglerna gäller datan oavsett vilken väg den tar.

Server-side tracking innebär att konverteringshändelser, till exempel ett köp, skickas till annonsplattformar från en server i stället för bara från ett skript i köparens webbläsare. För en webbshop skickar servern varje order till Meta, TikTok eller Google via deras API:er, så försäljningen rapporteras även när webbläsarpixeln är blockerad eller aldrig laddas.

Den här guiden förklarar skillnaden mellan en webbläsarpixel och server-side tracking, följer datan från annonsklicket till annonsplattformen och visar vad en serverhändelse innehåller. Den tar också upp deduplicering, server-side tagging, samtycke och hur du avgör om din butik behöver det. För själva uppsättningen i Shopify, läs server-side tracking i Shopify.

Webbläsarpixel kontra server-side tracking

En webbläsarpixel är en bit JavaScript från annonsplattformen. Den körs på dina sidor och skickar händelser från köparens enhet direkt till plattformen: en sidvisning, en vara som läggs i varukorgen, ett köp på tacksidan. Den fungerar bara när skriptet laddas, körs och når plattformen innan köparen lämnar sidan.

Server-side tracking flyttar sändningen till en server. Händelsen kan utgå från data som din butik redan har, till exempel en betald order, och servern skickar den till plattformens API. Meta kallar det API:et Conversions API och TikTok kallar det Events API. Google Ads använder enhanced conversions, som lägger till hashad kunddata till en konvertering.

Webbläsarpixel

Körs i köparens webbläsare
Skickar händelser direkt till annonsplattformen
Sätter och läser förstapartscookies, till exempel _fbp för Meta
Skickar ingenting när skriptet är blockerat eller sidan inte laddas

Server-side tracking

Körs på en server som du eller en tjänsteleverantör kontrollerar
Skickar händelser till plattformens API
Kan utgå från orderposten i din butik
Beror inte på att tacksidan laddas

De två metoderna fungerar tillsammans. De flesta butiker kör båda och låter plattformen ta bort dubbletterna.

Om du kör båda får plattformen den mest kompletta datan. Webbläsarhändelsen tillför cookies och sidkontext. Serverhändelsen kommer fram även när webbläsaren misslyckas. Ett gemensamt händelse-id ser till att plattformen räknar varje köp en gång.

Hur fungerar server-side tracking?

Server-side tracking för en webbshop har två halvor. Den första halvan sker i webbläsaren: när en köpare landar från en annons sparar ett skript klick-id:t från URL:en. Den andra halvan sker på servern: när ordern är betald kopplar servern det klick-id:t till ordern och skickar köpet.

AnnonsklickPlattformen lägger till ett klick-id i URL:en, till exempel fbclid, ttclid eller gclid.

LandningssidaEtt förstapartsskript sparar klick-id:t och UTM:erna tillsammans med ett besökar-id.

Order betaldButiken registrerar ordern och meddelar servern, till exempel med en webhook.

ServerMatchar ordern mot besökaren, hashar kunddata och bygger händelsen.

Annonsplattformens APITar emot köpet och matchar det mot annonsklicket.

Köpet utgår från orderposten, inte från tacksidan. Bara klick-id:t behöver sparas i webbläsaren.

Fånga klicket

Annonsplattformar lägger till ett klick-id i landningssidans URL: fbclid för Meta, ttclid för TikTok, gclid för Google Ads och msclkid för Microsoft Ads. Klick-id:t är den starkaste länken mellan en försäljning och annonsen som orsakade den, så det måste sparas vid den första sidvisningen. UTM-parametrar lägger till namnen på kampanj, annonsuppsättning och annons i ett format som du själv bestämmer.

Matcha ordern

Därefter måste servern veta vilken besökare som la ordern. Den mest tillförlitliga länken är ett värde som följer med varukorgen in i ordern, till exempel ett besökar-id som sparats på varukorgen. Andra metoder är svagare: en e-postadress som besökaren har angett tidigare på webbplatsen, eller samma IP-adress och webbläsare som setts strax före ordern. Varje plattform erbjuder olika alternativ. Vår guide för andra webbshoppar listar de metoder som ROASaurus använder per plattform.

Skicka händelsen

Slutligen skickar servern köpet till varje plattforms API. Händelsen innehåller ordervärdet, klick-id:t och kunddata som hjälper plattformen att hitta den person som klickade. Om en plattform ligger nere eller returnerar ett fel försöker en bra uppsättning igen senare, så att köpet inte går förlorat.

Vad innehåller en serverhändelse?

Varje plattform har egna fältnamn, men en köphändelse bär samma typer av data överallt. Här är ett förkortat exempel för Meta Conversions API:

Exempel: en Purchase-händelse för 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 }
  }]
}

Fält	Vad det är	Hashad?
Händelsenamn och tidpunkt	Purchase, och när ordern lades	Nej
Värde och valuta	Ordervärdet som plattformen använder för ROAS och värdebaserad budgivning	Nej
`event_id`	Ett unikt id per händelse, detsamma i webbläsaren och på servern, för deduplicering	Nej
E-post, telefon, namn, adress	Kunddata från ordern, normaliserad och hashad med SHA-256	Ja
Klick-id (fbc, ttclid, gclid)	Id:t från annonsklicket, sparat när köparen landade	Nej
IP-adress och user agent	Hjälper plattformen att matcha händelsen mot en enhet	Nej

Kunddata hashas innan den lämnar din server. Meta kräver att IP-adressen, user agent och klick-id:n skickas utan hashning.

Hashning gör om en e-postadress till en sträng med tecken av fast längd. Samma adress ger alltid samma sträng, men strängen avslöjar inte adressen. Plattformen använder de hashade värdena bara för att leta efter en träff bland sina egna användare. Så kan ett köp matchas mot den person som såg eller klickade på annonsen, även när personens webbläsare blockerade pixeln.

Hur fungerar deduplicering?

När pixeln och servern båda skickar samma köp måste plattformen räkna det en gång. Båda kopiorna har samma händelsenamn och samma händelse-id, till exempel order-1042. Meta jämför paret och behåller en kopia, så länge den andra kopian kommer in inom 48 timmar efter den första.

Purchase event_id=order-1042 browserMottaget från pixeln

Purchase event_id=order-1042 serverSamma namn och id: räknas en gång

Purchase event_id=order-1043 serverPixeln blockerades: serverkopian är den enda

Purchase event_id=1044 serverWebbläsaren skickade order-1044: id:na skiljer sig åt, så det räknas två gånger

Deduplicering fungerar bara när båda kopiorna använder exakt samma händelse-id.

Det mesta av dubbelräkningen kommer från två avsändare som inte delar id:n. Ett typiskt fall är en plattforms egen butiksapp och ett separat trackingverktyg som båda skickar köp med sina egna id:n. Vår hjälpartikel om att förhindra dubbelräkning listar de vanliga orsakerna och lösningarna.

Server-side tagging kontra att skicka från orderdata

Termen server-side tracking används för två olika uppsättningar. Båda skickar händelser från en server, men de utgår från olika ställen.

Server-side tagging, till exempel server containers i Google Tag Manager

Med server-side tagging skickar webbläsaren sina händelser till din egen server i stället för till varje leverantör. Server containern i Google Tag Manager är ett välkänt exempel. Den körs i ditt eget Google Cloud-projekt eller i en annan miljö som du väljer. Den tar emot anrop från webbläsaren, och dess taggar vidarebefordrar datan till Google Analytics, Meta och andra leverantörer. Du bestämmer vilken data som går vart, och servern kan köra på en subdomän till din webbplats.

Händelserna utgår fortfarande från webbläsaren. Om taggen i webbläsaren blockeras, eller tacksidan aldrig laddas, har server containern ingenting att vidarebefordra. Du driver, betalar för och uppdaterar dessutom servern själv.

Att skicka från orderdata

Den andra metoden låter köpet utgå från orderposten i din butik. Butiken rapporterar den betalda ordern till servern via en webhook eller ett API, och servern skickar den till varje ansluten plattform. Webbläsaren behövs bara tidigare, för att spara klick-id:t när köparen landar.

	Server-side tagging	Att skicka från orderdata
Där köpet utgår från	En tagg i webbläsaren	Den betalda ordern i din butik
Tacksidan stängdes i förtid	Köpet går förlorat	Köpet skickas
Taggen blockeras i webbläsaren	Köpet går förlorat, såvida inte förstapartsendpointen tar sig igenom	Köpet skickas
Postförskott och externa betalsidor	Beror på tacksidan	Skickas när ordern skapas eller betalas
Besökshändelser (sidvisningar, tillagda varor i varukorgen)	Ja	Behöver en separat insamlare i webbläsaren
Vem som kör servern	Du: hosting och uppdateringar	Du eller en tjänsteleverantör

Server-side tagging förbättrar hur webbläsarhändelser levereras. Att skicka från orderdata gör köpet oberoende av webbläsaren.

De två metoderna kan kombineras. Många butiker samlar in sidvisningar och händelser för tillagda varor i webbläsaren och skickar köpet från orderdata. Köpet är den händelse som annonsplattformar använder för att rapportera ROAS och optimera budgivningen, så det är den som mest behöver vara komplett.

Vad löser server-side tracking, och vad löser det inte?

Det löser

Köp som gått förlorade för att en annonsblockerare stoppade pixeln
Köp som gått förlorade för att tacksidan inte laddades
Köp från betalsätt som slutförs utanför din webbplats
Svag matchning, genom att lägga till hashad kunddata i varje händelse

Det löser inte

Samtycke: en besökare som har tackat nej är fortfarande en besökare som har tackat nej
Olika attributionsfönster och modeller per plattform
Dubbla avsändare som använder olika händelse-id:n
Klick-id:n som aldrig sparades vid landningen

Server-side tracking gör datan mer komplett. Det ändrar inte de regler som gäller för datan.

Samtycke gäller fortfarande

Server-side tracking är ett sätt att leverera data, inte ett sätt att kringgå sekretessregler. Där lagen kräver samtycke för marknadsföringscookies eller tracking omfattar kravet den data du samlar in, oavsett vilken väg den tar till plattformen. Att flytta en tracker till din server ändrar inte vad en besökare har samtyckt till.

Attributionen förblir plattformsspecifik

Varje plattform krediterar fortfarande köp med sina egna fönster och regler. Serverhändelser ger varje plattform bättre data, men summorna över Meta, TikTok och Google kan ändå bli större än din butiks intäkter. För att jämföra kanaler med en och samma uppsättning regler använder du en attributionsmodell för alla, till exempel modellerna i ROASaurus-attribution.

Behöver din butik server-side tracking?

En butik som lägger en betydande budget på betalda sociala annonser eller sökannonser har oftast nytta av det. Argumenten är starkast när flera av de här punkterna stämmer:

Annonsplattformen får tydligt färre köphändelser än din butik har webbordrar. Vår guide om annonsblockerare och tracking visar hur du mäter det glappet.
Många av dina besökare använder Safari på iPhone eller Mac, där cookies som sätts av skript håller i högst 7 dagar. Se Safari ITP och annonstracking.
Köpare handlar ofta dagar efter det första annonsklicket.
Betalningen slutförs utanför din webbplats, eller ordrar betalas senare, som vid postförskott eller banköverföring.
Du optimerar kampanjer mot köp eller köpvärde, så plattformen behöver varje försäljning att lära sig av.

Så här ändrar ett glapp besluten i praktiken. En exempelbutik har 1,000 webbordrar under en månad. Dess Meta-pixel rapporterade 820 Purchase-händelser, så 18% av ordrarna nådde aldrig Meta från webbläsaren.

Exempelbutik: köp som nådde Meta under en månad

Webbordrar i butiken

1,000

Bara pixel

820

Pixel + server, deduplicerade

1,000

I det här exemplet missar pixeln ensam 180 av 1,000 ordrar. Om du skickar köp från orderdata stängs glappet.

Butikens break-even-ROAS är 2.5, och Ads Manager visar en ROAS på 2.3 utifrån pixeldata. Med de siffrorna går kampanjerna med förlust. Om annonsdrivna ordrar missades i samma takt, 18%, är den verkliga ROAS:en ungefär 2.3 ÷ 0.82 = 2.8, vilket ligger över break-even. Det är en övre uppskattning, eftersom inte varje saknad order kom från en annons. Det visar ändå hur ett trackingglapp kan få en lönsam kampanj att se ut som en förlust.

Server-side tracking betyder mindre för en butik som inte annonserar, eller som lägger mycket lite på annonser.

Så skickar ROASaurus serverhändelser

ROASaurus fångar upp 19 klick-id:n och sex UTM-fält vid landningen och lagrar dem tillsammans med ett förstaparts besökar-id. Det skickar varje köp från din butiks betalda ordrar till Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll och Outbrain. På Shopify skickas Google Ads-konverteringar från Shopify-kassan. Webbläsarpixlar kan köra vid sidan av serverhändelserna med samma händelse-id, och Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI Ads, AppLovin och Spotify deduplicerar dem. Varje leverans och plattformens svar listas i Event log.

Läs mer på sidan om server-side tracking, eller hitta din webbshop på sidan med integrationer.

Källor

I ROASaurus

Läs vidare

TrackingAnnonsblockerare och tracking: vad din butik förlorarAnnonsblockerare stoppar trackingpixlar, så annonsplattformarna missar köp. Se vilka händelser som går förlorade, varför server-side-händelser inte gör det och hur du mäter glappet i din butik.TrackingConsent Mode v2 och GDPR: vad en webbshop får skickaConsent Mode v2 för webbshoppar: Googles fyra samtyckessignaler, vad EU-lagstiftningen kräver och vad server-side tracking fortfarande får skicka. Endast allmän information.TrackingDubbla köphändelser: varför försäljning räknas två gångerDubbla köphändelser blåser upp konverteringar och ROAS. Se orsakerna, hur Meta, TikTok, Snapchat, Pinterest och Reddit deduplicerar och hur du åtgärdar det.