A Meta Conversions API (röviden CAPI) és a böngészős pixel együtt pontosabb mérést adhat, mint bármelyik egyedül. A párosnak van egy kellemetlen mellékhatása is. Ha mindkét csatorna elküldi ugyanazt a vásárlást, és a Meta nem tudja összekötni a két jelet, akkor egy rendelésből két konverzió lesz a riportban. Ez a cikk azt mutatja meg, miért történik ez, hogyan előzi meg az event_id, és hogyan veszed észre a hibát, mielőtt rossz számok alapján döntenél a hirdetési keretről.
A szövegben három jelölést használok. A Hivatalosan igazolt állítás a Meta fejlesztői dokumentációjában vagy súgójában szerepel. A Saját tapasztalat ügynökségi munkában, több fiókon visszatérően látott mintát jelent. A Szakmai feltételezés logikus következtetés, amelyre nincs hivatalos megerősítés.
Miért számol duplán a Meta, ha a pixel és a Conversions API ugyanazt az eseményt küldi?
Azért, mert a két jel két külön úton érkezik, és közös azonosító nélkül a Meta nem tudja megállapítani, hogy ugyanarról a műveletről van szó. A pixel a látogató böngészőjéből küld adatot, a Conversions API a szerveredről. Mindkettő azt mondja, hogy történt egy vásárlás, a rendszer pedig mindkettőt elkönyveli.
Hivatalosan igazolt: a Meta kifejezetten azt javasolja, hogy a pixel és a Conversions API párhuzamosan fusson. A böngészős jelet reklámblokkoló, sütikorlátozás vagy megszakadt oldalbetöltés is elnyelheti, a szerveroldali jel ezeket a veszteségeket pótolhatja. A párhuzamos küldés feltétele a deduplikáció, vagyis az ismétlődő események kiszűrése.
Vegyünk egy példát. A vásárló fizet, megérkezik a köszönőoldalra, ott a pixel elküld egy Purchase eseményt. Ugyanebben a pillanatban a webáruház szervere is elküldi a rendelést a Conversions API-n. Ha a két üzenetben nincs közös azonosító, a Hirdetéskezelőben két vásárlás és dupla bevétel jelenik meg, a megtérülési mutató pedig kétszer olyan szépnek látszik, mint amilyen valójában.
Hogyan működik a deduplikáció event_id és eseménynév alapján?
A Meta akkor tekint két eseményt azonosnak, ha az eseménynév és az esemény-azonosító mindkettőben ugyanaz, és ugyanahhoz a pixelhez érkeznek. A böngészős oldalon ezt a paramétert eventID néven adod át, a szerveroldali üzenetben event_id a neve.
Hivatalosan igazolt: ha a rendszer 48 órán belül ugyanazt az eseménynév és azonosító párost látja böngészőből és szerverről is, az elsőt megtartja, a később érkezőt eldobja. A Meta leír egy másodlagos módszert is, amely az fbp sütire vagy az external_id értékre épül. Ez csak akkor működik, ha a böngészős esemény érkezik előbb, ezért önmagában kevésbé megbízható.
A böngészős hívás így néz ki egy vásárlásnál.
fbq('track', 'Purchase', {value: 18990, currency: 'HUF'}, {eventID: 'order_48213'});
A szerveroldali üzenetben ugyanennek az értéknek kell szerepelnie.
{"event_name": "Purchase", "event_time": 1760342400, "event_id": "order_48213", "action_source": "website", "event_source_url": "https://pelda.hu/penztar/rendeles-fogadva/", "user_data": {"em": ["sha256-kivonat"], "fbp": "fb.1.1760000000.123456789", "client_user_agent": "..."}, "custom_data": {"value": 18990, "currency": "HUF"}}
Négy részleten szokott elcsúszni a dolog.
- Az eseménynév betűre egyezzen. A
Purchaseés apurchasekét külön esemény, egyéni eseménynél ugyanez igaz. - Az azonosító eseményenként egyedi legyen. Vásárlásnál a rendelésszámra épülő érték jól működik, mert ugyanarra a rendelésre mindig ugyanazt adja. Oldalmegtekintésnél vagy kosárba tételnél véletlenszerű, kérésenként generált azonosító kell.
- Ugyanarra az eseményre ugyanaz az érték menjen mindkét csatornán. Ha a böngészős kód és a szerver külön generál véletlen számot, a két jel soha nem talál egymásra.
- Mindkét jel ugyanahhoz a pixelhez (adatkészlethez) érkezzen. Két külön pixel között nincs összevonás.
Szakmai feltételezés: a dokumentáció a böngészős és a szerveroldali jel párosítását írja le részletesen. Arra, hogy két azonos csatornáról érkező ismétlést (például két szerveroldali küldést) a rendszer minden esetben kiszűr, én nem építenék. Az ismétlést jobb a saját oldaladon megelőzni.
Hol nézhető meg az Eseménykezelőben a deduplikáció állapota és az esemény-egyezési minőség?
Három helyen érdemes megnézni. Az adatkészlet Áttekintés fülén az esemény sorát kibontva, az Események tesztelése nézetben, valamint a Diagnosztika fülön. A felület feliratai időnként változnak, a logika viszont évek óta ugyanaz.
- Áttekintés fül. Az eseménylistában minden sor mellett látszik, milyen integrációból jön az adat. Ha a vásárlásnál böngésző és szerver is szerepel, a párhuzamos küldés él. A sort kibontva megjelenik a böngészős és a szerveroldali események száma, valamint a deduplikációra vonatkozó részletek, köztük az, hogy az események mekkora hányadában érkezik azonosító.
- Események tesztelése. Itt valós időben látod a saját próbaműveleteidet. Ha a pixel és a szerver ugyanazzal az azonosítóval küld, a később érkező sor deduplikált jelölést kap. Ha két külön, feldolgozott sor marad, az azonosítók nem egyeznek.
- Diagnosztika fül. A Meta itt jelzi, ha a szerveroldali eseményekből hiányzik a deduplikációs paraméter, vagy ha az azonosító nem elég egyedi. Ezeket a figyelmeztetéseket érdemes komolyan venni, bár késéssel jelennek meg.
Hivatalosan igazolt: az esemény-egyezési minőség (Event Match Quality) egy tízes skálán mért pontszám, amely azt mutatja, mennyire tudja a Meta a szerveroldali eseményt egy fiókhoz kötni az elküldött ügyféladatok alapján. Ilyen adat a kivonatolt e-mail-cím és telefonszám, az fbp és az fbc érték, az IP-cím és a böngészőazonosító.
A két mutatót sokan összemossák. Az esemény-egyezési minőség arról szól, hogy az esemény mögött felismerhető-e a felhasználó. A deduplikáció arról, hogy ugyanazt az eseményt egyszer számolja-e a rendszer. Egy magas pontszámú fiókban is lehet minden vásárlás dupla.
Saját tapasztalat: a vásárlási eseménynél a pontszám általában magasabb, mint az oldalmegtekintésnél, mert a pénztárban már megvan a vevő e-mail-címe és telefonszáma. Az alacsony pontszámú oldalmegtekintés ezért önmagában nem hiba.
Milyen jelekből derül ki gyorsan a dupla számolás a riportban?
A leggyorsabb jel az, ha a Hirdetéskezelőben látott vásárlásszám a webáruház saját rendelésszámának körülbelül a kétszerese, miközben a kattintások száma és ára nem változott. Ez a rész saját tapasztalat, a Meta nem ad hivatalos listát ezekről a tünetekről.
- Lépcsős ugrás a bekapcsolás napján. A vásárlások száma attól a naptól nő meg hirtelen, amikor a szerveroldali küldést bekapcsoltad vagy bővítményt frissítettél. A valódi javulás ritkán jön egyetlen nap alatt.
- Feleződő eredményenkénti költség változatlan forgalom mellett. Ha az átkattintási arány, a kattintásonkénti költség és a landoló oldal megtekintéseinek száma ugyanaz, a vásárlás költsége viszont a felére esett, gyanakodj.
- Pontosan dupla konverziós érték. A bevétel és a darabszám ugyanolyan arányban nő, az átlagos kosárérték változatlan marad.
- Felborult tölcsér. Több vásárlás látszik, mint megkezdett fizetés, vagy a kosárba tételhez képest valószínűtlenül magas a vásárlási arány.
- Közel azonos böngészős és szerveroldali darabszám, miközben az összesített szám a kettő összege. Működő deduplikációnál az összesített érték a nagyobbik számhoz áll közel.
- Több konverzió, mint amennyit a webáruház összesen fogadott. A hirdetésnek tulajdonított vásárlás nem lehet több a teljes rendelésszámnál.
Az összevetésnél legyél óvatos. A Meta attribúciós ablaka, a megtekintés utáni konverziók és a visszamondott rendelések miatt a két rendszer száma hibátlan beállításnál sem egyezik pontosan. Kisebb eltérés természetes, a kétszeres szorzó viszont szinte mindig mérési hibára utal.
Szakmai feltételezés: a dupla jel a kampányok optimalizálását is torzíthatja, mert az algoritmus felfújt eredményekből tanul. Ennek mértékét kívülről nem lehet megmérni, ezért óvatosan kezelem ezt az állítást.
Mit ellenőrizz WordPress- és WooCommerce-oldalon, ha bővítmény küldi a szerveroldali eseményt?
Először azt nézd meg, hány helyről megy ki pixelkód és szerveroldali esemény. A WooCommerce-oldalak dupla számolásának leggyakoribb oka az, hogy két integráció dolgozik egymás mellett. Az alábbi lista a tipikus hibapontokat veszi sorra.
- Egyetlen integráció legyen. Nézd át a bővítménylistát, a sablon fejléc-mezőit, a címkekezelőt és a süti-hozzájárulás bővítmény beállításait. Ha a hivatalos Meta bővítmény mellett egy másik pixelbővítmény vagy egy kézzel beillesztett kód is fut, a böngészős esemény kétszer megy ki.
- A bővítmény maga adja az azonosítót mindkét csatornának. A hivatalos Facebook for WooCommerce és az ismertebb pixelbővítmények a böngészős és a szerveroldali eseményt ugyanazzal az értékkel küldik. Ez csak akkor működik, ha mindkét küldést ugyanaz a bővítmény végzi.
- A gyorsítótár ne tárolja el az azonosítót. Ha az oldal-gyorsítótár a kész HTML-lel együtt elmenti az
eventIDértékét, minden látogató ugyanazt kapja. Ilyenkor a Diagnosztika jelezheti, hogy az azonosító nem egyedi. A kosár, a pénztár és a köszönőoldal maradjon ki a gyorsítótárból, a többi oldalon pedig böngészőben generált azonosító a biztosabb megoldás. - A köszönőoldal újratöltése ne küldjön új vásárlást. Rendelésszámra épülő azonosítónál az ismételt betöltés ugyanazt az értéket adja, így jó eséllyel kiszűrődik. Véletlen azonosítónál minden frissítés új eseménynek látszik.
- Tisztázd, mikor megy a szerveroldali vásárlás. Egyes bővítmények a köszönőoldal betöltésekor küldenek, mások a rendelés állapotváltásakor. Külső fizetési oldalnál a vevő nem mindig tér vissza a webáruházba. Ilyenkor csak a szerveroldali jel érkezik meg, ami lefedettségi kérdés, és nem okoz duplikációt.
- Címkekezelős szerveroldali küldésnél az azonosító menjen át az adatrétegen. Ha a böngészős címke és a szerveroldali konténer külön változóból dolgozik, könnyen két különböző érték születik.
- A hozzájárulás-kezelés mindkét csatornára vonatkozzon. Ha a sütisáv a pixelt blokkolja, a szerveroldali küldés pedig ettől függetlenül megy, az adatvédelmi kérdés. Ezt jogi oldalról is érdemes átnézetni.
- Frissítés után ellenőrizz újra. Bővítmény-, sablon- és gyorsítótár-frissítés után a beállítás csendben megváltozhat, miközben az oldal látszólag hibátlanul működik.
Hivatalosan igazolt: a Meta azt javasolja, hogy a szerveroldali események nagyjából a böngészős események legalább háromnegyedét lefedjék. Ha a lefedettség ennél jóval alacsonyabb, a szerveroldali küldés hiányos, és a deduplikáció vizsgálata előtt ezt érdemes rendbe tenni.
Hogyan ellenőrizd lépésről lépésre egy próbarendeléssel?
Egy próbarendelés az Események tesztelése nézetben néhány perc alatt megmutatja, hogy a két jel összeér-e. A menete a következő.
- Nyisd meg az Eseménykezelőben az adatkészletet, majd az Események tesztelése nézetet.
- A böngészős teszthez add meg az oldalad címét, és nyisd meg a felkínált hivatkozáson. A szerveroldali teszthez másold ki a tesztkódot, és írd be a bővítmény megfelelő mezőjébe.
- Kapcsold ki a reklámblokkolót, fogadd el a sütiket, és menj végig a vásárláson egy tesztfizetési móddal.
- Nézd meg a megjelenő sorokat. Minden lépésnél (oldalmegtekintés, kosárba tétel, fizetés megkezdése, vásárlás) egy böngészős és egy szerveroldali sort kell látnod, amelyek közül az egyik deduplikált jelölést kap.
- A sorokat kibontva hasonlítsd össze az eseménynevet és az azonosítót. Betűre egyezniük kell.
- Töltsd újra a köszönőoldalt, és figyeld meg, keletkezik-e új, feldolgozott vásárlás.
- A teszt végén töröld a tesztkódot a bővítményből. Ha bent marad, az éles események is tesztként érkezhetnek.
Saját tapasztalat: a próbát érdemes egy második böngészőben, reklámblokkolóval is megismételni. Ilyenkor csak a szerveroldali sor jelenik meg, és ebből látod, hogy a szerveroldali küldés önállóan is működik.
Mit ne várj a deduplikációtól?
A deduplikáció az ismétlést szűri ki, a mérés többi hibáját nem javítja meg. Egy rosszul küldött értéket, egy hiányzó pénznemet vagy egy rossz pillanatban elsülő eseményt ugyanúgy továbbvisz. A Hirdetéskezelő és a webáruház számai közti különbséget sem tünteti el, mert az attribúció és a visszamondott rendelések továbbra is eltérést okoznak.
A helyes beállítás segítheti a kampányok tisztább értékelését, jobb hirdetési eredményt viszont nem garantál. Annyit ad, hogy a döntéseidet valós rendelésszámhoz közelebb álló adatokra alapozhatod. Egy korábbi dupla számolású időszak adatait utólag nem lehet kijavítani, ezért a javítás napját jegyezd fel, és az előtte lévő heteket ne hasonlítsd össze egy az egyben az utána következőkkel.
Források és további olvasnivalók
- Meta for Developers, Conversions API dokumentáció (Deduplicate Pixel and Server Events)
- Meta for Developers, Conversions API paraméterleírás (Server Event Parameters, Customer Information Parameters)
- Meta for Developers, Meta Pixel referencia
- Meta Business Súgóközpont, az esemény-egyezési minőségről és az Eseménykezelő diagnosztikájáról szóló cikkek
- Meta Business Súgóközpont, az Események tesztelése eszköz leírása
- WooCommerce dokumentáció, Facebook for WooCommerce bővítmény
- A Meta akkor von össze egy böngészős és egy szerveroldali eseményt, ha az eseménynév és az event_id betűre egyezik, és a két jel 48 órán belül érkezik ugyanahhoz a pixelhez.
- A dupla számolás leggyorsabb jele, hogy a Hirdetéskezelő vásárlásszáma a webáruház rendelésszámának nagyjából a kétszerese, miközben a kattintási mutatók nem változtak.
- Az esemény-egyezési minőség és a deduplikáció két külön dolog, egy magas pontszám mellett is lehet dupla a számolás.
- WooCommerce alatt a leggyakoribb hibaforrás a párhuzamosan futó két integráció, a gyorsítótárba ragadt event_id és a köszönőoldal újratöltése.
- Egy próbarendelés az Események tesztelése nézetben jó eséllyel megmutatja, hogy a böngészős és a szerveroldali jel összeér-e.
Gyakori kérdések
Mi az az event_id a Meta mérésében?
Egy eseményenként egyedi azonosító, amelyet a böngészős pixel (eventID néven) és a Conversions API (event_id néven) is elküld. Ha az eseménynév és ez az érték mindkét csatornán egyezik, a Meta a két jelet egy eseményként kezeli.
Mennyi időn belül kell megérkeznie a két eseménynek, hogy a Meta összevonja őket?
A Meta dokumentációja szerint 48 órán belül. Az ennél később érkező, azonos azonosítójú eseményt a rendszer már külön eseménynek tekintheti.
Jó ötlet a rendelésszámot használni event_id-ként?
Vásárlási eseménynél jól működik, mert a köszönőoldal újratöltésekor is ugyanaz az érték megy ki. Oldalmegtekintésnél és kosárba tételnél nincs rendelésszám, ott kérésenként generált egyedi azonosító kell.
Ha magas az esemény-egyezési minőség, akkor a deduplikáció is rendben van?
Nem feltétlenül. Az esemény-egyezési minőség azt méri, mennyire köthető az esemény egy felhasználóhoz, a deduplikáció pedig azt, hogy ugyanaz az esemény egyszer számít-e. A kettőt külön kell ellenőrizni.
Elég csak a Conversions API-t használni pixel nélkül, hogy ne legyen dupla számolás?
Technikailag megoldás, a Meta viszont a párhuzamos használatot javasolja, mert a két csatorna kiegészíti egymást. Helyesen beállított event_id mellett a párhuzamos küldés nem okoz dupla számolást.
Javítás után helyreállnak a korábbi, duplán számolt adatok?
Nem, a múltbeli adatok úgy maradnak. Érdemes feljegyezni a javítás napját, és az előtte lévő időszak vásárlásszámait fenntartással kezelni az összehasonlításoknál.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.