De pixel in de browser ziet nog maar een deel van uw conversies. Adblockers, geweigerde toestemming, browserrestricties op cookies van derden: het verlies is structureel en het verergert. De Conversions API bestaat om het te compenseren, op voorwaarde dat u ze correct opzet.
De twee kanalen
De browserpixel draait bij de bezoeker. Hij vangt de volledige context: advertentie-identifiers, cookies, navigatiegedrag. Hij wordt geblokkeerd zodra een blocker, een extensie of een geweigerde toestemming tussenkomt.
De Conversions API stuurt het event vanaf uw server naar het platform, zonder via de browser te gaan. Ze wordt niet geblokkeerd, maar ze beschikt alleen over wat u haar doorgeeft, en ze is blind voor het navigatietraject.
Beide zijn geen alternatieven. De aanbevolen configuratie laat ze samenwerken op dezelfde events, met een ontdubbelingsmechanisme.
De ontdubbeling
Het centrale technische punt, en degene die implementaties het vaakst missen.
Wordt een aankoop verstuurd door de pixel en door de API zonder koppelingsmechanisme, dan telt het platform twee conversies. Uw rapporten tonen een verdubbeling van het volume, uw acquisitiekost lijkt gehalveerd, en uw advertentiebeslissingen steunen op foute cijfers.
De koppeling steunt op twee waarden, die in beide verzendingen strikt identiek moeten zijn: de naam van het event, en een unieke identifier gegenereerd voor deze occurrence.
Drie praktische regels. De identifier moet server-side worden gegenereerd en daarna aan de pixel doorgegeven, niet omgekeerd. Hij moet stabiel zijn bij het herladen van de pagina, wat een willekeurige trekking bij elke weergave uitsluit: de bestelreferentie is de beste kandidaat voor de aankoop. En hij moet uniek zijn per occurrence, niet per product of per sessie.
Facebook Dynamic Ads + Pixel PRO: Productfeeds, Pixel & Conversions API (PrestaShop 8 & 9)Verkoop uw producten op Facebook en Instagram, en meet elke conversie€89,00
Wat de API verwacht
In tegenstelling tot de pixel die veel raadt, kent de API alleen wat u verstuurt. Drie families van informatie.
De klantmatchinggegevens. E-mail, telefoon, voornaam, naam, stad, postcode, land. Ze dienen om de conversie aan een gebruiker van het platform te koppelen. Ze moeten worden genormaliseerd en daarna gehasht voor verzending, nooit in klare tekst doorgegeven.
De eventgegevens. Naam, tijdstempel, waarde, valuta, inhoud van de bestelling met de productidentifiers.
De contextgegevens. IP-adres en user agent van de bezoeker, plus de advertentieklik-identifiers als ze aanwezig zijn in de landings-URL. Die twee laatste verbeteren de matching duidelijk en worden vaak vergeten.
De matchingkwaliteit
Het platform berekent een score die meet in hoeverre het uw events aan gebruikers kan koppelen. Die score bepaalt rechtstreeks de prestaties van uw campagnes, en hij is veel bepalender dan het volume verstuurde events.
Drie hefbomen om hem te verbeteren. Meer matchingparameters versturen: elk extra veld verhoogt de koppelingskans. Correct normaliseren voor het hashen: kleine letters, spaties verwijderen, internationaal formaat voor de telefoonnummers. En de klik-identifiers doorgeven, de meest betrouwbare signalen.
Een lage score ziet u niet in uw conversierapporten, u ziet hem in de prestaties van uw campagnes. Dat maakt hem moeilijk te diagnosticeren.
De toestemming
Een serieus te behandelen punt, want de serververzending ontslaat u van niets.
Dat het event van uw server vertrekt in plaats van uit de browser, verandert niets aan de juridische aard ervan. Heeft de bezoeker de advertentietrackers geweigerd, dan mag u zijn gegevens niet doorgeven aan een advertentieplatform, wat het technische kanaal ook is.
De Conversions API compenseert het verlies door blockers en de technische beperkingen van de browsers, niet dat door de geweigerde toestemming. Het omgekeerde beweren is een foute lezing die veel circuleert.
Concreet moet uw serverimplementatie de toestemmingsstatus van de bezoeker kennen en de verzending conditioneren.
De te dekken events
Vijf volstaan om e-commercecampagnes te sturen: contentweergave, toevoeging aan de winkelwagen, start van de betaling, aankoop, en inschrijving als u die gebruikt.
De aankoop is het enige event dat verplicht via beide kanalen met ontdubbeling moet lopen. De andere kunnen zich in eerste instantie met de pixel behelpen, de serverdekking komt daarna.
Een consistentiepunt om te bewaken: de productidentifiers in de events moeten exact overeenkomen met die van uw productfeed. Een afwijking verhindert de werking van de dynamische campagnes, die op die koppeling steunen.
Controleren
Drie controles, in deze volgorde.
De testtool van het platform, die de ontvangen events in realtime toont met hun bron. Plaats een volledige bestelling en controleer dat de aankoop één keer verschijnt, met de vermelding dat een ontdubbeling heeft plaatsgevonden.
De matchingkwaliteitsscore, na enkele dagen activiteit af te lezen en te vergelijken met de ijkpunten van het platform.
De afstemming met uw backoffice, over een week. Een afwijking van 10 tot 20% minder blijft normaal. Een positieve afwijking, waarbij het platform meer aankopen telt dan u er heeft geregistreerd, signaleert een mislukte ontdubbeling.
De Facebook Dynamic Ads en Pixel PRO module voor PrestaShop zet deze dubbele dekking op op PrestaShop 8 en 9: browserpixel en Conversions API met ontdubbeling per event-identifier, hashing van de matchinggegevens, verwerking van de toestemming en generatie van de productfeed voor de dynamische campagnes.