Varför visar Meta fler köp än vad min butik har ordrar?

Oftast för att två verktyg skickar samma pixel med olika händelse-id, eller för att webbläsar- och serverhändelserna inte delar ett id. Meta kan bara slå ihop kopior som har samma händelsenamn och samma händelse-id.

Hur länge väntar Meta med att deduplicera händelser?

Meta deduplicerar en webbläsarhändelse och en serverhändelse med samma händelsenamn och händelse-id när de kommer in inom 48 timmar från den första.

Ska jag stänga av webbläsarpixeln för att stoppa dubbletter?

Nej. Ge i stället webbläsarhändelsen och serverhändelsen samma händelse-id. Webbläsarpixeln tillför signaler som cookies, och serverhändelsen kommer fram när webbläsaren är blockerad.

Kan deduplicering lösa att flera plattformar gör anspråk på samma försäljning?

Nej. Det är överlappande attribution, inte en dubblerad händelse. Jämför plattformarnas anspråk med dina butiksordrar och använd en attributionsmodell för att jämföra kanaler.

Deduplicerar Pinterest taggen och Conversions API?

Ja, när båda händelserna har samma event_id och samma händelsenamn och kommer in inom 48 timmar. Pinterest behåller den första händelsen den tar emot och tar bort de senare kopiorna. I ROASaurus skickar Tag och servern alla fem shoppinghändelserna med matchande id:n och namn.

Dubbla köphändelser: varför försäljning räknas två gånger

Det viktigaste

En dubblerad köphändelse är en order som en annonsplattform räknar som två eller fler köp.
De vanligaste orsakerna är en webbläsarpixel och en serverhändelse utan gemensamt händelse-id, samt två verktyg som skickar samma pixel.
Meta, TikTok, Snapchat, Pinterest och Reddit behåller var och en en kopia när webbläsar- och serverhändelserna har matchande id:n och kommer in inom plattformens tidsfönster.
När Meta, Google och TikTok alla gör anspråk på samma försäljning har ingen händelse skickats två gånger: det är överlappande attribution, och deduplicering kan inte åtgärda det.
Jämför antalet köp från varje källa med dina butiksordrar: en enskild källa med fler köp än ordrar tyder på en andra avsändare.

Dubbla köphändelser uppstår när en annonsplattform räknar en order som två eller fler köp. De vanligaste orsakerna är en webbläsarpixel och en serverhändelse som inte delar ett händelse-id, samt två verktyg som skickar samma pixel. Resultatet är uppblåsta konverteringar, en ROAS som ser bättre ut än den är och budgivning som lär sig av försäljningar som aldrig ägde rum.

Den här guiden förklarar orsakerna, skillnaden mellan dubbletter inom en plattform och flera plattformar som gör anspråk på samma försäljning, hur deduplicering fungerar på Meta, TikTok, Snapchat, Pinterest och Reddit och hur du hittar och åtgärdar dubbletter.

Vad räknas som en dubblerad köphändelse?

Två olika problem kallas båda dubbelräkning. De har olika orsaker, och bara det ena är ett trackingfel.

	Dubblett inom en plattform	Flera plattformar gör anspråk på en försäljning
Vad som händer	En plattform räknar samma order mer än en gång	Flera plattformar tar var och en åt sig äran för samma order
Exempel	Meta visar 2 köp för en order på $80	Meta, Google och TikTok rapporterar alla samma order på $80
Orsak	Två händelser för en order utan gemensamt händelse-id	Varje plattform tillskriver försäljningen enligt sina egna attributionsregler
Åtgärdas med deduplicering	Ja	Nej
Vad du ska göra	En avsändare per pixel och ett händelse-id per order	Jämför med dina butiksordrar och använd en enda attributionsmodell

Deduplicering löser det första problemet. Det andra kräver din egen orderdata.

Därför räknas köp två gånger

En webbläsarpixel och en serverhändelse utan gemensamt id

Många butiker skickar varje köp två gånger med flit: en gång från webbläsarpixeln och en gång från en server via ett Conversions API. Det är en bra uppsättning, eftersom serverkopian kommer fram när webbläsarkopian blockeras. Men plattformen kan bara slå ihop de två kopiorna när de har samma händelse-id och samma händelsenamn. Om webbläsaren använder ett slumpmässigt id och servern använder ordernumret ser plattformen två olika köp.

Två verktyg som skickar samma pixel

Den här orsaken är vanlig och lätt att missa, särskilt efter ett byte till ett nytt trackingverktyg. En butik installerar en trackingapp men behåller plattformens egen app för försäljningskanaler, en Google Tag Manager-tagg eller pixelkod i temat. Varje verktyg skickar sitt eget Purchase med egna id:n. Deduplicering inom varje verktyg fungerar, men plattformen tar ändå emot två orelaterade köp.

Samma händelse skickas igen

En köptagg på orderbekräftelsesidan kan utlösas igen när kunden laddar om eller besöker sidan på nytt. En server kan också skicka en order två gånger, till exempel en gång när den skapas och en gång när den betalas. Bygg händelse-id:t på order-id:t, så att en upprepning har samma id som den första kopian och plattformen kan känna igen den.

Hur fungerar deduplicering?

Deduplicering är hur en plattform behåller en kopia av en händelse som den har tagit emot mer än en gång. Regeln är likartad på plattformarna i den här guiden: kopiorna måste ha samma id, oftast tillsammans med samma händelsenamn, och de måste komma in inom ett tidsfönster. Plattformen behåller då en kopia och kastar resten.

browser Purchase event_id=order-1042Webbläsarpixel i kassan

server Purchase event_id=order-1042Conversions API, samma namn och id: slås ihop med den första

browser Purchase event_id=7c1e9a40En andra app på samma pixel, med eget id: räknas igen

De två första händelserna delar ett id och räknas som ett köp. Den tredje har ett eget id, så plattformen rapporterar två köp för order 1042.

Två praktiska regler följer av detta. Skapa id:t en gång, utifrån något som både webbläsaren och servern känner till, till exempel order-id:t. Och använd exakt samma händelsenamn på båda sidor, så som plattformen definierar det, till exempel Purchase på Meta.

Dedupliceringsregler per plattform

Detaljerna skiljer sig åt mellan plattformarna. Tabellen sammanfattar varje plattforms officiella dokumentation i oktober 2026.

Plattform	Webbläsarfält	Serverfält	Fönster	Anmärkningar
Meta	`eventID`	`event_id`	48 timmar	Händelsenamnet måste också matcha. En reservlösning med fbp eller external_id fungerar bara när webbläsarhändelsen kommer först.
TikTok	`event_id`	`event_id`	48 timmar	Händelsenamnet måste också matcha. TikTok behåller den första händelsen den tar emot.
Snapchat	`client_dedup_id` och `transaction_id` för köp	`event_id` och `order_id` för köp	48 timmar, eller 30 dagar för köpets order-id	Händelsenamnet måste också matcha. Paret client_dedup_id har företräde.
Pinterest	`event_id`	`event_id`	48 timmar	Skicka samma händelsenamn från båda källorna. Pinterest behåller den första händelsen den tar emot.
Reddit	`conversionId`	`conversion_id`	2 dagar	Samma händelsetyp, och samma namn för anpassade händelser. Körs varje timme och kan ta upp till 24 timmar att visas.

Den gemensamma regeln: samma händelse, samma id, inom fönstret. Fältnamnen skiljer sig åt, så kontrollera varje integration för sig.

I ROASaurus skickar webbläsarpixlarna för Meta, TikTok, Snapchat, Pinterest och Reddit samma händelse-id som serverhändelserna, så de plattformarna deduplicerar. För Snapchat skickar pixeln dessutom order-id:t som transaction_id, vilket motsvarar order_id i serverköpet. För Pinterest använder Tag och API:et matchande händelsenamn. X, Microsoft Advertising och Taboola tar bara emot serverhändelser, så där finns inget att slå ihop. Om du skickar händelser själv visar guiden om Meta Conversions API var händelse-id:t ska in i pixeln och i API-anropet.

Att flera plattformar gör anspråk på en försäljning är ingen dubblerad händelse

Nu det andra problemet. En kund tittar på en TikTok-video, klickar på en Google Shopping-annons två dagar senare och köper efter en Meta-annons för retargeting. Varje plattform har sin egen uppgift om ett klick eller en visning, och var och en rapporterar försäljningen. Ingen händelse har skickats två gånger, så ingen dedupliceringsinställning ändrar detta.

Intäkter som plattformarna gör anspråk på under en vecka (exempelbutik)

Så hittar du dubbla köphändelser

Jämför varje källa med dina ordrar
Ta en hel dag. Räkna de Purchase-händelser som varje källa skickade den dagen, före deduplicering: webbläsarpixeln och serverhändelserna. Vissa händelseverktyg visar den uppdelningen per anslutningsmetod, och ditt verktyg för server-side tracking har en egen logg över vad det skickade. Jämför varje tal med antalet ordrar som din butik tog emot den dagen.
Läs dedupliceringsrapporterna
Vissa plattformar rapporterar de dubbletter de har tagit bort. Reddit för till exempel en logg över deduplicerade händelser i sju dagar, och Pinterest visar deduplicering per händelse i Ads Manager.
Lägg en testorder
Öppna plattformens vy för testhändelser och lägg en order. Du ska se ett Purchase från webbläsaren och ett från servern med samma händelse-id. Ett tredje Purchase, eller två olika id:n, visar orsaken.
Lista varje verktyg som kan skicka pixeln
Kontrollera appar för försäljningskanaler, containrar i tagghanteraren, temakod och äldre trackingappar. Ett webbläsartillägg som Meta Ads Data Advisor, tidigare Meta Pixel Helper, visar vilka pixelhändelser som utlöses på en sida.

Det första steget är den snabbaste kontrollen. En källa med en avsändare skickar högst ett köp per order. Webbläsarantalet är oftast lägre än dina ordrar, på grund av annonsblockerare och nekat samtycke. En enskild källa med fler köp än ordrar tyder därför på en andra avsändare eller på upprepade händelser:

Källa (exempelbutik, en dag)	Köp	Butiksordrar	Kvot	Vad det tyder på
Meta, webbläsare	186	120	1.55	Fler köp än ordrar: två verktyg utlöser webbläsarpixeln
Meta, server	119	120	0.99	Normalt: en serveravsändare
TikTok, server	241	120	2.01	Varje order två gånger: två appar skickar Events API

Antal per källa, före deduplicering. En kvot över 1.0 betyder att källan skickar vissa ordrar två gånger. En kvot nära 2.0 betyder att den skickar nästan varje order två gånger.

Så åtgärdar du dubbla köphändelser

Håll en avsändare per pixel. Välj ett verktyg för varje pixel och stäng av pixeln överallt annars: appar för försäljningskanaler, taggar i tagghanteraren och temakod. På Shopify tar du bort samma pixel från inställningarna för datadelning i kanalen Facebook & Instagram, eftersom varje nivå av datadelning fortfarande skickar webbläsarpixeln. Kontrollera TikTok-appen på samma sätt.
Använd ett händelse-id per order. Bygg id:t på order-id:t och skicka det med både webbläsarhändelsen och serverhändelsen.
Använd samma händelsenamn. Webbläsaren och servern måste namnge händelsen på samma sätt, exakt som plattformen definierar den.
Skicka inom fönstret. En serverhändelse som kommer fram dagar senare slås inte ihop. På Meta, TikTok och Pinterest är fönstret 48 timmar, på Reddit två dagar.
Testa igen efter varje ändring. Upprepa testordern och jämför antalen igen nästa dag.

Så undviker ROASaurus dubbla köphändelser

ROASaurus skickar varje köp utifrån butikens orderdata och ger webbläsarkopian och serverkopian samma händelse-id, byggt på order-id:t. På Shopify kommer serverhändelsen från webhooken för betald order, så en omladdning av tacksidan skapar ingen ny serverhändelse. Event log listar varje serverleverans per plattform, med förfrågan och plattformens svar, så att du kan se vad som skickades för varje order. Guiden om server-side tracking på Shopify visar hela flödet.

Om en plattform fortfarande visar fler köp än ordrar skickar ett annat verktyg samma pixel. Undvika dubbelräkning listar var du ska leta, och server-side tracking förklarar vilka händelser ROASaurus skickar till varje plattform.

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.TrackingSafari ITP och annonstracking: vad som fortfarande fungerarSafari ITP begränsar cookies som sätts av skript till 7 dagar, eller 24 timmar efter vissa annonsklick. Se hur det påverkar attributionen och vilken tracking som fortfarande fungerar.