De Meta Conversions API is een manier om conversiegebeurtenissen naar Meta te sturen vanaf een server in plaats van vanuit de browser van je bezoeker. Hij bestaat omdat de browser geen betrouwbare afzender meer is — blokkeerders houden verzoeken tegen, tracking-preventie gooit cookies weg, en mensen sluiten het tabblad voordat de pixel afgaat. Wat je zo kwijtraakt is onzichtbaar: de gebeurtenis komt niet aan, en niets vertelt je dat.
Adverteer je op Meta en zijn je gerapporteerde conversies lager dan je werkelijke bestellingen, dan zit het gat meestal hier.
Wat de Meta Conversions API doet
De pixel draait in de browser en meldt wat hij kan zien. De Conversions API neemt dezelfde gebeurtenissen — een aankoop, een lead, een toevoeging aan het winkelmandje — en stuurt ze over HTTP vanaf een server die jij beheert.
Meta verwacht allebei, niet het een óf het ander. Elke gebeurtenis draagt een event-ID, en komt dezelfde aankoop twee keer binnen, dan ontdubbelt Meta op dat ID. Goed gedaan levert dat één conversie op, één keer geteld, gemeld via welke van de twee routes het ook haalde.
Dat laatste is het punt. Het is niet dat de serverroute principieel nauwkeuriger is. Het is dat hij op andere plekken faalt dan de browserroute, waardoor je samen minder kwijtraakt.
Waarom de pixel alleen niet meer genoeg is
Er gebeurden drie dingen tegelijk, en geen daarvan draait terug.
Blokkeerders werden goed in het herkennen van verzoeken aan bekende trackerdomeinen. De tracking-preventie van Safari ging de levensduur afkappen van cookies die door javascript worden gezet. En browsers werden in het algemeen minder bereid een pagina nog werk te laten doen op weg naar buiten — precies het moment waarop een aankoopgebeurtenis wil afgaan.
Niets daarvan houdt een verzoek tegen dat een server doet.
Waar server-side tagging past
Je hebt twee manieren om gebeurtenissen naar de Conversions API te sturen.
Zelf de koppeling schrijven. Je backend bouwt het bericht en post het naar het adres van Meta. Volledige controle, en vanaf nu heb je een koppeling die stukgaat als Meta het formaat wijzigt.
Een server-side tagbeheerder draaien. Een servercontainer van Google Tag Manager ontvangt gebeurtenissen van je site en stuurt ze door naar Meta, als instelling in plaats van code. Dezelfde container voedt ook Google Ads, GA4, TikTok en LinkedIn vanuit dezelfde gebeurtenis, en dat is meestal wat de doorslag geeft — niemand wil vier losse koppelingen voor één aankoop.
Die tweede is wat server-side tagging in de praktijk betekent. Wat is server-side tagging behandelt het mechanisme volledig, en client-side versus server-side tracking is de kortere vergelijking.
Wat het niet oplost
Toestemming blijft gelden. Een server-side opzet maakt het makkelijker een toestemmingskeuze goed door te geven; het maakt hem niet overbodig.
Het verbetert geen gegevens die je nooit hebt verzameld. Stuurde de browser geen e-mailadres of orderbedrag, dan heeft de server niets om mee aan te vullen.
En het repareert geen verkeerd meetplan. Vuur je de aankoopgebeurtenis op de verkeerde pagina af, dan doe je dat voortaan ook vanaf een server, alleen betrouwbaarder.
Hoe je er komt
Je hebt een dataset bij Meta nodig, een servercontainer van Google Tag Manager, en ergens om die container te draaien op je eigen subdomein. Aan de slag loopt de opzet van begin tot eind door.
Kies je nog waar je hem draait, dan is server-side tracking tools vergeleken de volgende. Is je eerste vraag waar de gegevens staan, dan beantwoordt server-side tracking en de AVG die.
De rest van deze hoek
Meta is één platform van meerdere, en dezelfde servercontainer voedt de andere vanuit dezelfde gebeurtenis:
- Wat is de Conversions API — het bredere beeld, en hoe elk platform zijn versie noemt
- Conversions API versus de Meta-pixel — waarom allebei, en wat het event-ID doet
- Google Ads server-side tracking — hetzelfde idee zonder adres onder die naam
- GA4 server-side tracking — de analysehelft van dezelfde container