Pixel event deduplicatie: browser plus server zonder dubbel tellen

Browser en server events samen sturen is de juiste setup, tot Meta elke aankoop dubbel telt. Zo werkt deduplicatie en zo controleer je dat het echt klopt.

Als je hetzelfde event via de browser én via de server naar Meta stuurt, moet Meta weten dat het om één gebeurtenis gaat. Dat regelt deduplicatie: beide events krijgen dezelfde event naam en hetzelfde event ID, waardoor Meta het duplicaat herkent en er één telt. Gaat dat mis, dan telt elke aankoop dubbel, lijkt je ROAS ineens fantastisch en optimaliseert het algoritme op vervuilde data. In dit artikel leggen we uit hoe het werkt, waar het misgaat en hoe je controleert dat jouw setup echt klopt.

Waarom stuur je events überhaupt dubbel?

Het klinkt tegenstrijdig: waarom zou je hetzelfde event twee keer versturen om het vervolgens te ontdubbelen? Het antwoord is betrouwbaarheid. De browser pixel is kwetsbaar: adblockers, browserbeperkingen, geweigerde cookies en trage verbindingen zorgen dat een deel van je events nooit aankomt. De server kant heeft daar geen last van, maar mist soms weer context die de browser wel heeft. Door beide te sturen, vang je elkaars gaten op.

Die redundantie is dus een feature, geen fout. Meta moedigt het zelfs aan, omdat meer signaal betere optimalisatie betekent. De afspraak daarbij is simpel: als hetzelfde event via twee routes binnenkomt, zorg jij dat Meta kan zien dat het één gebeurtenis is. Dat is waar deduplicatie begint.

Hoe werkt deduplicatie precies?

Meta ontdubbelt op de combinatie van twee velden: de event naam en het event ID. Vuurt je browser een Purchase af met event ID “order_1234” en stuurt je server kort daarna óók een Purchase met event ID “order_1234”, dan herkent Meta het tweede event als duplicaat en telt er één. De eerste versie die binnenkomt wint, de tweede wordt genegeerd. Matchen de ID's niet, of heet het ene event Purchase en het andere CompletePayment, dan ziet Meta twee losse gebeurtenissen en tel je dubbel.

Het event ID zelf mag je vrij kiezen, zolang beide kanten exact dezelfde waarde gebruiken voor dezelfde gebeurtenis. In de praktijk is je ordernummer bijna altijd de beste keuze voor Purchase events: het is uniek per bestelling, bestaat aan beide kanten van je stack en maakt debugging leesbaar. Voor events zonder natuurlijk ID, zoals ViewContent, genereer je een unieke waarde op het moment van de gebeurtenis en geef je die aan beide routes mee.

Welke fouten zien we het vaakst?

• Geen event ID's meegeven: browser en server sturen allebei netjes hun events, maar zonder ID kan Meta ze niet koppelen.
• Verschillende ID's voor dezelfde gebeurtenis: de browser gebruikt een timestamp, de server het ordernummer, en niets matcht.
• Verschillende event namen tussen de routes, waardoor de ID match nooit wordt bereikt.
• Eén route stilletjes kapot: er wordt niets dubbel geteld, maar je draait zonder het te weten op de helft van je signaal.
• Deduplicatie één keer instellen en nooit meer controleren, terwijl een thema-update of nieuwe app de setup breekt.

Die laatste is de gemeenste. Deduplicatie is geen project dat je afrondt maar een onderdeel van je stack dat stuk kan gaan bij elke wijziging aan je site, je checkout of je tracking tools. Wie er nooit meer naar kijkt, ontdekt het probleem pas als de cijfers al weken niet meer kloppen.

Hoe controleer je dat het echt werkt?

Begin in Events Manager. Bij elk event zie je via welke kanalen het binnenkomt en of Meta duplicaten ontdubbelt; daar hoort bij een gezonde setup zichtbaar te zijn dat browser en server events worden samengevoegd. Gebruik daarnaast de testmodus: doe een testaankoop en volg of er precies één Purchase overblijft met het juiste event ID op beide routes.

De belangrijkste controle zit buiten Meta: vergelijk het aantal aankopen dat Meta over een periode rapporteert met het aantal bestellingen in je backend. Structureel veel meer aankopen in Meta dan in je shop wijst op dubbeltelling; structureel veel minder wijst op een kapotte route. Deze vergelijking is je rooktest, en je wilt hem periodiek herhalen, niet één keer bij de installatie.

Maak van die controle een vast ritueel met een vast moment, bijvoorbeeld aan het begin van elke maand, en na elke wijziging aan je checkout, thema of tracking apps. Het kost een kwartier en het beschermt elke schaalbeslissing die je daarna neemt. Wij doen deze vergelijking standaard voordat we bij een nieuw account budget verhogen, en het aantal keren dat er iets uit komt, blijft verrassen.

Dubbel getelde aankopen zijn erger dan gemiste aankopen: ze laten je opschalen op een ROAS die niet bestaat.

Conclusie

Browser plus server events is de juiste architectuur, maar alleen met werkende deduplicatie. Zorg dat elke gebeurtenis via beide routes dezelfde event naam en hetzelfde event ID meekrijgt, gebruik je ordernummer waar dat kan, en bewijs met een vergelijking tegen je backend dat er niets dubbel telt. Schone signalen zijn geen tracking hobby: het algoritme optimaliseert op wat jij het voert, en jij beslist op wat het teruggeeft.

Bij ons is dit standaard onderdeel van paid social beheer: voordat we budget opschalen, controleren we of het signaal klopt waarop dat budget stuurt. Twijfel je of jouw events dubbel tellen of juist half aankomen? Plan een call, dan kijken we graag met je mee naar je setup.