Platforms

Conversions API versus de Meta-pixel

De vraag achter Conversions API versus de Meta-pixel is welke machine verstuurt. De pixel is javascript in de browser van je bezoeker; de Conversions API is een HTTP-aanroep vanaf een server die jij beheert. Meta accepteert allebei, en verwacht allebei.

Dat laatste is wat de meeste vergelijkingen missen. Dit is geen keuze tussen twee opties.

Wat elk van de twee ziet

De pixel draait op de pagina. Hij weet wat daar stond: de URL, de verwijzer, waarop geklikt is, wat de browser over zichzelf meldt. Hij zet en leest een cookie in een first-party context. En hij wordt tegengehouden door blokkeerders, ingekort door tracking-preventie, en helemaal kwijtgeraakt als een bezoeker het tabblad sluit voordat hij afgaat.

De Conversions API draait op een server. Niets in de browser kan hem blokkeren. Hij kan parameters meesturen die jouw systemen kennen en de browser nooit had — een orderbedrag dat je backend bevestigt in plaats van een schatting in de pagina. Wat hij niet kan is de pagina zien.

Conversions API versus de Meta-pixel: waarom Meta ze allebei wil

De twee routes falen op andere plekken. Dat is het hele argument om ze samen te draaien: een aankoop die de pixel kwijtraakt wordt vaak nog door de server gemeld, en andersom.

Meta brengt ze samen met een event-ID. Je stuurt op beide routes hetzelfde kenmerk mee voor dezelfde handeling, en Meta houdt er één. Welke kopie overleeft bepaal je niet, en dat maakt niet uit.

Stuur je allebei zonder event-ID, dan verdubbelen je conversies ruwweg. Dat is de meest gemaakte fout in deze opzet, en de oplossing is het kenmerk — niet één van de routes uitzetten.

Wat het niet verandert

De Conversions API verzamelt niet meer over je bezoeker. Hij stuurt dezelfde gebeurtenissen over een route die vaker aankomt. Heeft je site nooit een e-mailadres of orderbedrag opgehaald, dan heeft de server niets om mee aan te vullen.

Toestemming geldt voor beide routes even hard. Server-side versturen is geen omweg om een toestemmingskeuze heen, en het zo behandelen is een nalevingsprobleem in plaats van een slimme instelling.

Waar de server vandaan komt

Je kunt het adres van Meta aanroepen vanuit je eigen backend, of een server-side tagbeheerder draaien die het als instelling doet. Die tweede is wat de meesten met server-side tagging bedoelen, en heeft als voordeel dat dezelfde gebeurtenis ook Google, LinkedIn en TikTok kan voeden.

Het stuk over de Meta Conversions API behandelt die opzet. Wat is de Conversions API is het bredere beeld over platformen heen, en wat is server-side tagging is het mechanisme eronder.

Vragen die hierover gesteld worden

Moet ik de Meta-pixel vervangen door de Conversions API?
Nee. Meta adviseert zelf om ze allebei te draaien en ertussen te ontdubbelen. De pixel meldt wat de browser kan zien, de Conversions API meldt vanaf een server die blokkeerders niet tegenhouden. De pixel weghalen gooit signalen weg die de server nooit had, zoals wat er op de pagina stond en waarop geklikt is.
Waar is het event-ID voor?
Daarmee herkent Meta dat een aankoop gemeld door de pixel en dezelfde aankoop gemeld door de server één gebeurtenis zijn en geen twee. Stuur op beide routes hetzelfde event-ID mee voor dezelfde handeling. Zonder dat zie je je conversies ruwweg verdubbelen.
Welke route wint als ze allebei aankomen?
Meta houdt er één en laat de dubbele vallen; welke kopie overleeft bepaal je niet en hoef je niet te weten. Wat telt is dat het kenmerk overeenkomt, want daar kijkt de ontdubbeling naar.
Verbetert de Conversions API de event match quality?
Meestal wel, omdat de server parameters kan meesturen die de browser liet vallen en het verzoek niet geblokkeerd wordt. Hij blijft begrensd door wat je site verzamelde: is er nooit een e-mailadres of orderbedrag opgehaald, dan heeft de server niets extra's te sturen.