Mijn gebeurtenissen binnen Meta Gebeurtenisbeheer komen niet overeen met die van mijn site en GA4. Hoe kan dat?
Het is een veelvoorkomend probleem voor marketeers: de data die je ziet in Meta Gebeurtenisbeheer komt niet overeen met de gegevens in Google Analytics 4 (GA4) of op je eigen website. Dit kan verwarrend zijn, vooral als je probeert de prestaties van je campagnes nauwkeurig te evalueren. In dit artikel bespreken we de twee belangrijkste redenen waarom deze verschillen zich kunnen voordoen.
Een van de meest voorkomende oorzaken van verschillen tussen Meta Gebeurtenisbeheer en GA4 is het gebruik van verschillende conversie-attributiemodellen. Elk platform heeft zijn eigen manier om conversies aan bepaalde kanalen of interacties toe te wijzen.
Meta gebruikt meestal een attributiemodel gebaseerd op “last click” of “last touch”, waarbij de laatste interactie met een advertentie de volledige conversie toegewezen krijgt. Aan de andere kant biedt GA4 verschillende attributiemodellen, zoals first-click, time-decay en data-driven modellen. Dit betekent dat GA4 conversies anders kan toewijzen dan Meta, wat resulteert in verschillen in gerapporteerde cijfers.
Als een gebruiker eerst op een Meta Ads-advertentie klikt en een paar dagen later op een Google Ads-advertentie, zal de conversie binnen GA4 toegewezen worden aan Google Ads, terwijl Meta Ads de conversie aan zichzelf toekent. Beide advertentie-kanalen hebben dan meegeholpen aan de conversie, maar in GA4 of in de backend van je site krijg je alleen de gegevens te zien van de sessie waarin de conversie plaatsvindt. Dit verschil in attributie verklaart waarom de cijfers in beide platformen nooit overeen zullen komen.
Voor een diepere uitleg over conversie-attributie kun je ons blog-artikel over conversie-attributie raadplegen.
Als je het gevoel hebt dat (los van het attributie probleem) Meta Gebeurtenisbeheer nog steeds te veel events meet, kunnen er meerdere dingen aan de hand zijn.
Met een Server-Side Tagging setup wordt ieder event 2 keer gestuurd naar Meta. DIT IS NIET HET PROBLEEM. In de GTM web container wordt de gebeurtenis aangemaakt, vanuit daar wordt die gebeurtenis éénmaal direct naar Meta gestuurd vanuit de web client en éénmaal naar de server. De server container stuurt de gebeurtenis nogmaals naar Meta. Omdat zowel de events die uit de web container als de server container komen hetzelfde event-ID hebben, is Meta in staat deze events te dedupliceren. Dat zie je ook in onderstaande visualisatie, maar zie je dus ook wat er vaak fout kan gaan qua het driemaal ontvangen van een gebeurtenis.
Er ontstaan problemen wanneer er naast de Server-Side Tagging setup ook nog een pixel script van Meta zelf actief is op je website. Deze stuurt naast je tracking setup nogmaals dezelfde gemeten events. Hierdoor worden gebeurtenissen 3x ontvangen, waarvan er maar 2 gededupliceerd kunnen worden. Na de deduplicatie blijven er dus nog 2 gebeurtenisen over, daar komen dus dubbele events vandaan in je Meta events manager. Zorg er dus altijd voor dat je bij je SST setup het Meta pixel script of plugin hebt verwijderd van je website.
Net zoals bij het bovenstaande verhaal van de Meta Pixel, kan het zo zijn dat je een plugin op je website hebt die informatie naar Meta stuurt. Denk hierbij bijvoorbeeld aan de volgende plugins:
WooCommerce:
Facebook for WooCommerce
PixelYourSite
CTX feed
Shopify
Facebook & Instagram Application
De event setup tool is een tool van Meta waarmee je zonder pixel events kan meten op je website. Wanneer een gebruiker dan de ingestelde handeling op jouw website uitvoert wordt het event naar Meta gestuurd. Ook deze functionaliteit is bij een SST setup overbodig en moet zelfs uit staan. Wanneer deze wel aan staat loop je het risico dat events twee keer worden gemeten en twee keer naar Meta worden gestuurd. Voer de volgende stappen uit om dit te checken: Meta Gebeurtenistool checken
Los van verschillen in metingen die kunnen ontstaan door de verschillende attributie modellen die worden gebruikt door GA4 en Meta, is het zaak dat je naast je SST setup niks ander hebt meelopen wat mogelijk events kan sturen naar je Meta events manager. Denk hierbij aan de bovengenoemde Meta pixel, plugins op je website en losse metingen via de event setup tool.
Verschillende Conversie-attributiemodellen
Een van de meest voorkomende oorzaken van verschillen tussen Meta Gebeurtenisbeheer en GA4 is het gebruik van verschillende conversie-attributiemodellen. Elk platform heeft zijn eigen manier om conversies aan bepaalde kanalen of interacties toe te wijzen.
Meta gebruikt meestal een attributiemodel gebaseerd op “last click” of “last touch”, waarbij de laatste interactie met een advertentie de volledige conversie toegewezen krijgt. Aan de andere kant biedt GA4 verschillende attributiemodellen, zoals first-click, time-decay en data-driven modellen. Dit betekent dat GA4 conversies anders kan toewijzen dan Meta, wat resulteert in verschillen in gerapporteerde cijfers.
Als een gebruiker eerst op een Meta Ads-advertentie klikt en een paar dagen later op een Google Ads-advertentie, zal de conversie binnen GA4 toegewezen worden aan Google Ads, terwijl Meta Ads de conversie aan zichzelf toekent. Beide advertentie-kanalen hebben dan meegeholpen aan de conversie, maar in GA4 of in de backend van je site krijg je alleen de gegevens te zien van de sessie waarin de conversie plaatsvindt. Dit verschil in attributie verklaart waarom de cijfers in beide platformen nooit overeen zullen komen.
Voor een diepere uitleg over conversie-attributie kun je ons blog-artikel over conversie-attributie raadplegen.
Meta kan te veel gebeurtenissen meten
Als je het gevoel hebt dat (los van het attributie probleem) Meta Gebeurtenisbeheer nog steeds te veel events meet, kunnen er meerdere dingen aan de hand zijn.
Meta Pixel
Met een Server-Side Tagging setup wordt ieder event 2 keer gestuurd naar Meta. DIT IS NIET HET PROBLEEM. In de GTM web container wordt de gebeurtenis aangemaakt, vanuit daar wordt die gebeurtenis éénmaal direct naar Meta gestuurd vanuit de web client en éénmaal naar de server. De server container stuurt de gebeurtenis nogmaals naar Meta. Omdat zowel de events die uit de web container als de server container komen hetzelfde event-ID hebben, is Meta in staat deze events te dedupliceren. Dat zie je ook in onderstaande visualisatie, maar zie je dus ook wat er vaak fout kan gaan qua het driemaal ontvangen van een gebeurtenis.
Er ontstaan problemen wanneer er naast de Server-Side Tagging setup ook nog een pixel script van Meta zelf actief is op je website. Deze stuurt naast je tracking setup nogmaals dezelfde gemeten events. Hierdoor worden gebeurtenissen 3x ontvangen, waarvan er maar 2 gededupliceerd kunnen worden. Na de deduplicatie blijven er dus nog 2 gebeurtenisen over, daar komen dus dubbele events vandaan in je Meta events manager. Zorg er dus altijd voor dat je bij je SST setup het Meta pixel script of plugin hebt verwijderd van je website.
Plugins van derde
Net zoals bij het bovenstaande verhaal van de Meta Pixel, kan het zo zijn dat je een plugin op je website hebt die informatie naar Meta stuurt. Denk hierbij bijvoorbeeld aan de volgende plugins:
WooCommerce:
Facebook for WooCommerce
PixelYourSite
CTX feed
Shopify
Facebook & Instagram Application
De event setup tool
De event setup tool is een tool van Meta waarmee je zonder pixel events kan meten op je website. Wanneer een gebruiker dan de ingestelde handeling op jouw website uitvoert wordt het event naar Meta gestuurd. Ook deze functionaliteit is bij een SST setup overbodig en moet zelfs uit staan. Wanneer deze wel aan staat loop je het risico dat events twee keer worden gemeten en twee keer naar Meta worden gestuurd. Voer de volgende stappen uit om dit te checken: Meta Gebeurtenistool checken
Conclusie
Los van verschillen in metingen die kunnen ontstaan door de verschillende attributie modellen die worden gebruikt door GA4 en Meta, is het zaak dat je naast je SST setup niks ander hebt meelopen wat mogelijk events kan sturen naar je Meta events manager. Denk hierbij aan de bovengenoemde Meta pixel, plugins op je website en losse metingen via de event setup tool.
Bijgewerkt op: 19/08/2024
Dankuwel!