← Alle cases

Meta Ads tracking: veel events dubbel geteld door foutieve deduplicatie

Een retail-webshop merkte dat de data in Meta Ads niet leek te kloppen. Het bedrijf adverteert via Facebook en Instagram en had zowel de Meta Pixel als de Meta Conversions API geïmplementeerd. Na een meekijksessie van ongeveer een uur bleek het probleem niet te zitten in het gebruik van zowel client-side als server-side tracking, maar in het ontdubbelen van events. Daardoor werden veel events dubbel geteld in Meta.

Organisatie

Retail-webshop, adverteert via Facebook en Instagram

Rol

Meekijksessie, klant voerde de aanpassing zelf uit

Onderdelen

Meta Pixel, Meta Conversions API, deduplicatie van events

Tools

GTM web container, GTM server container, Meta Events Manager

Doorlooptijd

Oorzaak gevonden in een videocall van ongeveer 60 minuten

Resultaat

Event coverage van 2,94% naar >75%, de streefwaarde van Meta, zonder de server-side setup opnieuw op te bouwen

De vraag

De vraag aan mij was simpel: gaat er iets mis met onze Meta Ads tracking, en zo ja, waar zit het probleem?

De uitgangssituatie

Het e-commercebedrijf had server-side tracking laten instellen door een marketingbureau. De samenwerking met dat bureau was inmiddels gestopt.

Omdat er twijfel was over de kwaliteit van de data in Meta Ads, had het bedrijf een gesprek gehad met Meta. Daar kwam uit dat de tracking niet volgens de gebruikelijke best practice was opgezet. Maar wat er precies misging, was niet duidelijk.

De setup bestond uit:

• een Meta Pixel in de client-side Google Tag Manager-container;
• de Meta Conversions API via server-side Google Tag Manager.

De klant vermoedde daarom dat juist die combinatie het probleem veroorzaakte.

Client-side én server-side Meta tracking is niet het probleem

Ik kreeg toegang tot zowel de GTM- als de server-side GTM-container. Tijdens een videocall van ongeveer 60 minuten heb ik de inrichting bekeken en het probleem stap voor stap teruggezocht.

Al snel bleek dat de aanname van de klant niet klopte. Dat Meta Ads zowel client-side als server-side was geïmplementeerd, was niet het probleem. Sterker nog: Meta raadt zelf aan om de Meta Pixel en de Conversions API naast elkaar te gebruiken. Het is dus een gebruikelijke manier om Meta-events te implementeren.

De reden is dat de browser en de server elkaar aanvullen:

• De browser (Pixel) ziet direct wat een bezoeker doet en plaatst de cookies fbp en fbc, waarmee Meta de bezoeker aan een advertentie kan koppelen. Maar de browser verliest events, bijvoorbeeld door adblockers, cookiebeperkingen of bezoekers die de pagina verlaten voordat het event is verstuurd.
• De server (Conversions API) stuurt events rechtstreeks vanuit je eigen systeem, onafhankelijk van de browser. Zo komt een aankoop ook door als de browser hem mist, en kun je gegevens uit je backend meesturen, zoals een bevestigde order of (gehashte) klantgegevens.
• Samen meet je meer acties en kan Meta bezoekers beter herkennen. Beide kanalen horen daarbij binnen de toestemming (consent) van de bezoeker te blijven.
• De voorwaarde is dat Meta kan zien welke browser- en server-events bij dezelfde actie horen. Zonder ontdubbeling telt Meta die aankoop twee keer.

Het probleem zat dus ergens anders: de twee events werden door Meta niet goed als hetzelfde event herkend.

Het probleem: events werden niet goed ontdubbeld

Bij een server-side implementatie kunnen er voor dezelfde actie twee events bij Meta binnenkomen. Bijvoorbeeld een aankoop:

1. De Meta Pixel stuurt een purchase-event vanuit de browser.
2. De Meta Conversions API stuurt hetzelfde purchase-event vanuit de server.

Meta moet vervolgens kunnen herkennen dat deze twee events eigenlijk bij dezelfde actie horen. Anders worden ze allebei als een afzonderlijk event geregistreerd.

Daarvoor gebruikt Meta zogenaamde deduplication keys: sleutels om events te ontdubbelen. De aanbevolen methode is de combinatie van event_id en event name. Als alternatief kan Meta de event name combineren met fbp en/of external_id, maar die route is zwakker. En precies daar ging het mis.

Illustratief voorbeeld, geen echte event_id's.

De event ID kwam niet overeen

In Meta Events Manager was duidelijk te zien dat de parameter event_id vrijwel altijd werd meegestuurd: client-side in 99,93% van de events, server-side in 100%. Op het eerste gezicht lijkt dat dus goed.

Maar het probleem zat in de waarde van die parameter. De event ID die vanuit de browser werd meegestuurd, was vrijwel nooit hetzelfde als de event ID die vanuit server-side werd meegestuurd. De twee events kwamen daardoor bij Meta binnen als twee verschillende events.

De event coverage voor deze sleutel was slechts 0,02%: in vrijwel geen enkel geval kon Meta een browser-event en een server-event via de event_id aan elkaar koppelen.

Ook de external ID kon het probleem niet oplossen

Meta kijkt bij het ontdubbelen niet alleen naar event_id. Een andere parameter die gebruikt kan worden is external_id: het eigen klant-ID van de webshop. Die parameter was client-side in 12,3% van de events aanwezig, maar kwam server-side in 0% van de events binnen. Ook via deze parameter kon Meta de twee events dus niet aan elkaar koppelen.

De fbp-cookie werkte wel, maar onvoldoende

Een derde parameter waar Meta naar kan kijken is fbp: een first-party cookie die de Meta Pixel in de browser plaatst zodra iemand de website bezoekt. Deze parameter kwam in 95,24% van de browser-events en 94,53% van de server-events goed door. Daardoor kon Meta een klein deel van de events alsnog herkennen als hetzelfde event.

De event coverage van fbp was echter slechts 2,92%. Over alle sleutels samen werd slechts 2,94% van de Pixel-events gedekt door de Conversions API met een gedeelde dedupliceringssleutel. Dat was bij lange na niet genoeg om events betrouwbaar te ontdubbelen.

Bron: Meta Events Manager, vóór de aanpassing.

Het gevolg: events konden dubbel worden geteld

De combinatie van deze problemen zorgde ervoor dat Meta browser-events en server-events vrijwel niet als hetzelfde event herkende. Dezelfde actie kon in Meta twee keer worden geregistreerd, zodra zowel de Pixel als de Conversions API dat event verstuurde.

Het aantal events in Meta kon daardoor hoger liggen dan het werkelijke aantal acties. Hoeveel hoger, hangt af van het aandeel events dat ook server-side werd verstuurd. Je toetst dat door de aantallen vóór ontdubbeling in Events Manager te vergelijken met de orders in de backend.

Het probleem was dus niet dat er te weinig data naar Meta ging, maar juist dat Meta dezelfde acties als afzonderlijke events kon registreren.

Event coverage in gewone taal

Event coverage laat zien bij welk deel van de events uit de browser Meta ook het bijbehorende event van de server herkent.

Denk aan twee tellers bij een winkel: de ene staat bij de deur (de browser), de andere bij de kassa (de server). De coverage zegt bij hoeveel bezoekers Meta kan vaststellen dat de teller bij de deur en de teller bij de kassa dezelfde persoon hebben geteld. In deze case was dat slechts 2,94%.

Wat er mis kan gaan bij een lage coverage

• Dubbel tellen. Meta ziet niet dat twee meldingen over dezelfde actie gaan en telt een aankoop of lead twee keer.
• Gemiste acties. Een lage coverage kan ook betekenen dat de server veel events helemaal niet verstuurt. Dan mis je acties die de browser niet doorgeeft, bijvoorbeeld door een adblocker of cookiebeperkingen.
• Cijfers die niet kloppen. Resultaten, kosten per conversie en rendement in Meta wijken af van je webshop of backend. Daardoor weet je niet meer welke campagne echt werkt.
• Slechtere optimalisatie. Meta leert van de data die je aanlevert. Onvolledige of dubbele data leidt tot minder goed gekozen doelgroepen en biedingen.
• Verkeerde beslissingen. Budget gaat naar campagnes die er beter uitzien dan ze zijn, en goede campagnes worden mogelijk te vroeg stopgezet.

Wat een hogere coverage oplevert

• Elke actie telt één keer. De cijfers in Meta komen dichter bij de werkelijkheid.
• Een vangnet voor gemiste events. Als de browser een actie niet doorgeeft, kan de server dat doen, binnen de kaders van de toestemming (consent) van de bezoeker.
• Meta kan beter optimaliseren. Meta krijgt een completer en betrouwbaarder beeld van wie converteert en kan advertenties daar beter op afstemmen.
• Betrouwbaarder rapporteren. Je kunt campagnes en budget beoordelen op data die je kunt vertrouwen.

De oplossing

De oplossing zat niet in het verwijderen van de Meta Pixel of het stoppen met server-side tracking. De bestaande architectuur, de Meta Pixel via client-side GTM én de Meta Conversions API via server-side GTM, kon blijven staan.

De oorzaak zat in de manier waarop de deduplication keys werden doorgegeven. De klant heeft met mijn instructies zelf twee dingen aangepast. Het eerste punt is nog tijdens de meekijksessie doorgevoerd. Het tweede had wat meer tijd nodig en is daarna aangepast, met een korte check via WhatsApp:

1. De event_id wordt nu één keer in de browser gedefinieerd en doorgestuurd naar server-side GTM. De Pixel en de Conversions API gebruiken daardoor dezelfde waarde voor dezelfde actie.
2. De external_id wordt nu ook meegestuurd, zodat deze sleutel in zowel de browser- als de server-side events aanwezig is.

Het resultaat

• De event coverage steeg van 2,94% naar >75%, de streefwaarde van Meta.
• De Pixel en de Conversions API gebruiken dezelfde event_id voor dezelfde actie.
• De external_id zit nu in zowel de browser- als de server-side events.
• De bestaande architectuur bleef staan: de server-side setup hoefde niet opnieuw te worden opgebouwd.

Wat deze case laat zien

Server-side tracking en client-side tracking botsen niet automatisch met elkaar. Een Meta Pixel in de browser én de Meta Conversions API via server-side GTM kunnen juist samen worden gebruikt. Het belangrijke onderdeel is dat Meta vervolgens kan herkennen welke browser- en server-events bij elkaar horen. Daarvoor moet het ontdubbelen goed zijn ingericht.

Als dat niet het geval is, kan een event twee keer worden gemeten. En als je vervolgens Meta Ads gebruikt om campagnes te beoordelen of te optimaliseren, stuur je op data die niet klopt.

In deze case zat het probleem niet in de keuze voor server-side tracking, maar in de details van de implementatie: de deduplication keys werden niet goed doorgegeven en kwamen niet overeen. Lees meer in server-side tracking: wanneer heb je het nodig en wanneer niet?