Pixel en Conversions API samen gebruiken: zo voorkom je dubbele metingen

Pixel en Conversions API samen gebruiken werkt zodra elk event via beide routes dezelfde naam en hetzelfde event-id draagt. Meta herkent de twee metingen dan als één en telt de aanvraag één keer. Ontbreekt dat gedeelde kenmerk, dan telt alles dubbel en stuur je je campagnes op cijfers die niet bestaan. Hieronder staat hoe je het inricht en controleert.

waarom meta zelf beide routes adviseert

In de eigen documentatie van Meta staat het advies aan adverteerders om de Conversions API naast de Meta-pixel te gebruiken. De twee routes zien niet hetzelfde. De pixel zit in de browser van je bezoeker en heeft daar de cookiewaarden fbp en fbc tot zijn beschikking. De koppeling vanaf je server (de Conversions API) geeft door wat jouw eigen systeem registreert, buiten de browser om.

Een meting die vanaf je server vertrekt hangt niet af van wat er in de browser van je bezoeker gebeurt. Wat je vanaf de server doorstuurt blijft wel gebonden aan de toestemming die je bezoeker gaf. Wat de Conversions API precies is en wanneer je hem nodig hebt staat in onze uitleg over de Meta Conversions API, en de bredere opzet van meten via je eigen server staat in het artikel over server side tracking.

hoe meta twee metingen als één herkent

Pas wanneer de eventnaam gelijk is én het event-id gelijk is, herkent Meta een pixel-event en een server-event als hetzelfde. In de browser heet dat veld eventID, op de server event_id. Dat staat in de documentatie van Meta over het ontdubbelen van pixel- en serverevents. Zonder die twee overeenkomsten ziet Meta twee losse aanvragen, ook al ging het om één ingevuld formulier.

Er zit een venster omheen. Volgens de documentatie van Meta gebeurt dat ontdubbelen alleen als het tweede event binnen 48 uur na het eerste met hetzelfde event-id binnenkomt. Komen beide events binnen en verschillen ze inhoudelijk niet, dan houdt Meta doorgaans het event dat het eerst binnenkwam.

Met alleen een browserbron of alleen een serverbron ontdubbelt Meta niets. Twee gelijke browserevents tellen dus allebei, ook als ze bij dezelfde handeling horen, want het ontdubbelen werkt over de twee bronnen heen en niet binnen één bron.

zo richt je pixel en server samen in

Begin bij de naam en het id, want daar valt de beslissing.

1. Kies je events en houd de standaardnamen aan. Kies per handeling één naam en gebruik die aan beide kanten, bijvoorbeeld Lead voor een verzonden formulier, Schedule voor een geboekte afspraak en Purchase voor een betaling.
2. Laat browser en server hetzelfde event-id gebruiken. Je site maakt bij de aanvraag één uniek kenmerk aan en geeft dat mee aan de pixel (eventID) en aan de server (event_id). Gaat het hier mis, dan ontdubbelt Meta niets en telt alles dubbel.
3. Stuur de klantgegevens gehasht mee vanaf de server. Meta beveelt aan mee te sturen: e-mailadres, IP-adres, voor- en achternaam, telefoonnummer, de cookiewaarden fbp en fbc, en de user agent van de browser. Persoonsgegevens zoals een e-mailadres gaan gehasht mee en zijn dus niet leesbaar.
4. Controleer in Events Manager of je events als ontdubbeld verschijnen. Doe een testaanvraag op je eigen site en kijk of Meta één gebeurtenis toont in plaats van twee.
5. Stuur in realtime door. Events in realtime of dicht daarbij delen geeft campagnes de beste resultaten, volgens de documentatie van Meta.

Wij meten bij klanten via een formulier op hun eigen site en registreren die inzendingen server-side. Draait de funnel in GoHighLevel (GHL), dan staat de browser-pixel in de tracking-code van de funnelinstellingen en loopt de serverkant via de tab Gebeurtenissen, die de trackinggegevens rechtstreeks naar Meta stuurt; het veld voor een toegangstoken daar verraadt dat het om de Conversions API gaat. Waar GHL het niet kan, vullen we de Conversions API aan met n8n.

wat de browser levert en wat de server levert

De twee routes vullen elkaar aan omdat ze op verschillende punten sterk zijn. De browser weet bij welke advertentie een bezoek hoort; de server krijgt de aanvraag hoe dan ook bij Meta.

hoe goed meta je aanvraag kan koppelen

De kwaliteit van je servermeting hangt af van de gegevens die je meestuurt. Meta drukt dat uit in de event match quality: volgens de documentatie van Meta een score tot 10 die aangeeft hoe goed de klantgegevens bij een serverevent te koppelen zijn aan een Meta-account. Hoe meer bruikbare velden meekomen, hoe vaker Meta de aanvraag aan een echt persoon kan verbinden.

In gewone taal: je server geeft door dát er iemand een formulier invulde en stuurt genoeg kenmerken mee om die persoon te herkennen. Wat je meestuurt blijft gebonden aan de toestemming die je bezoeker gaf; de cookiebanner blijft leidend.

wanneer één laag beter is dan twee

Lukt het niet om browser en server betrouwbaar hetzelfde event-id te geven, kies dan één laag en zet de andere uit. Twee lagen die dubbel tellen zijn slechter dan één laag die klopt: je optimaliseert op aanvragen die er niet zijn en je kostprijs per aanvraag lijkt lager dan hij is.

Moet je kiezen, dan houden wij de server aan, omdat die buiten de browser om loopt. Zet de pixel er weer bij zodra het gedeelde event-id staat en je in Events Manager ziet dat gebeurtenissen als ontdubbeld binnenkomen. Draai je nog geen campagnes op aanvragen, dan is deze hele inrichting niet je eerste stap; zorg eerst dat er iets te meten valt. Aan de keuze zelf verdienen wij niets.

Wil je pixel en server niet zelf aan elkaar knopen, dan staat op server side tracking laten inrichten hoe wij dat doen en hoe lang het duurt.

veelgestelde vragen

wat is een event-id bij meta?

Een event-id is een uniek kenmerk dat je aan een gebeurtenis hangt, zodat Meta twee metingen van dezelfde handeling kan herkennen. In de browser geef je het mee als eventID, vanaf de server als event_id. In de documentatie van Meta staat het zo: een pixel-event en een server-event gelden alleen als hetzelfde wanneer zowel de eventnaam als het event-id gelijk zijn.

hoe zie ik of mijn events ontdubbeld worden?

Dat controleer je in Events Manager bij Meta: doe een testaanvraag op je eigen site en kijk of de gebeurtenis één keer verschijnt in plaats van twee keer. Let daarbij op het venster, want volgens de documentatie van Meta ontdubbelt Meta alleen als het tweede event binnen 48 uur na het eerste met hetzelfde event-id binnenkomt. Blijf je twee losse gebeurtenissen zien, dan verschilt de eventnaam of het event-id tussen browser en server.

wat is een goede event match quality?

De event match quality is volgens de documentatie van Meta een score tot 10 die aangeeft hoe goed de klantgegevens bij een serverevent te koppelen zijn aan een Meta-account, en hoger is beter. Een streefgetal noemen wij niet, wel wat helpt: Meta beveelt aan om e-mailadres, IP-adres, voor- en achternaam, telefoonnummer, de cookiewaarden fbp en fbc en de user agent van de browser mee te sturen. Hoe meer van die velden je betrouwbaar meestuurt, hoe hoger de score uitvalt.

moet ik e-mailadressen echt hashen?

Ja, persoonsgegevens zoals een e-mailadres worden gehasht meegestuurd naar Meta en zijn dus niet leesbaar. Hashen zet het adres om in een onleesbare reeks tekens waarmee Meta alleen kan vergelijken, niet teruglezen. Controleer bij je eigen koppeling of dat hashen automatisch gebeurt voordat je klantgegevens laat doorsturen.

wat gebeurt er als ik alleen de conversions api gebruik?

Gebruik je alleen de Conversions API, dan meet je zonder browserlaag, en dat werkt. Volgens de documentatie van Meta ontdubbelt Meta niets bij één bron, dus elke gebeurtenis komt binnen zoals jij hem stuurt. Je mist bovendien de klik-context uit de browser, waaronder de cookiewaarden fbp en fbc, tenzij je die vanaf je site meegeeft aan het serverevent. Meta adviseert zelf de Conversions API naast de pixel te gebruiken.

Wil je weten of jouw pixel en server dezelfde gebeurtenis beschrijven voordat er meer budget op gaat? We kijken in een half uur met je mee, en als het al klopt is dat het eerlijke antwoord. App me en plan een gesprek van dertig minuten.