Problemen oplossenMeta
Meta CAPI dedupliceert niet: los dubbele events op
Rapporteren Meta Pixel en CAPI dezelfde aankoop twee keer? Diagnosticeer event_id-mismatches en dubbele bronnen, en verifieer dedup in Events Manager.
- Gepubliceerd
- Gecontroleerd
Diagnose
- Platform Meta
- Gebruikelijke oorzaak De browser- en serverevents delen niet dezelfde event_name en event_id.
- Oorzaken, op volgorde 4
- Hoe je het diagnosticeert 7
Eerste antwoord gratis, binnen één werkdag. Beschrijf je situatie
Klinkt bekend?
Het symptoom
De korte versie
Direct antwoord
Meta dedupliceert een Pixel-event en een CAPI-event alleen wanneer beide exact dezelfde event_name en event_id dragen voor dezelfde actie.
Als een van de twee waarden verschilt — of als twee onafhankelijke systemen, zoals het native Meta & Instagram-kanaal van Shopify en een apart geconfigureerde GTM-opzet, beide Purchase versturen voor dezelfde order zonder een event_id-schema te delen — heeft Meta geen manier om te weten dat het duplicaten zijn, en telt het ze allebei. De Test Events-tool van Events Manager laat dit direct zien: een correct gededupliceerde aankoop verschijnt één keer, gemarkeerd als samengevoegd uit twee bronnen, niet als twee aparte rijen.
Waar je moet kijken
Oorzaken, op volgorde
Pixel en CAPI tellen dubbel4 oorzaken
-
Geen gedeeld event_id
De Pixel-call in de browser en de CAPI-call op de server genereren hunevent_idonafhankelijk van elkaar in plaats van één gedeelde waarde te gebruiken (doorgaans het order- of checkout-token van Shopify) — waardoor Meta niets heeft om ze op te matchen. -
Twee onafhankelijke systemen die parallel afgaan
Het native Facebook & Instagram-verkoopkanaal van Shopify en een aparte, op GTM gebaseerde Meta Pixel/CAPI-opzet, tegelijk geïnstrumenteerd, elk met zijn eigen event_id-logica die niets van de ander weet. Dit is verreweg de meest voorkomende oorzaak van een ruwweg verdubbeld purchase-aantal. -
Mismatch in event_name
Deduplicatie werkt op basis vanevent_nameplusevent_idsamen. Als de serverPurchaseverstuurt maar het browser-event anders is getagd, probeert Meta ze niet eens te matchen — het behandelt ze terecht als verschillende events, wat een ontwerpkeuze is, geen bug, maar wel hetzelfde opgeblazen aantal oplevert. -
Late CAPI-aflevering
Als serverevents worden gebundeld en pas ruim na het browserevent worden verzonden, kunnen ze buiten het venster aankomen dat Meta gebruikt om events te matchen, en worden ze apart geteld, ook met een correcte event_id.
7 stappen
Hoe je het diagnosticeert
Werk ze in deze volgorde af.
- Selecteer in Meta Events Manager → Data Sources je Pixel/dataset en open het tabblad Overview. Controleer het deduplicatiecijfer voor het Purchase-event.
- Open Events Manager → Test Events, activeer een echte of testaankoop, en let erop of zowel het browser- als het server-Purchase-event verschijnen. Een werkende opzet toont één samengevoegd, gemarkeerd event — geen twee ongefuseerde rijen.
- Open op de bedankpagina het netwerktabblad van de browser, zoek de uitgaande Pixel-call (
fbevents.js-verzoek) en noteer de meegestuurdeevent_id-parameter. - Controleer aan de serverkant wat CAPI verstuurt voor diezelfde order — Settings → Customer events van Shopify (bij gebruik van het native kanaal) of de Meta CAPI-tag in je GTM-servercontainer — en bevestig dat de
event_iddie voor diezelfde order wordt verstuurd, exact overeenkomt met de waarde van de browser. - Controleer in Shopify Admin → Settings → Apps and sales channels of het Facebook & Instagram-kanaal tegelijk geïnstalleerd is met een aparte Meta-implementatie in GTM. Beide tegelijk draaien is verreweg de meest voorkomende oorzaak van een verdubbeld aantal.
- Bevestig de gelijkheid van
event_name— beide kanten moeten exactPurchaseversturen, met hetzelfde hoofdlettergebruik en dezelfde spelling, wil de deduplicatiesleutel überhaupt van toepassing zijn. - Vergelijk in Test Events de tijdstempels tussen het browserevent en het CAPI-event voor dezelfde order — een groot verschil wijst op een bundelingsvertraging die het serverevent buiten het matchingvenster duwt.
Signaal en oplossing
Beslissingstabel
| Oorzaak | Signaal dat je ziet | Oplossing |
|---|---|---|
| Geen gedeeld event_id | Test Events toont twee aparte Purchase-rijen voor dezelfde order, geen deduplicatie-indicator | Genereer één event_id per order (bijv. het checkout-token) en geef exact dezelfde waarde mee aan zowel de Pixel-call als de CAPI-call |
| Native kanaal + GTM gaan allebei af | Purchase-aantal ligt ruwweg dubbel zo hoog als het echte orderaantal; zowel een native Meta-kanaal als een aparte GTM-opzet zijn geïnstalleerd | Kies één systeem als bron van waarheid voor Purchase-events en schakel het uit in het andere |
| Mismatch in event_name | Deduplicatieratio blijft dicht bij nul, terwijl beide kanten duidelijk afgaan | Stem event_name exact af (Purchase) en zorg voor gelijke schrijfwijze van parameters in browser- en server-calls |
| Late CAPI-aflevering | Browserevent gaat meteen af; het bijbehorende CAPI-event verschijnt veel later in Test Events | Verstuur CAPI-events synchroon bij het aanmaken van de order in plaats van in een vertraagde batch |
Een notitie van Daniilvoordat je beslist
Los je het zelf op of schakel je hulp in?
Het overzicht en Test Events van Events Manager controleren, en nagaan of zowel een native kanaal als een aparte GTM-opzet geïnstalleerd zijn, is iets wat de meeste handelaars rechtstreeks in de beheerpanelen kunnen doen — geen code nodig.
Waar een ontwikkelaar nodig is, is bij het genereren en consistent doorvoeren van een event_id door zowel de thema-/pixelcode als wat CAPI verstuurt, of bij het beslissen welk van twee overlappende systemen je behoudt en het schoon migreren weg van het andere.
Als duplicaten aanhouden nadat je hebt bevestigd dat er maar één systeem actief is en de event-namen overeenkomen, moet de event_id-generatielogica zelf worden herzien — dat is werk voor Meta Conversions API, geen instellingswijziging.
— Daniil
Volgende stap
Als de zelfcheck geen uitsluitsel geeft.
De checks hierboven vinden de oorzaak in de meeste winkels. Overlappen er twee of meer, dan is een afstemming per bestelling sneller dan nog een middag dashboards vergelijken.
Tracking Health Check
- Prijs
- EUR 375
- Toegang
- Alleen-lezen
- Doorlooptijd
- oordeel twee werkdagen na de kickoff
Wat de afstemming laat zien voor dit symptoom.
Een Health Check stemt dit symptoom bestelling voor bestelling af met je Shopify-bestellingen, zodat de oorzaak een feit uit je eigen data is en geen gok op basis van een dashboard. Echte cijfers voor dit symptoom zijn nog niet gepubliceerd — vraag om het voorbeeldrapport.
Volg de bestelling. Vergelijk daarna het bewijs.
- Echte bestellingBestel-ID, bedrag, valuta
- Browser- / servereventsToestemming, event-ID, aflevering
- GA4 / advertentieplatformsOntvangen events en rapportage
- Gegevens afstemmenVergelijk IDs, perioden en definities
Vragen
Vragen die dit symptoom oproept
Wat is een event_id precies?
Het is een unieke identifier die je één keer per actie genereert — één per order, niet per verzonden event — en die je koppelt aan zowel de Pixel-call in de browser als de CAPI-call op de server voor diezelfde actie. Meta gebruikt het paar event_name en event_id om te herkennen dat twee events dezelfde actie uit de echte wereld beschrijven en dat ze moeten worden samengevoegd tot één, niet twee.
Kan ik Pixel en CAPI helemaal zonder deduplicatie draaien?
Dat kan, maar dat moet je niet doen. Zonder gedeeld event_id wordt elke actie die de browser kan zien en die de server ook rapporteert dubbel geteld — waardoor je conversieaantal en ROAS worden opgeblazen op een manier die er goed uitziet, totdat je je uitgaven opschaalt tegen cijfers die niet echt zijn.
Hoe weet ik of dedup echt werkt, in plaats van dat er simpelweg geen duplicaten zijn?
Controleer de Test Events-tool van Events Manager tijdens een echte of een testaankoop. Als Pixel en CAPI allebei afgaan en correct werken, zie je beide events vermeld met een deduplicatie-indicator die laat zien dat ze zijn samengevoegd tot één geteld event — niet alleen de afwezigheid van een tweede rij.
Handelt het native Meta-kanaal van Shopify deduplicatie al voor mij af?
Het handelt dat binnen zichzelf correct af — de eigen Pixel- en CAPI-calls van het native kanaal delen standaard een event_id. Het misgaat wanneer je het native kanaal tegelijk met een aparte, op GTM gebaseerde Meta-configuratie draait, wat een tweede, onafhankelijk event_id-schema introduceert dat Meta op geen enkele manier tegen het eerste kan reconciliëren.
Lees verder, of check een verwant symptoom.
Alle symptomen- Dienst Herstel van Meta Conversions API — deduplicatie en matchkwaliteit
- Artikel Meta CAPI-deduplicatie: hoe event_id echt werkt
- Problemen oplossen Meta rapporteert meer aankopen dan Shopify: diagnose
- Kennisbank Wat is event_id? (deduplicatie van Meta Pixel + CAPI)
- Kennisbank Wat is Meta Event Match Quality (EMQ)?
- Problemen oplossen GA4 registreert geen aankopen op Shopify: diagnose
Hoi, ik ben Daniil.
Ik werk met je samen, van probleemdefinitie tot implementatie en overdracht. Je praat met degene die het werk doet. Ik werk in het Engels en het Russisch.
Geprobeerd en kom je er nog niet uit?
Beschrijf je taakHet eerste antwoord is gratis, binnen één werkdag. Of schrijf rechtstreeks: next@taskfordaniel.com