Ga naar hoofdinhoud
SERVER-SIDEMETA ADS

Meta Conversions API — de match-rate die telt.

Pixel alleen lekt sinds iOS 14.5 conversies. Hoe je met de Conversions API, schone klantparameters en deduplicatie je Event Match Quality omhoog krijgt.

Door Mink HelwigOnderdeel van Tracking operations

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 we het vaakst zien.

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 APIstuurt 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 met fn/ln (voor-/achternaam), ct/st/zp/country (plaats, regio, postcode, land) en external_id (jouw eigen klant- of user-ID; hashen mag, maar is optioneel).
  • fbc en fbp worden NIET gehasht. fbc (afgeleid van de fbclid in de klik-URL) en fbp (de Pixel-browsercookie) zijn sterke, high-priority matching-signalen naast e-mail en telefoon. Stuur ze als platte waarde mee vanuit je server — bewaar fbclid bij de eerste pageview zodat je hem server-side beschikbaar hebt.
  • Ook handig: client_ip_address en client_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.

  1. Stuur vanuit beide bronnen hetzelfde event_id mee, plus dezelfde event_name. Meta gebruikt die combinatie om duplicaten te herkennen en er één van te houden.
  2. 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.
  3. Voor fbp/fbc geldt: 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.

  1. 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.
  2. 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.
  3. Dataset (Pixel) ID + access token. Genereer een access token (via Events Manager of een system user in Business Manager) voor de server-calls.
  4. Implementatie kiezen:(a) server-side GTM met de officiële Meta CAPI-tag — onze voorkeur voor bureaus, want één template over alle klanten; (b) Meta’s CAPI Gateway (gehost); (c) een partner-integratie (Shopify, WooCommerce); of (d) een directe Graph API-call vanuit je backend.
  5. Klantparameters mappen volgens sectie 03 — hashing, fbc/fbp, external_id — en het gedeelde event_id voor dedup.
  6. 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.

  1. Alleen de Pixel, geen CAPI. Je mist een groeiend deel van je conversies. Bij serieuze ad-spend op Meta is CAPI geen luxe meer.
  2. Verkeerde hash-encoding. Base64 in plaats van hex, of niet genormaliseerd vóór het hashen. Resultaat: lage EMQ zonder foutmelding.
  3. fbc/fbp niet meegestuurd. Sterke matching-signalen ontbreken omdat fbclid niet server-side beschikbaar is. Bewaar hem bij de eerste pageview.
  4. Geen of verkeerde deduplicatie. Verschillende event_id’s per bron → dubbeltellingen → verkeerde ROAS.
  5. 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.

  1. Pixel alleen lekt sinds iOS 14.5; draai Pixel + CAPI redundant.
  2. Event Match Quality meet je matching — verbeter hem met rijkere, schone klantparameters.
  3. Hash met SHA-256 hex (niet Base64), normaliseer eerst; stuur fbc/fbp ongehasht mee.
  4. Dedupliceer met een gedeeld event_id + event_name over beide bronnen.
  5. Setup: domein verifiëren, AEM controleren, token, implementatie via sGTM, valideren met Test Events.

// NIEUWSBRIEF

Stuur me toekomstige artikelen.

Eén mail per maand over tracking operations — nieuwe artikelen, updates over het product, bureau-lessen. Uitschrijven kan altijd.

Geen spam. Uitschrijven kan altijd via elke mail. Zie ons privacybeleid.

// EN NU?

Meta CAPI automatisch over al je klanten?

SignumCore deployt de sGTM Meta CAPI-setup met hashing, fbc/fbp en deduplicatie als herhaalbaar template — niet per klant opnieuw uitvogelen.