Meta Conversions API forklart enkelt: prinsipper, valg av løsning og verifisering

En bestilling er lagt inn i nettbutikken, men Meta kan ikke se den. Andre ganger ser Meta den to ganger. Teamet optimaliserer deretter kampanjene ved hjelp av tall de ikke stoler på, og den første ideen er: La oss implementere CAPI, så løser det alt.

Conversions API kan gjøre målingen mer nøyaktig fordi den sender enkelte markedsføringshendelser fra serveren, CRM-systemet eller plattformen direkte til Metas systemer. Men det kan ikke gjenskape data virksomheten aldri oppretter, og det løser heller ikke dårlig navngitte konverteringer. Først trenger du en måleplan. Deretter kommer dataoverføringen.

CAPI erstatter ikke Pixel eller samtykke

Meta beskriver Conversions API som en mer direkte forbindelse mellom virksomhetens markedsføringsdata og systemene for måling og optimalisering av annonser. For netthendelser anbefaler Meta å vurdere CAPI sammen med Meta Pixel. Nettleser- og serverbaserte baner kan utfylle hverandre.

Det betyr ikke at serveren kan sende alt nettleseren ikke sendte. Meta sier uttrykkelig at CAPI ikke er utviklet for å omgå personvernregler, europeiske bestemmelser eller plattformbegrensninger. Håndter samtykke og lovligheten av behandlingen ut fra de konkrete dataene, regionen og den juridiske vurderingen. En hashet e-postadresse er fortsatt data som stammer fra en person, ikke et røykteppe.

Bestem først hvilke hendelser som har forretningsverdi

For en nettbutikk gir det vanligvis mening å spore veien fra visning av et produkt, via handlekurv og betaling, til kjøp. For et nettsted som genererer leads kan et innsendt skjema eller en kvalifisert lead være viktigere. Jeg ville ikke sendt hvert klikk som en konvertering bare fordi du kan.

For hver hendelse bør du skrive ned:

  • hva som faktisk må skje i den virkelige verden,
  • om det er hovedresultatet for virksomheten eller bare et diagnostisk signal,
  • hvilket system som er sannhetskilden,
  • hvilken unik identifikator du skal bruke,
  • hvilke parametere annonsering og rapportering trenger,
  • under hvilke betingelser du har lov til å sende dataene.

Ved et kjøp er sannhetskilden ofte den bekreftede bestillingen i nettbutikken eller backend-systemet, ikke bare åpningen av takkesiden. For en lead kan skjemaet være det første signalet, men bare CRM-systemet bekrefter kvaliteten på kontakten.

Deduplisering avgjør om dobbeltmåling hjelper

Når du sender den samme hendelsen fra både Pixel og serveren, må Meta gjenkjenne den som én hendelse. Dette krever samme hendelsesnavn og samme event_id på begge banene.

For et kjøp kan en stabil ordre-ID være et egnet grunnlag. For en hendelse uten egen forretnings-ID bør du opprette en unik identifikator når handlingen skjer og sende den til både nettleser- og serverlaget. En tilfeldig identifikator som genereres separat på hver side, hjelper ikke — verdiene vil ikke samsvare.

Deduplisering er ikke en detalj for en utvikler. Hvis den mislykkes, kan kampanjene motta et dobbelt signal, og rapporteringen begynner å lyve.

Fire implementeringsmåter har ulike kostnader

En partner eller funksjon i en netthandelsplattform

For en typisk nettbutikk er dette ofte førstevalget. Plattformen vedlikeholder integrasjonen kontinuerlig, og virksomheten trenger ikke å eie API-kode. Likevel bør du kontrollere hvilke hendelser den sender, om den håndterer deduplisering og samtykke, og om den lar deg inspisere parameterne.

En administrert tjeneste eller gateway

En leverandør overtar deler av infrastrukturen og oppdateringene. Du betaler for drift og avhengighet, men reduserer ditt eget tekniske vedlikehold. Det gir mening hvis tjenesten støtter teknologistakken din, og du har tydelig tilgang til diagnostikk.

Server-side Google Tag Manager

En servercontainer kan samle flere overføringer av markedsføringsdata og gi virksomheten mer kontroll. Samtidig tilfører den hosting, maler, tillatelser og enda et sted som må testes. Jeg ville ikke valgt den bare for å få et pent arkitekturdiagram.

En tilpasset direkteintegrasjon

Den gir størst fleksibilitet og også størst ansvar. Du trenger sikker token-håndtering, validering av inndata, logging uten å lekke sensitive data, gjenoppretting etter feil, håndtering av API-versjoner og noen som vedlikeholder integrasjonen.

Den opprinnelige artikkelen inneholdt et kort PHP-skript og et offentlig tilgjengelig endepunkt. Jeg anbefaler ikke lenger en slik løsning som generell veiledning. Den brukte en gammel API-versjon og bygget på for mange antakelser om sikkerhet og drift. Kode som fungerer i dag etter kopiering, kan stille slutte å registrere hendelser i morgen. For en direkteintegrasjon bør du ta utgangspunkt i Metas gjeldende dokumentasjon og drive normal utvikling, ikke kopiere og lime inn markedsføring.

Kvaliteten på hendelsene betyr mer enn antallet parametere

En serverbasert hendelse trenger vanligvis et navn, tidspunkt, handlingskilde og URL eller annen kontekst, avhengig av kilden. For en forretningshendelse legger du til relevant verdi, valuta, varer og stabil ID. Send brukeridentifikatorer bare når du har rett til å ha dem, de er korrekt normalisert og de har det påkrevde formatet.

Flere identifikatorer kan forbedre samsvaret, men «jo flere, desto bedre» stemmer ikke uten begrensninger. Ikke send tomme, oppdiktede eller utdaterte verdier. Og opprett ikke et fingeravtrykk for å omgå brukerens valg.

Testen må dekke hele kundereisen

  1. Start testmodus i Meta Events Manager.
  2. Gjennomfør et reelt scenario fra innlasting av nettstedet til en bestilling eller lead.
  3. Kontroller nettleser- og serverhendelsene, parameterne deres og samsvarende ID-er.
  4. Kontroller at Meta dedupliserer paret og ikke viser en diagnostikkfeil.
  5. Sammenlign verdi, valuta og ID med backend-systemet eller CRM.
  6. Test både godkjenning og avslag av samtykke i henhold til løsningen din.
  7. Etter lansering bør du overvåke diagnostikk og bortfall over tid, ikke bare én grønn test.

Test Events bekrefter at den tekniske meldingen kom frem. Den bekrefter ikke at du valgte riktig konvertering, eller at integrasjonen er juridisk i orden.

CAPI og GA4 er to forskjellige lag

CAPI sender hendelser til Meta for måling og optimalisering av annonser. GA4 analyserer nettstedet og appen på tvers av kilder. Tallene kan avvike på grunn av attribusjon, samtykke, identitet og behandling. Jeg prøver ikke å tvinge dem til å samsvare absolutt; først kontrollerer jeg at hvert system mottar teknisk korrekte data, og at vi bruker dem til riktig beslutning.

Hvis du trenger en samlet oversikt over kostnader og resultater fra nettstedet, kan du også lese hvordan du kobler Meta Ads til GA4. Guiden til Google Tag Manager dekker selve implementeringen av tagger, og guiden til GA4 forklarer betydningen av hendelser.

Når jeg ikke ville implementert CAPI ennå

Hvis virksomheten ikke har definert konverteringene sine, ikke vet hvilken bestilling som er gyldig eller ikke klarer å vedlikeholde den eksisterende Pixel-implementeringen, vil en serverbasert bane øke kaoset. Fiks først kildedataene og måleplanen. CAPI gir mening når du vet hvilket signal du vil levere, hvorfor Meta trenger det og hvem som skal eie integrasjonen.

Hvis du vil velge den minste fornuftige løsningen for nettbutikken eller leadsgenereringsnettstedet ditt, kan du sende meg plattformen, det nåværende måleoppsettet og hendelsen som betyr mest for virksomheten din via kontaktsiden.

Trenger du klarhet i markedsføringen?

La oss først gjøre situasjonen tydelig.

Hvis bedriften din står overfor en lignende beslutning, kan du sende meg litt kontekst. Så ser vi om det gir mening å fortsette.

Beskriv situasjonen