Sinds Apple in april 2021 met iOS 14.5 het App Tracking Transparency-kader uitrolde, ziet de browser-Pixel van Meta een steeds kleiner deel van wat er werkelijk gebeurt. Adblockers, ITP in Safari, en consent-weigeringen doen de rest. Het gevolg: campagnes optimaliseren op onvolledige signalen, en je rapportage onderschat structureel wat Meta oplevert.
De Conversions API (CAPI) is Meta’s antwoord daarop: je stuurt conversie-events server-to-server, naast de Pixel. Maar CAPI “aanzetten” is niet genoeg — het verschil zit in de kwaliteit van de meegestuurde klantparameters (zichtbaar als Event Match Quality) en in correcte deduplicatie. Deze gids loopt beide langs, plus de setup en de fouten die het vaakst voorkomen.
Waarom je ze allebei draait.
De Meta Pixel draait in de browser: JavaScript dat events (PageView, ViewContent, AddToCart, Purchase) en browser-signalen (fbp-cookie, fbc uit de fbclid in de klik-URL) naar Meta stuurt. Krachtig, maar afhankelijk van wat de browser toelaat.
De Conversions API stuurt diezelfde events vanaf je server (via server-side GTM, Meta’s CAPI Gateway, een partner-integratie zoals Shopify, of een directe Graph API-call). Server-side events worden niet geblokkeerd door adblockers of ITP en kunnen rijkere klantdata meesturen.
Meta’s eigen advies is redundante setup: stuur elk belangrijk event zowel via de Pixel als via CAPI. De Pixel levert browser-signalen die server-side lastig te reproduceren zijn (zoals fbp); CAPI levert betrouwbaarheid en extra klantparameters. Samen geven ze de hoogste match — mits je dubbeltellingen voorkomt (zie deduplicatie).
De score die je matching meet.
Event Match Quality (EMQ) is een kwaliteitsbeoordeling die Meta per event toont in Events Manager (van een lage tot een hoge score). Het meet hoe goed de klantparameters die je meestuurt Meta in staat stellen het event te koppelen aan een Meta-account. Hoe hoger de EMQ, hoe meer conversies aan klikken worden toegeschreven — en hoe beter de campagne-optimalisatie en je rapportage.
EMQ is geen advertentie-relevantiescore en geen garantie — het is een diagnostische data-kwaliteitsmetric. Maar betere matching voedt wél Meta’s optimalisatie en attributie. Een lage score betekent bijna altijd: te weinig of te “vuile” klantparameters. De oplossing is niet meer events sturen, maar rijkere en schonere parameters per event.
Praktisch mikpunt: zorg dat je belangrijkste events (Purchase, Lead) in het groene gebied zitten. De grootste sprongen komen meestal van een gehasht e-mailadres én telefoonnummer (Meta’s sterkste signalen), aangevuld met fbc/fbp en external_id.
Wat je meestuurt — en hoe.
Meta matcht op customer information parameters. De persoonsgegevens daarvan moeten genormaliseerd en gehasht worden voordat ze je server verlaten — Meta ziet nooit de ruwe waarde:
- Hashen met SHA-256, hex-encoded. Let op: Meta verwacht hexadecimale SHA-256 (LinkedIn vraagt juist Base64 — niet verwisselen). Normaliseer eerst. E-mail: trim + lowercase. Telefoon: alleen cijfers, met landcode, zonder symbolen, plus-teken of leidende nullen.
- Meer signalen = hogere match. E-mail (
em) en telefoon (ph) zijn Meta’s belangrijkste matching-signalen. Vul aan metfn/ln(voor-/achternaam),ct/st/zp/country(plaats, regio, postcode, land) enexternal_id(jouw eigen klant- of user-ID; hashen mag, maar is optioneel). fbcenfbpworden NIET gehasht.fbc(afgeleid van defbclidin de klik-URL) enfbp(de Pixel-browsercookie) zijn sterke, high-priority matching-signalen naast e-mail en telefoon. Stuur ze als platte waarde mee vanuit je server — bewaarfbclidbij de eerste pageview zodat je hem server-side beschikbaar hebt.- Ook handig:
client_ip_addressenclient_user_agent(origineel van de browser, niet die van je server) helpen Meta bij de matching.
Een verkeerde hash of een ontbrekende normalisatie levert geen foutmelding op — alleen een lagere EMQ. Dat maakt het verraderlijk: het “werkt”, maar matcht slecht.
Pixel + CAPI zonder dubbeltellen.
Als je hetzelfde event via de Pixel én via CAPI stuurt, moet Meta begrijpen dat het om één gebeurtenis gaat. Anders tel je conversies dubbel en verstoor je je biedingen en ROAS.
- Stuur vanuit beide bronnen hetzelfde
event_idmee, plus dezelfdeevent_name. Meta gebruikt die combinatie om duplicaten te herkennen en er één van te houden. - Genereer het
event_idéén keer per gebeurtenis (bijv. een order-ID of een random UUID) en geef het door aan zowel de browser-Pixel als de server-call — niet twee losse id’s. - Voor
fbp/fbcgeldt: stuur dezelfde waarden mee in beide bronnen, zodat Meta de events betrouwbaar koppelt binnen het deduplicatie-venster.
Controleer het resultaat in Events Manager: bij correcte dedup zie je je Pixel- en server-events samengevoegd, niet opgeteld.
Van domeinverificatie tot live.
- Domein verifiëren in Meta Business Manager (DNS-record, meta-tag of bestands-upload). Aanbevolen om eigenaarschap en controle over je events te houden; sinds de AEM-wijziging van 2025 niet langer strikt vereist voor event-configuratie, maar nog steeds best practice.
- Aggregated Event Measurement (AEM) controleren. AEM is Meta’s manier om web-conversies van opt-out-gebruikers (iOS 14+/ATT) te meten. Let op: Meta heeft medio 2025 de oude limiet van 8 events en de handmatige prioritering verwijderd — AEM aggregeert nu automatisch de in aanmerking komende web-events. Je hoeft dus geen 8-event-prioriteit meer in te stellen, maar controleer wel dat je belangrijkste conversies meekomen.
- Dataset (Pixel) ID + access token. Genereer een access token (via Events Manager of een system user in Business Manager) voor de server-calls.
- Implementatie kiezen: (a) server-side GTM met de officiële Meta CAPI-tag — de meest herhaalbare route, omdat je hem één keer inricht en daarna alleen nog events aanhangt; (b) Meta’s CAPI Gateway (gehost); (c) een partner-integratie (Shopify, WooCommerce); of (d) een directe Graph API-call vanuit je backend.
- Klantparameters mappen volgens sectie 03 — hashing,
fbc/fbp,external_id— en het gedeeldeevent_idvoor dedup. - Valideren via Test Events + Payload Helper in Events Manager. Stuur een test-conversie, controleer dat parameters aankomen, dat de hash klopt en dat de dedup werkt.
Waar het misgaat.
- Alleen de Pixel, geen CAPI. Je mist een groeiend deel van je conversies. Bij serieuze ad-spend op Meta is CAPI geen luxe meer.
- Verkeerde hash-encoding. Base64 in plaats van hex, of niet genormaliseerd vóór het hashen. Resultaat: lage EMQ zonder foutmelding.
fbc/fbpniet meegestuurd. Sterke matching-signalen ontbreken omdatfbclidniet server-side beschikbaar is. Bewaar hem bij de eerste pageview.- Geen of verkeerde deduplicatie. Verschillende
event_id’s per bron → dubbeltellingen → verkeerde ROAS. - Consent genegeerd. Stuur geen events voor bezoekers die marketing-consent weigerden. Koppel je CAPI-tags aan je Consent Mode v2-signaal
ad_user_data.
Samenvatting.
- Pixel alleen lekt sinds iOS 14.5; draai Pixel + CAPI redundant.
- Event Match Quality meet je matching — verbeter hem met rijkere, schone klantparameters.
- Hash met SHA-256 hex (niet Base64), normaliseer eerst; stuur
fbc/fbpongehasht mee. - Dedupliceer met een gedeeld
event_id+event_nameover beide bronnen. - Setup: domein verifiëren, AEM controleren, token, implementatie via sGTM, valideren met Test Events.


