Kell a Meta pixel és a Conversions API is?

A Meta mindkettőt ajánlja. A pixel böngészőadatokat ad hozzá, például az fbp sütit, a Conversions API pedig azokat az eseményeket kézbesíti, amelyeket a böngésző elszalaszt. Add mindkét példánynak ugyanazt az eseménynevet és eseményazonosítót, hogy a Meta minden eseményt egyszer számoljon.

Meddig vár a Meta, hogy deduplikáljon egy böngészős és egy szerveroldali eseményt?

A Meta akkor deduplikál egy azonos eseménynevű és eseményazonosítójú böngészős és szerveroldali eseményt, ha azok 48 órán belül megérkeznek egymáshoz képest. A később érkező példány ismét beleszámít.

Kell a Conversions API-hoz az ügyféladatok hashelése?

Igen, az elérhetőségi adatoknál. Az e-mail, a telefonszám, a név és a cím mezőit normalizálni és SHA-256-tal hashelni kell. Az IP-címet, a user agentet, az fbp-t és az fbc-t hashelés nélkül kell küldeni.

Mely mezők kötelezők egy webes eseménynél?

Minden eseményhez kell event_name, event_time, action_source és legalább egy ügyféladat-paraméter. Webes eseményeknél a Meta az event_source_url és a client_user_agent megadását is megköveteli.

Küldhetek régi rendeléseket a Conversions API-n keresztül?

Csak a frissebbeket. Az event_time legfeljebb 7 napra lehet a múltban, és ha egy kérésben akár egyetlen esemény is régebbi, a Meta az egész kérést elutasítja.

Meta Conversions API (CAPI): gyakorlati útmutató

A legfontosabb tudnivalók

A Meta Conversions API az olyan eseményeket, mint a Purchase, a szerveredről küldi, így azok akkor is eljutnak a Metához, ha a böngészőpixelt blokkolják.
Futtasd a pixel mellett, és add mindkét példánynak ugyanazt az eseménynevet és event_id-t; a Meta ilyenkor egyszer számolja az eseményt, ha mindkettő 48 órán belül megérkezik.
A webes eseményekhez szükség van az action_source, az event_source_url és a vásárló user agentjének megadására; a hashelt e-mail és telefonszám, az IP-cím, az fbp és az fbc dönti el, mennyire tudja a Meta párosítani őket.
Teszteld az Events Manager Test events fülén, aztán töröld a tesztkódot, mert a tesztesemények nem kerülnek eldobásra.
A legtöbb probléma az eltérő eseményazonosítókból, a szerver saját IP-címéből, egy elveszett fbclid-ből vagy normalizálás nélkül hashelt elérhetőségi adatokból ered.

A Meta Conversions API (CAPI) lehetővé teszi, hogy a szervered közvetlenül a Metának küldjön eseményeket, például Purchase-t. A Meta pixel ugyanezeket az eseményeket a vásárló böngészőjéből küldi. A CAPI a szervered felől küldi őket, így akkor is megérkeznek, ha egy reklámblokkoló megállítja a pixelt, egy süti elveszett, vagy a köszönőoldal soha nem töltődik be.

Ez az útmutató azt tárgyalja, mit tartalmaz egy Conversions API esemény, hogyan futtathatod a pixel mellett egyetlen event_id segítségével, mely paramétereket követeli meg és ajánlja a Meta, hogyan tesztelhetsz a Test events segítségével, és melyek a leggyakrabban előforduló hibák.

Mi a Meta Conversions API?

A Conversions API a Meta Graph API része. A szervered egy HTTPS POST kérést küld a graph.facebook.com/VERSION/PIXEL_ID/events címre egy hozzáférési tokennel és egy data listával, amely legfeljebb 1,000 eseményt tartalmaz. Minden esemény egy műveletet ír le, például egy vásárlást, három részben: mi történt, ki tette, és a részletek.

Mező	Mit tartalmaz
`event_name`	A művelet, például `Purchase`, `AddToCart` vagy `InitiateCheckout`
`event_time`	Mikor történt, Unix időbélyegként, másodpercben
`event_id`	Az esemény egyedi azonosítója, amellyel a pixellel szemben deduplikálható
`action_source`	Hol történt: `website` a webáruházi vásárlásoknál
`event_source_url`	Az oldal URL-je, ahol az esemény történt
`user_data`	A párosításhoz használt ügyféladatok: hashelt e-mail és telefonszám, IP-cím, user agent, fbp és fbc
`custom_data`	Részletek, például `value`, `currency` és `content_ids`

Minden Conversions API esemény ugyanolyan szerkezetű: a művelet, az ügyféladatok és a részletek.

Egy lerövidített Purchase esemény így néz ki:

Conversions API: egy Purchase esemény (lerövidítve)

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1792929600,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkouts/thank-you",
    "user_data": {
      "em": ["<SHA-256 of the normalized email>"],
      "ph": ["<SHA-256 of the normalized phone>"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; ...)",
      "fbp": "fb.1.1792928400000.1234567890",
      "fbc": "fb.1.1792928400000.AbCdEf123"
    },
    "custom_data": { "value": 74.00, "currency": "USD" }
  }]
}

Az elérhetőségi mezők, például az e-mail és a telefonszám, normalizálva és SHA-256-tal hashelve hagyják el a szerveredet. Az IP-cím, a user agent, az fbp és az fbc változatlanul kerül elküldésre.

Miért érdemes a Conversions API-t a pixel mellett futtatni?

A Meta azt javasolja, hogy a Conversions API-t a pixel mellett futtasd, és mindkettőn ugyanazokat az eseményeket küldd. Mindkét oldal olyasmit lát, amit a másik nem, és együtt teljesebb adatot adnak a Metának.

Meta pixel (böngésző)

Beállítja az _fbp sütit, és egy hirdetési kattintás fbclid-jét az _fbc sütiben tárolja
Látja az oldalt és a böngészőt a látogatás közben
Elveszik, ha a böngésző blokkolja, vagy az oldal nem töltődik be

Conversions API (szerver)

A kifizetett rendelést a webáruházad adataiból küldi
Hozzáadhat hashelt e-mailt, telefonszámot és címet a rendelésből
Nem függ a böngészőtől, ezért a reklámblokkolók nem állítják meg

A pixel hozza a böngészőazonosítókat, a szerver pedig a rendelést. Külön-külön mindkettő kihagy egy részt a képből.

Mindkettő futtatásának ára, hogy a Meta mostantól minden eseményből két példányt kap. A következő rész megmutatja, hogyan tart meg a Meta csak egyet.

Hogyan működik a deduplikáció egyetlen event_id-val?

A Meta egy böngészős és egy szerveroldali eseményt akkor tekint ugyanannak az eseménynek, ha két dolog egyezik: az eseménynév és az eseményazonosító. A pixelben az azonosító az eventID opcióba kerül. A Conversions API-ban ugyanez az érték az event_id mezőbe.

Meta pixel: ugyanaz a Purchase eventID-val

fbq('track', 'Purchase', { value: 74.00, currency: 'USD' }, { eventID: 'order-1042' });

A vásárló fizet1042. rendelés, $74.00

A pixel elküldi a Purchase-teventID order-1042, a böngészőből

A szerver elküldi a Purchase-tevent_id order-1042, a rendelésből

A Meta egyet számolAzonos név és azonosító 48 órán belül

Mindkét példány ugyanazt az eseménynevet és azonosítót hordozza, ezért a Meta két vásárlás helyett egyet tart meg.

A Meta csak akkor deduplikál egy egyező párt, ha a két példány 48 órán belül megérkezik egymáshoz képest. Néhány szabály segít, hogy ez a gyakorlatban működjön:

Az azonosítót egyszer hozd létre. Olyasmiből építsd fel, amit mindkét oldal ismer, például a rendelésszámból, és add át a böngészőnek és a szervernek is. Két rendszer, amely külön-külön készít saját azonosítót, nem fog egyezni.
Egy formátumot használj. Az order-1042 és az 1042 különböző azonosítók.
Az eseménynevet pontosan egyeztesd. A Purchase és a purchase különböző események.
A szerveroldali eseményt időben küldd el. Az a szerveroldali esemény, amely több mint 48 órával a böngészős esemény után érkezik meg, másodszor is beleszámít.

A Meta egy második módszert is leír, amely az eseményeket az fbp vagy az external_id alapján párosítja. A Meta szerint ez általában csak akkor működik, ha a böngészős esemény a szerveroldali előtt érkezik meg, ezért a közös event_id a megbízhatóbb választás. Ha a Meta ennek ellenére több vásárlást jelent, mint ahány rendelése volt a webáruházadnak, a duplikált vásárlási eseményekről szóló útmutatónk felsorolja a szokásos okokat.

Mely paraméterek kötelezők, és melyek ajánlottak?

A kötelező mezők teszik érvényessé az eseményt. Az ajánlott mezők döntik el, hogy az eseményeid közül hányat tud a Meta egy személyhez párosítani, és csak a párosított események használhatók attribúcióhoz és hirdetéskiszolgáláshoz.

Paraméter	Webes események	Mit küldj
`event_name`	Kötelező	Egy standard esemény, például a Purchase, vagy egy egyéni eseménynév
`event_time`	Kötelező	Unix-idő másodpercben, legfeljebb 7 napra visszamenőleg
`action_source`	Kötelező	`website` a webáruházad eseményeihez
`event_source_url`	Kötelező	Az oldal URL-je, ahol az esemény történt
`client_user_agent`	Kötelező	A vásárló böngészőjének user agent karakterlánca, nem a szerveredé
`user_data`	Kötelező	Legalább egy ügyféladat-paraméter
`event_id`	Ajánlott	Ugyanaz az azonosító, amelyet a pixel használ, a deduplikációhoz
`em`, `ph`	Ajánlott	E-mail és telefonszám, normalizálva és SHA-256-tal hashelve
`client_ip_address`	Ajánlott	A vásárló IP-címe, hashelés nélkül
`fbp`, `fbc`	Ajánlott	A böngészőazonosító és a kattintásazonosító sütik, hashelés nélkül
`external_id`	Ajánlott	A saját vásárlóazonosítód, a böngészős és a szerveroldali eseményeken azonos
`value`, `currency`	Purchase mellett küldd	A rendelés értéke és egy hárombetűs pénznemkód

A Meta az action_source, az event_source_url és a client_user_agent mezőt kötelezőként sorolja fel a Conversions API-n keresztül küldött webes eseményeknél.

Három részlet okozza a problémák nagy részét:

Hashelés előtt normalizálj. A Meta az e-mailt levágott szóközökkel és kisbetűsen várja, a telefonszámokat pedig számjegyekként, az országkóddal. Az Anna@Example.com és az anna@example.com különböző hasheket ad, és csak a második párosítható.
Ne hasheld a böngészőazonosítókat. Az fbp, az fbc, az IP-cím és a user agent sima értékként kerül be.
A kattintásazonosítót pontosan úgy tartsd meg, ahogy van. Az fbc értéke fb.1., a létrehozás ideje ezredmásodpercben, egy pont, majd a landing oldal URL-jéből származó fbclid. Az fbclid megkülönbözteti a kis- és nagybetűket. Mentsd el, amikor a látogató megérkezik, mert a pénztárnál már nincs az URL-ben.

Azt, hogy ezek a mezők mennyire párosítanak jól, a Meta Event Match Quality pontszáma méri. Az Event Match Quality útmutatónk minden paramétert, a hashelési szabályokat és a célként kitűzendő pontszámot tárgyalja.

Hogyan tesztelheted az eseményeket a Test events segítségével?

Az Events Manager Test events füle az eseményeket érkezésükkor mutatja. Használd, mielőtt egy új beállításra hagyatkoznál.

Nyisd meg a Test events fület
Az Events Managerben válaszd ki az adatkészletedet (pixeledet), és nyisd meg a Test events fület. Másold ki a megjelenő tesztkódot.
Add hozzá a kódot a szerveroldali eseményeidhez
Küldd el a kérésben test_event_code néven. A ROASaurusban illeszd be a Meta pixel Test event code mezőjébe.
Adj le egy tesztrendelést
Látogasd meg a webáruházat, tegyél egy terméket a kosárba, és fizess, hogy a pixel és a szerver is küldjön egy Purchase-t.
Hasonlítsd össze a két példányt
Mindkét példánynak ugyanazt az eseménynevet, eseményazonosítót, értéket és pénznemet kell mutatnia.
Nézd meg az ügyféladatokat
A szerveroldali eseménynek hashelt e-mailt és telefonszámot, az IP-címet, a user agentet és az fbp-t kell hordoznia, valamint fbc-t, ha a látogatás hirdetési kattintással indult.
Távolítsd el a tesztkódot
A Meta szerint a mező csak tesztelésre való, ezért távolítsd el, mielőtt az eseményekre hagyatkozol.

Purchase browser order-1042 74.00 USDA pixelből

Purchase server order-1042 74.00 USDA Conversions API-ból

event_name + event_id matchEgy vásárlásként számolva

em ph fbp fbc client_ip_address client_user_agentÜgyféladatok a szerveroldali eseményen

Mit mutat egy jó tesztrendelés (példaértékek): két példány, egy azonosító és teljes ügyféladat.

Gyakori Conversions API hibák és javításuk

Amit látsz	Valószínű ok	Megoldás
A teljes kérés meghiúsul, és egyetlen eseményt sem dolgoz fel a rendszer	A köteg egyik eseményének event_time értéke több mint 7 napos	Az eseményeket akkor küldd, amikor megtörténnek. Az újrapróbálkozás előtt javítsd vagy dobd el a régi eseményeket.
A Meta több vásárlást jelent, mint amennyi a webáruházadban volt	Eltérő eseményazonosítók, eventID nélküli pixelesemény, vagy egy második alkalmazás, amely ugyanazt a pixelt küldi	Használj egy azonosítót mindkét példányhoz, és pixelenként egy szerveroldali küldőt.
Alacsony párosítási minőség a szerveroldali eseményeknél	A szervered a saját IP-címét és user agentjét küldi	Add tovább a vásárló böngészőjéből vagy rendeléséből rögzített IP-címet és user agentet.
Kevés esemény fbc-vel	Az fbclid-t nem mentették el a landing oldalon, vagy módosították	Pontosan úgy tárold az fbclid-t, ahogy megérkezik, és ebből építsd fel az fbc-t.
Az e-mail és a telefonszám nem párosul	Normalizálás nélkül hashelt, vagy hash nélkül elküldött értékek	Vágd le a szóközöket és kisbetűsítsd az e-mailt, tartsd meg a telefonszám számjegyeit és az országkódot, majd hasheld SHA-256-tal.
A kérések lejárt token hibával meghiúsulnak	A hozzáférési token Facebook-bejelentkezésből származik, a bejelentkezési tokenek pedig lejárnak	Csatlakozz újra, vagy használj System User tokent a Business Managerből, amelyet lejárati dátum nélkül is létrehozhatsz.

A legtöbb Conversions API probléma elutasított kérésként, dupla számolásként vagy alacsony párosítási minőségként jelentkezik.

Néhány nap éles forgalom után nyisd meg az Events Manager Diagnostics fülét. A Meta ott felsorolja a problémákat, és javaslatokat ad a javításukra. Ezután hasonlítsd össze az Events Manager napi Purchase-számát a webáruházad kifizetett rendeléseivel ugyanazokra a napokra. Ha a Meta egyértelműen magasabb, a dupla számolás megelőzéséről szóló súgóoldalunk felsorolja az ellenőrzendő beállításokat.

A Conversions API beállítása a ROASaurusszal

A ROASaurus a Conversions API eseményeket a webáruházad rendelési adataiból küldi, így a szerveroldalt nem neked kell megépítened. A Tracking & platforms oldalon kattints a Connect with Facebook gombra, és válaszd ki a hirdetési fiókodat és a pixeledet, vagy illeszd be a pixel (adatkészlet) azonosítóját és egy Conversions API tokent. A Meta beállítási útmutatója mindkét lehetőséget lépésről lépésre bemutatja, a Meta-integráció oldala pedig felsorol minden elküldött mezőt.

Egy azonosító mindkét oldalon. A böngészős és a szerveroldali esemény ugyanazt az eseményazonosítót használja. Vásárlásnál ez az order-, amelyet a rendelésazonosító követ.
Rövid várakozás a vásárlás előtt. A szerveroldali Purchase röviden vár a rendelés beérkezése után, hogy a böngészős vásárlási esemény előbb csatolható legyen. Ennek az IP-címe, user agentje és oldal-URL-je ezután a szerveroldali eseménnyel együtt megy ki, a látogatóhoz mentett fbp és fbc mellett.
Ügyféladatok a rendelésből. Az e-mail, a telefonszám, a név és a cím normalizálva és SHA-256-tal hashelve kerül bele. A webáruház vásárlóazonosítója és a ROASaurus látogatóazonosítója hashelve, external_id-ként kerül be.
A Meta számára nem párosítható események kimaradnak. Az az esemény, amelyben nincs fbc, fbp, e-mail, telefonszám vagy IP-cím, nem kerül elküldésre.

Az Event log minden szerveroldali kézbesítést megmutat a kéréssel és a Meta válaszával. Ha az árrések nagyon eltérnek a termékek között, a vásárlások mellett profitértéket is küldhetsz: a Meta-értékoptimalizálás profitra útmutatónk elmagyarázza, hogyan. A kattintástól a rendelésig tartó teljes adatútról lásd a szerveroldali követés oldalt.

Források

A ROASaurusban

Olvass tovább

Hirdetési platformok és webáruházakUtánvétes konverziókövetés és külső pénztárakUtánvétes konverziókövetés: miért nem látják a pixelek az utánvétes és a külső pénztárban leadott rendeléseket, mikor kell elküldeni a vásárlást, és hogyan kezeld az átvételkor visszautasított rendeléseket.Hirdetési platformok és webáruházakCCV Shop konverziókövetés: beállítási útmutatóCCV Shop konverziókövetés: küldd el a kifizetett rendeléseket a Metának és a TikToknak aláírt webhookkal, kösd őket a hirdetési kattintásokhoz, állítsd be, teszteld, és kezeld a késői fizetéseket.Hirdetési platformok és webáruházakGoogle Ads enhanced conversions ShopifyonAz enhanced conversions hashelt ügyféladatokat ad a Google Ads vásárlásokhoz Shopifyon. Hogyan működnek, miben különböznek az offline importoktól, és hogyan kell beállítani.