Meta (Facebook) hibák

Az alábbi bejegyzések közül több ugyanoda vezet: a Meta Events Managerben a pixelhez tartozó adatforrás beállításaihoz. Ha inkább egyszer végigmennél az összeshez, ahelyett hogy tünetenként követnéd őket, használd a Meta Events Manager beállításainak listáját a Meta (Facebook) pixel fejezetben.

Server Sending Invalid Match Key Parameters

A Pixel Manager úgy állítja elő és küldi az egyezési kulcs paramétereit, hogy az eltérés ne fordulhasson elő: vagy helyesen küldi és egyezteti őket, vagy egyáltalán nem küldi el.

A figyelmeztetés szokásos magyarázata ezek közül egy vagy több:

• Nemrég kapcsoltad be a Meta (Facebook) CAPI-t. Ilyenkor a Meta néha összekeveri a régi és az új értékeket, és figyelmeztetést ad. Ez az átmeneti állapot néhány nap alatt magától megszűnik. Ilyenkor az ajánlás, hogy egyszerűen utasítsd el a figyelmeztetést. Ha újra megjelenik, nézd meg a többi lehetséges okot. Ha úgy gondolod, hogy egyik sem jön szóba, fordulj a támogatáshoz.
• Egy második Meta-pixel példány fut egy másik bővítményen vagy egyedi kódon keresztül. Ennek a kódnak hiányoznak a helyes egyezési kulcsai, és ez okozza a figyelmeztetést. Kapcsold ki a további Meta (Facebook) bővítményeket és/vagy távolítsd el a további egyedi Meta-kódot. Utána utasítsd el a figyelmeztetést a Metában. Ha újra megjelenik, fordulj a támogatáshoz.
• Bekapcsoltad, hogy a Facebook kód nélkül, automatikusan kövessen eseményeket. Ezt a funkciót ki kell kapcsolnod a Facebook Events Managerben.

Purchase Event delay from server (Conversions API)

Normál körülmények között a bővítmény azonnal elküldi a vásárlási eseményt a Metának. Ha viszont egy rendelés fizetése meghiúsul, a Conversions API-n nem megy ki vásárlási esemény. Csak ha a rendelés fizetése egy későbbi időpontban helyreáll, akkor küldi el a vásárlási eseményt a Metának. Ez a Purchase Event delay from server figyelmeztetést okozhatja. Nyugodtan figyelmen kívül hagyhatod.

Potentially violating Personal data sent to Meta

Ez akkor történik, ha a Meta az URL útvonalában olyan URL-paramétereket észlel, amelyek feltehetően személyes adatot (PII) tartalmaznak.

Példa: http://example.com/account/reset-password?username=johndoe

Ilyenkor a Meta úgy találja, hogy a username valószínűleg személyes adatot tartalmaz, figyelmeztetést ad, és az információt így törli: http://example.com/account/reset-password?username=_removed_

A bővítmény nem ad hozzá semmilyen információt az URL útvonalához. Az egyetlen információ, amit a Pixel Manager a böngészőpixelen át küld, a termék- és rendelésadat. A figyelmeztetés forrása a szerver által generált URL-útvonal, és ott kell javítani.

A Meta bizonyos esetekben „gyorsan elsül”, és akkor is figyelmeztet, ha nincs személyes adat az URL útvonalában. Példa: http://example.com?_ip=123456. Itt az _ip=123456 egy IP-címre hasonlít, de nálad lehet teljesen más is. Ha biztos vagy benne, hogy nem személyes adat, nyugodtan figyelmen kívül hagyhatod a figyelmeztetést.

„Failed to load resource: net::ERR_BLOCKED_BY_CLIENT”

Ezt általában a böngészőben lévő reklámblokkoló okozza. Átmeneti megoldásként kapcsold ki a reklámblokkolót, vagy válts másik böngészőre, amelyben nincs bekapcsolva reklámblokkoló.

A Meta-pixel nem töltődik be, a Google-címke viszont igen

Tünet: mielőtt a látogató elfogadja a sütibannert, vagy miután elutasítja a marketingsütiket, a Google-címke betöltődik és kéréseket küld, de a Meta-pixel teljesen hiányzik: nincs fbevents.js, nincsenek kérések a facebook.com/tr felé, és nincs hiba a konzolban. Mivel a Google működik, a Meta-pixel hibásnak látszik.

Ok: ez akkor fordul elő, ha a bolt hozzájárulást követel a követés előtt, vagy a Consent → Explicit consent → Enable Explicit Consent Mode beállítással, vagy opt-in módban futó sütibannerrel. Ebben a felállásban ez a szándékolt viselkedés. Ha a Consent → Google Consent Mode v2 → Enable Google Consent Mode v2 be van kapcsolva a szabványos beállításokkal, a Pixel Manager minden látogatónak betölti a Google-címkét, és a Google Consent Mode közli a Google-lel, mibe egyezett bele a látogató, így a Google sütik nélküli méréseket is küldhet. A Metának nincs ennek megfelelője, ezért a Pixel Manager egyáltalán nem tölti be a Meta-pixelt, amíg a látogató nem adja meg a marketingkategóriát. A Google Consent Mode nélkül a Google-címke is vár a hozzájárulásra.

Így ellenőrizheted: nyisd meg a boltot privát ablakban, válaszolj a bannerre, majd futtasd az ellenőrzéseket a böngésző fejlesztői eszközeiben.

Ellenőrzés	Marketing megtagadva	Marketing megadva
pmwDataLayer.pmw_loaded a konzolban	true	true
typeof gtag a konzolban	"function"	"function"
typeof fbq a konzolban	"undefined"	"function"
Network fül	nincs fbevents.js, nincs signals/config kérés	az fbevents.js és a signals/config/<pixel_id> 200-as állapottal betöltődik
Konzolhibák	nincs	nincs

Megtagadott állapotban a konzol a Pixel Manager saját sorát is mutatja: „The pixel has not loaded because you have not given consent for it yet”, a category: marketing és a pixel: Facebook megnevezésével. A teljes naplóhoz fűzd az URL-hez a ?pmwloggeron paramétert.

A Pixel Manager saját pixel-facebook szkriptje mindkét állapotban betöltődhet. Csak a Meta fbevents.js fájlja töltődik be hozzájárulás után.

Megoldás: ha a „megtagadva” oszlop egyezik, nincs teendő. Ha a Meta-pixel a marketingsütik elfogadása után sem töltődik be, ellenőrizd, hogy a bannered helyesen képezi-e le a marketingkategóriáját (Hozzájárulás és adatvédelem).

Dupla Purchase esemény a Meta automatikus eseményészlelése miatt

Összefoglaló: ha a Meta Events Managerben dupla Purchase eseményt látsz, és a dupla esemény azonosítója pmw_xq9m1b4a3uqdcc61_26495490706760077 alakú, a duplát a Meta fbevents.js fájlja váltja ki, nem a Pixel Manager. Javítsd a Meta Events Managerben az Automatic events (régebben: Track Events Automatically Without Code) kikapcsolásával.

A Meta egy új pixel létrehozásakor alapból bekapcsolja az automatikus eseményeket: a beállítás előre kijelölt opcióként szerepel, és a Meta mesterségesen intelligens funkciója pótolja azokat az eseményeket, amelyekről úgy gondolja, hogy hiányoznak a weboldalról. Ha a pixelt ez után hoztad létre, és nem szüntetted meg a kijelölést, a beállítás be van kapcsolva.

Ha az automatikus eseményészlelés már ki van kapcsolva az Events Managerben, és még mindig dupla eseményeket látsz, ez a bejegyzés nem érvényes. Ugorj a „Duplák az automatikus észlelés kikapcsolása után is” részre.

Tünet: ugyanarra a rendelésre két Purchase esemény érkezik a Meta Events Managerbe:

• A szabályos, a Pixel Manager által küldött, pmw_<rendelés_azonosító> formátumú eseményazonosítóval, például pmw_145741.
• Egy második, szokatlan eseményazonosítóval, amely egy véletlen karakterláncot és egy hosszú számsort kombinál, például pmw_xq9m1b4a3uqdcc61_26495490706760077. A véletlen középső rész azt a formátumot követi, amelyet a Pixel Manager a nem vásárlási eseményekhez használ (pmw_<16 base36 karakter>), de a számsort a Meta fűzi hozzá.

A második eseményt nem a Pixel Manager küldi. A Meta saját fbevents.js szkriptje váltja ki egy olyan funkció részeként, amelyet a Meta „Track Events Automatically Without Code” néven hív (automatikus eseményészlelés, mikroadat-események vagy következtetett események).

Miért történik: amikor a Meta-pixel betöltődik, konfigurációt kér a Metától a https://connect.facebook.net/signals/config/<pixel_id> címről. Ez a konfiguráció több viselkedést szabályoz, többek között az inferredEvents, microdata, automaticMatching és openbridge (a Meta kezelt CAPI Gateway) beállításokat.

Ha az automatikus eseményészlelés be van kapcsolva a pixelen az Events Managerben, az fbevents.js a PageView után rövidesen átvizsgálja az oldal strukturált adatait (Schema.org JSON-LD, OpenGraph-címkék, mikroadat-attribútumok) és a DOM-ot. Ha egy megerősítő oldalon e-kereskedelmi jelet észlel, elküldi a saját további Purchase eseményét a Metának. Ez az esemény az fbevents.js belsejében épül fel, és sosem halad át a Pixel Manager kódján.

Az pmw_<véletlen>_<szám> eseményazonosító-formátum Meta-belső minta: a Meta pixelkódja az oldalon legutóbb látott eseményazonosítót (jellemzően a Pixel Manager PageView eseményének véletlen formátumú azonosítóját) veszi, és hozzáfűzi a saját belső alesemény-számlálóját vagy hash-ét. Ezért tűnik úgy, hogy a dupla azonosító a Pixel Manager névterét örökli, bár a Pixel Manager nem hozta létre.

Ez a Meta oldaláról tervezett viselkedés. A Pixel Manager a saját kódútvonalából nem tudja megakadályozni, mert a dupla az fbevents.js belsejében keletkezik, miután a Pixel Manager már átadta az irányítást.

Hogyan azonosítod ezt az okot: nyisd meg a megerősítő oldalt (például /checkout/order-received/...) megnyitott Chrome DevTools mellett. A Network fülön szűrj a facebook.com/tr és a facebook.com/privacy_sandbox/pixel/register/trigger kifejezésekre (a Meta a böngészőtől és a Privacy Sandbox beállításaitól függően mindkét végpontot használja). Vizsgáld meg az eid lekérdezési paramétert minden ev=Purchase kérésen:

• eid=pmw_<rendelés_azonosító> (például pmw_145741): szabályos Pixel Manager Purchase.
• eid=pmw_<16 karakter>_<hosszú szám> (például pmw_xq9m1b4a3uqdcc61_26495490706760077): a Meta által automatikusan észlelt dupla.

Ha mindkettő megjelenik, az itt leírt eset érvényes. Ha a dupla eseményazonosító nem pmw_-vel kezdődik, a dupla egy külön pixelintegrációból jön az oldaladon (másik bővítmény, GTM-címke, egyedi témakód stb.). Az más probléma: nézd át a telepített bővítményeket és a megerősítő oldalon betöltött GTM-konténereket.

1. megoldás: az automatikus eseményészlelés kikapcsolása a Meta Events Managerben (ajánlott)

Ez a legtisztább javítás, mert a forrásnál állítja meg a duplát, és minden olyan oldalra érvényes, amely ezt a pixelt használja.

1. Jelentkezz be a Meta Business Managerbe.
2. Nyisd meg az Events Managert.
3. A bal oldali sávban válaszd a Datasets (régebbi elrendezésben: Data Sources) részt, és kattints a megfelelő pixelre.
4. Kattints a Settings fülre.
5. Az Event setup alatt keresd meg az Automatic events beállítást (régebbi elrendezésben: Track Events Automatically Without Code).
6. Kapcsold ki, és mentsd.

Rövid terjedési késleltetés (általában percek) után a Meta már nem küldi az automatikus eseményészlelés konfigurációját a pixelnek az oldalbetöltéskor, és a dupla Purchase megszűnik.

2. megoldás: az autoConfig kikapcsolása a pmw_facebook_auto_config szűrővel

Használd, ha nem tudod vagy nem akarod megváltoztatni a Meta Events Manager beállítását, például egy másik csapat által kezelt pixelnél, vagy ha a változtatásnak az oldal kódjában kell lennie, nem a Meta konfigurációjában.

A gyermektéma functions.php fájljában:

add_filter('pmw_facebook_auto_config', function ($enabled, $pixel_id) {
    return false;
}, 10, 2);

A Pixel Manager ilyenkor közvetlenül a pixel inicializálása előtt kiadja az fbq('set', 'autoConfig', false, '<pixel_id>') hívást, ami az egyetlen pillanat, amikor az fbevents.js figyelembe veszi a beállítást. Ettől kezdve a pixel ki van lépve a Meta AutomaticSetup funkciócsomagjából, és a pixelkonfigurációval egy pillanattal később érkező bekapcsoló hívások nem tudják visszakapcsolni. A szűrő pixelenként egyszer fut, ezért ha csak egy adott $pixel_id értékre ad false-t, többpixeles felállásban egyetlen pixelt fed le.

Veszély: ne csinálj ilyet saját window.fbq helyettesítővel. A Meta pixel-bootstrapja úgy kezdődik, hogy „ha az fbq már létezik, ne csinálj semmit”, ezért bármely helyőrző fbq, amelyet a Pixel Manager futása előtt definiálsz, megakadályozza az fbevents.js betöltését, és a Meta-pixel semmit nem követ. Ha a Pixel Manager idegen fbq-t talál, konzolfigyelmeztetést ír.

Figyelmeztetés: a 2. megoldás szélesebb, mint az 1. Az 1. megoldás pontosan az automatikus eseményészlelést kapcsolja ki; az autoConfig kikapcsolása a pixelt a Meta teljes AutomaticSetup csomagjából kiléptet, amely az fbevents.js jelenleg ismert kiadásában ezeket is tartalmazza:

• Mikroadat-gyűjtés és -dúsítás, amely az oldal jelölőkódjából olvasott custom_data mezőket ad a szabályos eseményekhez. A Pixel Manager felhasználói számára elhanyagolható, mert a Pixel Manager maga szolgáltatja az eseményadatot.
• A Meta reguláris kifejezés- és mesterségesintelligencia-alapú egyezési kiterjesztései és az AutomaticParameters műszerezése.
• SmartSetup, a Meta teljes ár kinyerését is beleértve.
• Elköteleződési műszerezés, például görgetési mélység, oldalmetaadatok és a Meta webchat-integrációja.
• Jövőbeli Meta-funkciók, amelyeket a Meta ugyanabban a csomagban szállít, nem érik el a pixelt, amíg a szűrő aktív.

Amit az autoConfig kikapcsolása nem érint, mert mindegyiknek saját bekapcsolója van:

• A pixelkonfiguráció letöltése és végrehajtása. Az autoConfig kikapcsolási lehetőség, nem olyan kapcsoló, amely megakadályozza a https://connect.facebook.net/signals/config/<pixel_id> fájl betöltését.
• Az Event Setup Tool szabályai és értékkinyerői. A szabálymotor saját kattintásfigyelőt telepít, és csak a saját bekapcsolóját ellenőrzi, így a szabály továbbra is lefut. Távolítsd el a szabályokat az Events Managerben (lásd lent).
• A Meta Conversions API Gateway (openbridge). Kapcsold le az Events Managerben (lásd lent).
• A Meta alapvető automatikus fejlett egyeztetése, az üzleti kategória szerinti eseménykorlátozásai, az első féltől származó sütik és a botblokkolás.

Az 1. megoldás a legtöbb boltnak jobb. A 2. megoldás azokra az esetekre van, amikor az Events Manager beállítása elérhetetlen, és a kettő nem egyenértékű.

Ha egyik megoldás sem állítja meg a duplákat

Ha már kikapcsoltad az automatikus eseményészlelést (1. megoldás) vagy az autoConfig beállítást (2. megoldás), és még mindig dupla Purchase események jelennek meg, az ok valószínűleg a Meta fbevents.js követőkönyvtárának egy külön, jól ismert, szakaszos hibája, nem az automatikus eseményészlelés. Folytasd a következő részszel, és futtasd az ott leírt egy-URL-es tesztet.

Miért nem javítja ezt magától a Pixel Manager: a dupla az fbevents.js belsejében keletkezik, miután a Pixel Manager átadta neki az irányítást, ezért a Pixel Manager a saját kódútvonaláról nem tudja elfogni. Az autoConfig kikapcsoló kapcsolót be tudná építeni, de a fent felsorolt szélesebb mellékhatások miatt nem lenne biztonságos alapból bekapcsolni mindenkinek. A Pixel Manager szabványos eseményazonosító-konvenciókat használ (pmw_<rendelés_azonosító> a vásárlásokhoz és pmw_<véletlen> a többihez), ami miatt a Meta által generált duplák egyáltalán könnyen azonosíthatók.

Duplák az automatikus észlelés kikapcsolása után is (az fbevents.js könyvtár hibája)

Akkor használd, ha már kizártad a gyakoribb okokat: nincs más Meta-pixel megvalósítás az oldalon, és a Track Events Automatically Without Code már ki van kapcsolva a Meta Events Managerben (lásd az előző részt), a duplák mégis megjelennek. Ez a Meta fbevents.js követőkönyvtárának ismert, szakaszos hibája. A javítás egy régebbi, bizonyítottan jó fbevents.js verzió betöltése. A megerősítő oldalon egy egy-URL-es teszttel kevesebb mint egy perc alatt megerősítheted az okot.

A Meta támogatását nehéz rávenni a hiba javítására. A Pixel Managerben szerencsére van beépített kerülőmegoldás.

Gyors teszt: régebbi fbevents.js betöltése az URL-ből. Úgy erősítheted meg, hogy ez a hiba-e az ok, hogy egyetlen oldalbetöltésre a Meta fbevents.js könyvtárának régebbi verzióját töltöd be, egy lekérdezési paraméter hozzáfűzésével az olyan oldal URL-jéhez, ahol a dupláit látod (jellemzően a megerősítő oldal, például /checkout/order-received/...).

1. Válassz tesztelésre egy régebbi verziót. A 2.9.84 verzió a tesztekben működőnek bizonyult.
2. Fűzd az oldal URL-jéhez az fbevents-version=2.9.84 paramétert, például: https://example.com/checkout/order-received/12345/?key=...&fbevents-version=2.9.84
3. Nyisd meg az oldalt, és figyeld a Meta Events Managert vagy a böngésző Network fülét. Ha a dupla Purchase események megszűnnek, megerősítetted, hogy követőkönyvtár-hibáról van szó. Ha folytatódnak, valami másról van szó: ellenőrizd újra az oldalon a duplikált pixelmegvalósításokat, vagy az automatikus eseményészlelésről szóló részt.

Állandó megoldás: ha az URL-teszt megerősítette az okot, használd az alábbi szűrőt, hogy a Pixel Manager minden látogatónak mindig ezt a régebbi fbevents.js verziót töltse be. A téma functions.php fájljában:

add_filter('pmw_facebook_fbevents_script_version', function () {
    return '2.9.84';
});

A szűrő hozzáadása után ürítsd ki az összes szerveroldali gyorsítótárat (gyorsítótár-bővítmény, oldal-gyorsítótár, CDN), különben a látogatók továbbra is a gyorsítótárazott oldalt kapják az fbevents.js jelenlegi URL-jével.

Még ha az automatikus eseményészlelés már ki is van kapcsolva az Events Managerben, érdemes ezt az URL-tesztet korán lefuttatni minden duplaesemény-vizsgálatnál: másodpercek alatt kizárja vagy igazolja a leggyakoribb megmaradt okot.

Extra események a Meta Event Setup Tool szabályai miatt

Összefoglaló: ha a Meta Events Manager extra Purchase, AddToCart, InitiateCheckout vagy más szabványos eseményeket mutat, amelyek gombkattintáskor futnak le, eseményazonosító nélkül és általában érték nélkül, akkor az eseményeket a pixelen tárolt, rámutatós-kattintós Event Setup Tool szabályok váltják ki a Meta Events Managerben, nem a Pixel Manager. Távolítsd el a szabályokat az Events Managerben: Data sources → válaszd ki a pixelt → Settings → Event setup → Manage.

A Pixel Manager automatikusan észleli ezeket a szabályokat, és figyelmeztetést jelenít meg az Opportunities fülön és a hibakeresési jelentésben, ha aktív szabályokat talál a pixelen.

Tünet: a Meta Events Manager eseményszámai felfújtak, és a vásárlási értékek hibásak vagy hiányoznak. Közelebbről nézve extra szabványos események futnak le, valahányszor a látogató egy adott gombra kattint, például Purchase esemény a rendelés leadása gomb minden kattintásakor, akkor is, ha a fizetés meghiúsul és nem jön létre rendelés. Az extra eseményeknek nincs eseményazonosítójuk, így a Meta nem tudja deduplikálni őket a Pixel Manager által küldött, helyesen követett eseményekkel szemben, és általában nem hordoznak értéket, vagy az oldalról kinyert értéket hordoznak.

Miért történik: a Meta Event Setup Tool lehetővé teszi, hogy bárki, aki hozzáfér a pixelhez, eseményeket definiáljon a weboldal elemeire való rámutatással és kattintással, jellemzően úgy, hogy „indíts egy Purchase eseményt, ha egy ilyen szöveget tartalmazó gombra kattintanak”. Ezeket a szabályokat gyakran régen állította be valaki, egy ügynökség, vagy egy korábbi követési próbálkozás során, és a boltosok ritkán tudják, hogy még léteznek.

Az eszköz áll a Set up the selected events for me gomb mögött is, amelyet az Events Manager a Manage Events alatt kínál. Ennek elfogadása pontosan az itt leírt szabályokat hozza létre, ezért utasítsd vissza: az események, amelyeket a Meta hiányzónak jelöl, abból származnak, amit a Meta maga észlelhetett, nem abból, amit a pixeled ténylegesen küld.

A szabályok nem az oldaladon tárolódnak. A pixelen magán vannak, és a pixel nyilvános konfigurációs fájljával jutnak el minden böngészőhöz a https://connect.facebook.net/signals/config/<pixel_id> címről, estRules (eseményszabályok) és iwlExtractors (értékkinyerő szabályok, amelyek az oldal HTML-jéből kaparják ki az összegeket) néven. Ha egy szabály illeszkedik, az fbevents.js közvetlenül, a Pixel Manager kódján kívül lövi ki az eseményt.

Mivel a szabályalapú eseményeknek nincs eseményazonosítójuk, a deduplikáció lehetetlen. Az eredmény rendszeres kettős számolás: egy helyes, deduplikált esemény a Pixel Managertől, plusz egy csalárd esemény a szabálytól. A rendelés leadása gombhoz kötött Purchase szabály a legrosszabb eset, mert minden kattintási kísérletnél lefut, a meghiúsult fizetéseknél is, és jellemzően a rendelés értéke nélkül.

Hogyan azonosítod ezt az okot:

• A Pixel Managerben nyisd meg az Opportunities fület. Ha aktív Event Setup Tool szabályokat talál a pixeleden, egy figyelmeztető kártya pixelenként felsorolja az érintett eseményneveket. Ugyanez az információ megjelenik a hibakeresési jelentésben a Meta Event Setup Tool alatt. A friss kiadásban mindkettő felsorolja a szabály- és értékkinyerő-azonosítókat és azt az URL-t, amelyre az egyes értékkinyerők hatókörrel vannak, és a Meta támogatásának pontosan ez kell.
• Kézzel: nyisd meg a böngészőben a https://connect.facebook.net/signals/config/<pixel_id> címet (cseréld a <pixel_id> részt a pixel azonosítójára), és keresd a fájlban az estRules szót. Az olyan szabályok, amelyekben "rule_status":"ACTIVE" és "derived_event_name" szerepel, a megnevezett eseményt lövik ki. Keresd az iwlExtractors szót is, amely az értékkinyerő szabályokat sorolja fel.
• A Network fülön: azon az oldalon, ahol az extra esemény lefut, nyisd meg a Chrome DevTools-t, szűrj a facebook.com/tr kifejezésre, és kattints az adott gombra. A szabály által kiváltott kérések cd[cs_est]=true paramétert hordoznak, és nincs bennük a Pixel Manager pmw_ formátumú eid értéke.

Megoldás: távolítsd el a szabályokat a Meta Events Managerben:

1. Jelentkezz be a Meta Business Managerbe, és nyisd meg az Events Managert.
2. A bal oldali sávban válaszd a Data Sources részt, és kattints a megfelelő pixelre.
3. Kattints a Settings fülre.
4. Görgess az Event setup részhez, és kattints a Manage gombra.
5. Töröld vagy kapcsold ki az összes itt felsorolt szabályt. A Pixel Manager már minden bolteseményt deduplikációval és pontos értékekkel követ, ezért egyik szabályra sincs szükség.

Rövid terjedési késleltetés (általában percek, legfeljebb a konfigurációs gyorsítótár lejártáig) után a pixelkonfiguráció már nem tartalmazza a szabályokat, és a csalárd események megszűnnek.

Ha a szabályok a törlés után is megmaradnak. Két dolog szokta életben tartani a szabályokat, miután azt hiszed, hogy eltávolítottad őket:

• A listát a megnyitott URL szűri. Az Event Setup Tool csak annak az oldalnak a szabályait és értékkinyerőit mutatja, amelyre megnyitották. A /checkout/ címre szóló Purchase szabály láthatatlan, ha az eszközt a kezdőlapon nyitod meg. Nyisd meg pontosan azon az URL-en, amelyet a Pixel Manager jelent a bejegyzéshez.
• A Meta néha továbbra is kiszolgálja a törölt szabályokat. Láttunk olyan pixeleket, ahol tizenegy törölt szabályból kilenc eltűnt a nyilvános konfigurációból, a maradék kettő pedig hetekig "rule_status":"ACTIVE" állapotban maradt. Sem az oldalon, sem a Pixel Managerben nem lehet eltávolítani őket, és a törlés megismétlése sem segít.

A második esetben fordulj a Meta támogatásához a Pixel Manager hibakeresési jelentésében lévő szabály- és értékkinyerő-azonosítókkal (Meta Event Setup Tool), közöld, hogy a bejegyzéseket törölted az Events Managerben, de a https://connect.facebook.net/signals/config/<pixel_id> fájlban még aktívként szolgálják ki őket, és kérd, hogy távolítsák el az árva bejegyzéseket. Addig a Pixel Manager tovább jelenti őket, mert a vizsgálat a Meta élő konfigurációját olvassa, nem az Events Manager képernyődet.

Figyelmeztetés: az oldalról nincs mód ezeknek a szabályoknak a leállítására. Az autoConfig kikapcsolása (a pmw_facebook_auto_config szűrő) itt nem segít, bár a régi kiadások szerint igen: a Meta szabálymotorja saját kattintásfigyelőt telepít, és csak a saját bekapcsolóját ellenőrzi, amelyet az autoConfig nem töröl. A szabályoknak a Meta oldalán kell megszűnniük.

Hogyan olvasd a Meta „browser received” és „server received” eseményszámait

Összefoglaló: a Meta Events Manager browser received és server received számai, és a mögöttük lévő CSV-export, nyers beérkezési számok a deduplikáció előtt. Az a bolt, amely a Pixel Manager böngészőpixelét a Conversions API-val együtt futtatja, tervezetten több szerveroldali eseményt mutat, mint böngészőoldalit, és ezeknek az oszlopoknak az aránya sosem jelenti azt, hogy a konverzióidat kétszer számolták. Azok a nézetek, amelyek azt mutatják, mit számolt a Meta valójában: az Event deduplication és az Event match quality → Additional conversions reported.

Minden Meta-hibaelhárítás előbb-utóbb az Events Manager számaihoz jut, és három nézetet rendszeresen tünetként olvasnak, pedig nem azok. Mindegyik ezt mutatja:

Browser received és server received (Events Manager → az eseményed → Overview, és a CSV-export). Ez a két oszlop azt számolja, hány esemény érkezett a Metához az egyes csatornákon, mielőtt a Meta összevonja az egyező párokat. A Pixel Manager a böngészőből és a szerverről is elküldi ugyanazt a Purchase eseményt, mindkettő azonos pmw_<rendelés_azonosító> eseményazonosítóval, ezért mindkét csatorna jelenti az eseményt, és a Meta egyetlen konverzióvá egyesíti a párt. Ha az esemény mindkét oszlopban látszik, a rendszer működik.

Az egészséges kép:

• A server received magasabb, mint a browser received. A Pixel Manager fizetett rendelésenként pontosan egy szerveroldali Purchase eseményt küld, akár túlélte a böngészőpixel, akár nem. A böngészőesemény csak azon vásárlók arányára létezik, akiknek a böngészője nem blokkolta az fbevents.js fájlt, és akik ténylegesen elérték a megerősítő oldalt. A két oszlop közti különbség nem veszteség, hanem pontosan azoknak a konverzióknak a halmaza, amelyek visszanyerésére a Conversions API való. Az a bolt, ahol a vásárlók 70%-ánál keletkezik böngészőesemény, nagyjából 100 szerveroldali eseményt mutat 70 böngészőoldali mellett.
• Egyik oszlop sem árul el semmit a kettős számolásról. Ahhoz nyisd meg az Event deduplication nézetet, vagy az Event match quality → Additional conversions reported részt. Az utóbbi azt jelenti, hogy a Meta a deduplikáltakon felül a konverziók mekkora hányadát számolta. A Purchase esetén a 0% azt jelenti, hogy semmi extra nem lett számolva, bármit mutatnak is a beérkezési oszlopok.
• Az arány nő azon rendelések hányadával, amelyek sosem a pénztáradon át érkeztek. A szerveroldali Purchase minden olyan rendelésre kimegy, amely fizetett állapotot ér el, bármi hozta is létre a rendelést: ERP- vagy piactér-integráció a REST API-n át, adminban a személyzet által leadott rendelések, előfizetés-megújítások és napokkal a pénztár után fizetett állapotba lépő rendelések. Egyiknek sincs párosítható böngészőeseménye, ezért mind csak a szerveroszlopot növeli. Az a bolt, amely a rendeléseinek zömét integráción át veszi fel, jogosan mutathat nyolc vagy több szerveroldali eseményt böngészőoldali eseményenként, a 0% körüli deduplikációs lefedettséggel és szinte nulla szerveroldali _fbp értékkel. A deduplikációnak nincs mit párosítania, nem a rosszat párosítja. A méret felméréséhez használd a Click ID Capture Quality jelentés „Order origin (created_via)” bontását.

Ami valóban vizsgálatot érdemel:

• A server received a browser received tiszta többszöröse, óráról órára, de csak azokban az órákban, amikor lefutott böngészőesemény. Ez a minta tükör: valami a böngészőeseményeket átmásolja a szervercsatornába. A szokásos ok a Meta saját Conversions API Gateway-e, lásd lent.
• A server received messze magasabb, mint a fizetett rendeléseid száma. Ez a második szerveroldali küldőre utal ugyanazon az adatforráson, nem tükörre. Nézd át az Events Manager → Settings → Integrations részt. Számold meg minden eredetű és minden olyan állapotú rendelést, amely aznap fizetett állapotot ért el, nem csak a webshopon át leadottakat: a nap szerveroldali eseményeinek csak a webshop-rendelésekhez hasonlítása a leggyakoribb módja, hogy ez a teszt elbukik, és hogy egy egészséges bolt úgy tűnik, rendelésenként nyolc eseményt küld.

A Test Events ablak üres marad (Events Manager → Test Events). A szerveroldali események csak akkor jelennek meg a Test Events ablakban, ha tesztesemény-kódot hordoznak, és a Pixel Manager ezt a mezőt éles üzemben szándékosan üresen hagyja. Egy normál rendelés ezért sosem jelenik meg ott, és ez várt viselkedés, nem sikertelen esemény. Az ablak használatához állíts be kódot a Tracking Pixels → Meta → CAPI Test Event Code mezőben a teszt idejére, aztán töröld.

A Sampled activities egy minta (Events Manager → az eseményed → Sampled activities). Ahogy a neve is mondja, ez a fül a legutóbbi események mintáját mutatja, nem teljes naplót, és rendszeresen egyetlen sort sem jelenít meg. Ha egy rendelés hiányzik belőle, az nem bizonyíték arra, hogy a Meta nem kapta meg az eseményt. Egyetlen rendelés megerősítéséhez használd az Event deduplication nézetet, vagy a Test Events ablakot beállított tesztesemény-kóddal.

A Meta Conversions API Gateway minden böngészőeseményhez egy második szerveroldali eseményt küld

Összefoglaló: ha a server received szám közel pontosan kétszerese a browser received számnak minden olyan órában, amikor lefutott egy böngészőesemény, az extra szerveroldali események szinte biztosan a Meta saját Conversions API Gateway-ének (belső nevén OpenBridge) tükrei. Ez minden böngészőpixel-eseményt lemásol, és másodszor is eljuttatja a Metához a szervercsatornán. A Meta oldalán fut, láthatatlan a WordPress bővítménylistájában, és túléli azon bővítmény eltávolítását, amely egykor beállította. Kapcsold ki a Gateway-kapcsolatot az Events Manager → Settings → Integrations alatt, és tartsd meg a Pixel Manager Conversions API-ját.

Tünet: a Purchase beérkezési számok rendszeres, nem alkalmi arányt mutatnak: 1 böngészőesemény 2 szerveroldali ellen, 3 a 6 ellen, és így tovább, egy 28 napos export legtöbb órájában. Eközben a boltban csak egy követőbővítmény fut, az oldal forrásában nincs második pixelkódrészlet, és a Pixel Manager saját védelmei a dupla vásárláskövetés ellen igazoltan a helyükön vannak.

Miért történik: a Meta Conversions API Gateway a Meta által üzemeltetett átjátszó. Ha egy pixelhez van kapcsolva, a Meta egy openbridge blokkot ad a pixelkonfigurációban, amelyet minden látogató böngészője letölt a https://connect.facebook.net/signals/config/<pixel_id> címről. Az fbevents.js ezután betölti az openbridge3 bővítményt, és bekapcsolja a pixelen, és attól kezdve a böngészőpixel által küldött minden eseményt POST-tal elküld a Gateway végpontjára is, ami szerveroldali eseményként továbbítja a Metának.

Egyetlen rendelés egy olyan boltban, amely a Gateway-t és a Pixel Manager Conversions API-ját is futtatja, így három érkezést eredményez:

1. egy böngészőoldali Purchase a Pixel Manager pixeljétől,
2. egy szerveroldali Purchase, amely a Gateway tükre a böngészőeseményről,
3. egy szerveroldali Purchase a Pixel Manager Conversions API-jától.

Ez az 1:2 arány, és csak azokban az órákban jelenik meg, amikor lefutott böngészőesemény, mert egyébként a Gateway-nek nincs mit tükröznie. Hosszabb időszakon a számtan félreérthetetlen. Egy bolt 28 nap alatt 74 böngészőoldali és 180 szerveroldali Purchase eseményt mért: a szerveroldali események közül 74 a Gateway tükre volt a böngészőeseményekről, a maradék 106 a Pixel Managertől jött, fizetett rendelésenként egy. A 106 rendelés és a 74 böngészőesemény különbsége azon vásárlók szokásos hányada, akiknek a böngészőpixelét blokkolták.

A konverzióidat nem számolják kétszer. A Gateway tükre a böngészőesemény saját eseményazonosítóját hordozza, így a Meta ugyanúgy deduplikálja a párt, ahogy a Pixel Manager böngészőoldali és szerveroldali eseményeit. Ellenőrizd az Event match quality → Additional conversions reported nézetben, ahol a Purchase értéke 0% kell legyen.

Hogyan azonosítod ezt az okot:

• Az Events Managerben nyisd meg a Settings → Integrations részt (egyes nézetekben Your existing integrations). A csatlakoztatott Gateway Conversions API Gateway néven szerepel, Connected jelvénnyel és a pixel nevével, amelyet táplál. Ugyanebben a listában jelennek meg az eltávolított bővítményekből maradt kapcsolatok is, például a Meta for WooCommerce bővítményből hátramaradt WordPress-kapcsolat. A kikapcsolt WordPress-bővítmény nem tud semmit küldeni, az adatbázis-sorai tétlenek, de a kapcsolat, amelyet a Meta a saját oldalán tart, túléli a bővítményt.
• Kézzel, a pixelkonfigurációból: nyisd meg a böngészőben a https://connect.facebook.net/signals/config/<pixel_id> címet, és keresd az openbridge szót. Az aktív Gateway egy config.set("<pixel_id>","openbridge",{"endpoints":[…]}) blokkként jelenik meg, amelyet egy fbq.loadPlugin("openbridge3") és egy optIn(…,"OpenBridge",true) hívás követ. A blokk egy eventsFilter mezőt is hordoz; blocklist módban minden, nem megnevezett esemény tükröződik, így a listából hiányzó Purchase másolódik.

Megoldás: kapcsold le a Gateway-t, és tartsd meg a Pixel Manager Conversions API-ját:

1. Jelentkezz be a Meta Business Managerbe, és nyisd meg az Events Managert.
2. Válaszd a Data Sources részt, kattints a megfelelő pixelre, és nyisd meg a Settings fület.
3. Az integrációk listájában keresd meg a Conversions API Gateway bejegyzést, és kattints a See Details gombra.
4. A Gateway panelen nyisd meg a Settings részt, és kattints a Disconnect gombra. Erősítsd meg a párbeszédablakot, majd kattints a Next és a Finish gombra.
5. Közben távolítsd el az ugyanazon az adatforráson lévő elavult kapcsolatokat, például egy már nem futtatott Meta-követőbővítményből hátramaradt WordPress-kapcsolatot.
6. Ha a Gateway-t a saját AWS-fiókodban telepítették, az Events Managerben való lekapcsolás nem távolítja el a felhőerőforrásokat, és azok tovább költenek. Az AWS-konzolban töröld a Gateway CloudFormation-stackjét, majd a CloudWatch naplócsoportját, amelyet a stack törlése hátrahagy.

A Pixel Manager figyelmeztető kártyája az Opportunities fülön a Gateway lekapcsolása után akár egy napig látszhat, mert a Pixel Manager naponta egyszer újra ellenőrzi a Meta pixelkonfigurációját. A közvetlen ellenőrzéshez nyisd meg a https://connect.facebook.net/signals/config/<pixel_id> címet, és győződj meg róla, hogy az openbridge már nem jelenik meg. A Meta eltarthat egy ideig, mire a lekapcsolás után frissíti ezt a fájlt, ezért az, hogy az openbridge blokk közvetlenül a változtatás után még ott van, nem jelenti, hogy a lekapcsolás nem sikerült.

Nem éri meg mindkettőt futtatni. A Gateway csak azokat az eseményeket tükrözheti, amelyeket a böngésző már elküldött, ezért semmit nem tesz hozzá azon rendelések nagyjából 20-40%-ához, ahol a böngészőpixelt blokkolták, vagy a vásárló sosem érte el a megerősítő oldalt. A Pixel Manager Conversions API-ja a szerverről küld, fizetett rendelésenként egyszer, így pontosan ezeket fedi le. Két szerveroldali küldő ugyanazon a pixelen beérkezési zajt és egy második átgondolandó dolgot ad, anélkül hogy egyetlen visszanyert konverziót is hozzátenne.

Figyelmeztetés: a Gateway az oldalról sem kapcsolható ki. Az autoConfig kikapcsolása (a pmw_facebook_auto_config szűrő) nem állítja meg a tükrözést, bár a régi kiadások szerint igen: az fbevents.js az openbridge használatát a saját bekapcsolójához köti, amelyet az autoConfig nem töröl. Kapcsold le a Gateway-t az Events Managerben.

A Facebook Ads Manager több konverziót mutat, mint ahány WooCommerce-rendelés van

Ez az egyik leggyakoribb kérdés. Mielőtt bármi mást tennél, állapítsd meg a valós helyzetet: az Ads Manager attribúciós modellezést (attribúciós ablakok, megtekintésalapú jóváírás, késleltetett újraszámolások) alkalmaz a nyers események tetején, ezért csak a Meta Events Manager tudja megmondani, hogy egy esemény ténylegesen többször lefutott-e. Válassz ki egy ismert rendelést, keresd meg a Purchase eseményeit az Events Managerben (idő és érték alapján), és számold meg őket. Rendelésenként pontosan egy deduplikált esemény azt jelenti, hogy a követés helyes, és az eltérés az Ads Manager jelentési viselkedése. Egynél több esemény valódi duplikációt jelent: ilyenkor menj végig sorban az alábbi ellenőrzőlistán.

Egy megjegyzés, mielőtt számolni kezdesz: a browser received és server received oszlopok a deduplikáció előtti nyers beérkezési számok, és aktív Conversions API mellett a szerveroszlop tervezetten a magasabb. Mielőtt az ott látható arányt duplikációnak vennéd, olvasd el a „Hogyan olvasd a Meta browser received és server received eseményszámait” részt.

1. Ellenőrizd a duplikált pixelmegvalósításokat. Gondoskodj róla, hogy csak egy bővítmény vagy kódrészlet lövi ki a Meta-pixelt az oldaladon. Ha a Pixel Manager mellett másik Meta-követőbővítményt futtatsz, vagy kézi pixelkód van a témádban, távolítsd el a duplákat. Ellenőrizd a Meta Events Manager → Test Events részben.
2. Kapcsold ki az Automatic Events beállítást a Meta Events Managerben. Events Manager → a pixeled → Settings → kapcsold ki az Automatic Events (néha Track Events Automatically Without Code) beállítást. Ez a Meta-funkció a meglévő pixelmegvalósításod tetejére lő ki eseményeket, és felfújhatja a konverziós számokat. Ha a dupla eseményazonosítót össze tudod vetni a pmw_<16 karakter>_<hosszú szám> formátummal, ez szinte biztosan az ok: a teljes diagnózist lásd a külön bejegyzésben.
3. Távolítsd el az Event Setup Tool szabályait. A pixelen tárolt rámutatós-kattintós szabályok extra eseményeket lőnek ki gombkattintásra, eseményazonosító nélkül és általában érték nélkül. A Pixel Manager az Opportunities fülön figyelmeztet ezekre: lásd a külön bejegyzést.
4. Ellenőrizd a CAPI-deduplikációt. Ha a böngészőpixelt és a Conversions API-t is használod, nézd meg, hogy az Events Managerben az események „Deduplicated” jelölést mutatnak-e. Ha nem, gondoskodj róla, hogy egy bővítmény kezelje mindkét oldalt. A Pixel Manager automatikusan egyező event_id értékeket generál a megfelelő deduplikációhoz. A böngészőpixel és a CAPI különböző eszközök közti megosztása a kettős számolás gyakori oka.
5. Vizsgáld át az adatforrás többi küldőjét. A pixelt nem csak az oldalad táplálhatja. A Meta saját Conversions API Gateway-e minden böngészőeseményt a szervercsatornába tükröz, és ez a leggyakoribb rejtett második küldő: lásd a külön bejegyzést. Ellenőrizd az Events Manager → Settings → Integrations részt is offline vagy CSV-feltöltésekre, katalógusintegrációkra, partnerösszekötőkre (például Stape), és azokra a kapcsolatokra, amelyeket már eltávolított követőbővítmények hagytak hátra.
6. Nézd meg, mely eseményeket számolod konverziónak. Az Ads Managerben, ha a kampányod az AddToCart és a Purchase eseményt is konverziónak számolja, mindkettő megjelenik a „Conversions” oszlopban. Az Ads Managerben csak a vásárlási konverziókat nézd, ne az összesített „Conversions” vagy „Results” oszlopot, amely más eseményeket, például AddToCart vagy űrlapküldést is tartalmazhat.

Ne feledd: a Facebook vásárlási konverzióinak mindig alacsonyabbnak kell lenniük, mint a WooCommerce-rendelések teljes száma, mert a Facebook csak a hirdetési interakciókhoz rendel konverziót. Ha a Facebook több vásárlási konverziót jelent, mint a teljes WooCommerce-rendelésszámod, az egyértelmű jele technikai problémának.

A Meta kevesebb eseményt mutat, mint ahány látogatója van a boltnak

Összefoglaló: ha a Meta Events Manager valódi eseményeket kap, de jóval kevesebbet, mint ahány látogatója van a boltnak, az ok majdnem mindig a négy közül az egyik: a lusta betöltés visszatartja a követést, amíg a látogató interakcióba nem lép; a kifejezett hozzájárulás visszatartja, amíg a sütibannert el nem fogadják; egy külső oldalon fizetős átjáró megakadályozza, hogy a vásárlók elérjék a megerősítő oldalt; vagy a látogató blokkolja a pixelt. Ezek egyike sem követési hiba, és mindegyiknek más a megoldása.

Ugyanezek az okok minden más pixelre is érvényesek, ezért amit itt megtudsz, ugyanúgy megmagyarázza az alacsony eseményszámot a Google Adsben, a TikTokon vagy a Pinteresten.

Kezd a konzolnaplózóval: tölts be egy termékoldalt az URL-hez fűzött ?pmwloggeron paraméterrel, és ne nyúlj az oldalhoz. A konzolban látottak megmondják, melyik a négy közül.

1. Lusta betöltés (Pro). Ha a konzol üres marad, amíg meg nem mozdítod az egeret vagy le nem nyomsz egy billentyűt, és az oldal forrásában a Pixel Manager szkriptje type="text/pmw-lazy" típussal szerepel, a lusta betöltés aktív. Minden látogató, aki érkezik és interakció nélkül távozik, követetlen marad. Az asztali látogatók szinte azonnal kiváltják az egérmozgással, ezért a veszteségek a mobillátogatókra koncentrálódnak, akik sosem görgetnek. A vásárlásokat ez sosem érinti. Kapcsold ki a General → General → Lazy-load the Pixel Manager beállításnál, vagy előbb olvasd el a teljes kompromisszumot az Általános beállítások fejezetben.
2. Kifejezett hozzájárulás. Keresd a konzolban a Consent mode: explicit sort, amelyet egy Region check sor követ. A Region check: restricted → blocking all categories azt jelenti, hogy ez a látogató a korlátozott régiók listádon belül van, és semmi nem megy ki, amíg el nem fogadja a bannert. Ez a beállítás szándékolt működése, és mindazok eseményei elvesznek, akik figyelmen kívül hagyják a bannert. Két dolgot érdemes ellenőrizni: hogy a korlátozott régiók listád valóban megegyezik-e azokkal az országokkal, ahol jogilag előbb hozzájárulást kell kérned, és hogy a bannered elég feltűnő-e ahhoz, hogy ténylegesen válaszoljanak rá. Lásd a Hozzájárulás és adatvédelem fejezetet.
3. Konkrétan a vásárlások. Ha a tölcsér eseményei egészségesnek látszanak, de a vásárlások hiányoznak, a bolt valószínűleg egy külső oldalon fizetős átjárót használ, amely nem megbízhatóan viszi vissza a vásárlókat a megerősítő oldalra. Nyisd meg a hibakeresési jelentést a WooCommerce → Pixel Manager → Support alatt, és olvasd el a WooCommerce Payment Gateways részt: átjáróként jelenti, hogy a legutóbbi rendelések közül hány érte el a megerősítő oldalt, és a hiányzók közül hányat nyert vissza az Automatic Conversion Recovery. Lásd a Funkciók fejezetet.
4. Reklámblokkolók és követésvédelem. Minden bolt látogatóinak egy része egyenesen blokkolja az fbevents.js fájlt, ami a konzolban Failed to load resource: net::ERR_BLOCKED_BY_CLIENT üzenetként jelenik meg. A Conversions API ennek egy részét visszanyeri, a Server-Side Proxy (Szerveroldali követés) pedig jóval többet, mert a követést a saját domainedről szolgálja ki.

A boltlátogatók és a Meta-események közti eltérés még tökéletes beállítás mellett is normális, már a 4. pont miatt is. Az aggasztó az, ha a különbség hirtelen nő, vagy ha nem ritkul, hanem egész eseménytípus hiányzik. A hiányzó eseménytípus másra utal: lásd a következő bejegyzést.

A Meta csendben elejti az AddToCart, InitiateCheckout és Purchase eseményeket (korlátozott üzleti kategória)

Összefoglaló: ha a Meta Events Manager megkapja a PageView és a ViewContent eseményt, de az AddToCart, InitiateCheckout, AddPaymentInfo és Purchase eseményt soha, és sehol nincs hiba, akkor a Meta valószínűleg azért blokkolja ezeket, mert a pixeled besorolt üzleti kategóriája korlátozott. Az egészség és wellness a legtöbbször érintett kategória. A blokkolás a Meta saját fbevents.js könyvtárában érvényesül, és a Conversions API (CAPI) sem kerüli meg. Az oldalon semmilyen bővítmény, kódrészlet vagy beállítás nem tudja elküldeni ezeket az eseményeket, amíg a korlátozás aktív. A Meta oldalán kell megoldani, az Events Managerben, az üzleti kategória kijavíttatásával vagy felülvizsgáltatásával.

A Pixel Manager automatikusan észleli a korlátozást, és megnevezi a blokkolt eseményeket a böngészőkonzolban és a hibakeresési jelentés Meta Business Category Event Restrictions része alatt.

Tünet: a követés elromlottnak látszik, de csak a tölcsér alsó részén:

• A PageView és a ViewContent a szokásos módon megérkezik a Meta Events Managerbe.
• Az AddToCart, InitiateCheckout, AddPaymentInfo és Purchase soha nem érkezik meg: sem az Events Managerben, sem a Test Events eszközben, még a saját magad leadott tesztvásárlásnál sem.
• A böngészőkonzol nem mutat hibát. A Pixel Manager konzolnaplózója (?pmwloggeron) azt jelzi, hogy elsütötte az eseményt.
• A böngésző Network fülén nincs kérés a facebook.com/tr felé a hiányzó eseményekhez, míg a PageView és ViewContent kérései ott vannak.
• A Meta-bővítmények cseréje, az újratelepítés, a gyorsítótárak ürítése, a hozzájárulás-kezelés kikapcsolása és a Conversions API bekapcsolása semmit nem változtat.

Mivel a kosárba tétel és a vásárlás pontosan azok az események, amelyek a boltosokat érdeklik, ez bővítményhibának látszik. Nem az. A Pixel Manager normálisan hívja az fbq('track', 'AddToCart', ...) függvényt, a Meta könyvtára panasz nélkül elfogadja a hívást, majd eldobja.

Miért történik: a Meta korlátozza, milyen adatot fogad el az érzékeny ágazatokban működő hirdetőktől. Ha egy pixel olyan vállalkozáshoz tartozik, amelyet a Meta korlátozott kategóriába sorolt (leggyakrabban egészség és wellness: például orvosi eszközök, orvosi riasztók, étrend-kiegészítők, gyógyszertárak, klinikák, terápiás és mentálhigiénés szolgáltatások, orvosi tesztkészletek), a Meta blokkolja az alsó tölcsér konverziós eseményeit az adott pixelen, és csak az általánosabbakat tartja meg.

A korlátozás a pixelen él, nem az oldaladon. A Meta a pixel nyilvános konfigurációs fájljában juttatja el minden böngészőhöz a https://connect.facebook.net/signals/config/<pixel_id> címről, egy eventValidation bejegyzésként, amely a blokkolt eseményneveket a restrictedEventNames alatt sorolja fel. A Meta fbevents.js könyvtára beolvassa ezt a listát, és valahányszor az oldalad egy ilyen eseményt követne, elküldés előtt eldobja. Semmi nem jut el a Metához, és hibaként sem naplózódik.

Két következményt érdemes kimondani, mert mindkettőről gyakran azt hiszik, hogy kerülőmegoldás, pedig nem az:

• A Conversions API nem segít. A korlátozás az adatforrásra (a pixelre és a domainre) vonatkozik, nem a szállításra. A korlátozott eseménynevekhez tartozó szerveroldali eseményeket a Meta fogadja, majd eldobja, így a Purchase CAPI-n át küldése nem számoltatja el. A CAPI kedvéért bármelyik bővítmény Pro változatának megvásárlása nem javítja ezt.
• Az események átnevezése vagy színlelése sem segít. Az adatok egyedi eseményként, más névvel küldése átjuthat, de nem lesz használható szabványos konverziós eseményként az optimalizáláshoz, és a korlátozott adatok meghamisítása veszélybe sodorhatja a hirdetési fiókot. A helyes út a kategorizálás rendezése a Metánál.

A korlátozott kategóriájú pixelek gyakran hordoznak egy protectedDataMode bejegyzést is ugyanabban a konfigurációs fájlban, amely az átengedett eseményekről is lehántja az egyedi paramétereket. Így még a túlélő események is kevesebb adattal érkezhetnek, mint amennyit elküldtél.

Hogyan azonosítod ezt az okot:

• Nyiss meg bármelyik boltoldalt az URL-hez fűzött ?pmwloggeron paraméterrel, és nézd a böngészőkonzolt. Ha a pixel korlátozott, a Pixel Manager figyelmeztetést ír, amely megnevezi az összes blokkolt eseményt. Ugyanez az információ a hibakeresési jelentésben (Support → Debug report) a Meta Business Category Event Restrictions alatt található.
• Kézzel, a pixelkonfigurációban: nyisd meg a böngészőben a https://connect.facebook.net/signals/config/<pixel_id> címet (a <pixel_id> helyére a saját pixelazonosítód kerül), és keresd a fájlban a restrictedEventNames szót. Ha nem üres listát találsz, azok az eseménynevek vannak blokkolva. Így néz ki egy korlátozott pixel: {"unverifiedEventNames":[],"restrictedEventNames":["AddPaymentInfo","AddToCart","AddToWishlist","InitiateCheckout","Purchase"]}
• Kézzel, futásidőben: a bolt bármelyik oldalán, a böngészőkonzolban futtasd: JSON.stringify(fbq.instance.pluginConfig.get('<pixel_id>', 'eventValidation'))
• Kontrollteszt: a böngészőkonzolban kövess egy eseményt a korlátozott listából és egyet, ami nincs rajta, majd hasonlítsd össze. Csak a korlátozatlan hoz létre kérést a facebook.com/tr felé:

fbq('track', 'Purchase', {value: 1, currency: 'USD'})
fbq('track', 'Search', {search_string: 'test'})
performance.getEntriesByType('resource').filter(r => r.name.includes('facebook.com/tr')).map(r => r.name)

Ez a végleges teszt. Bizonyítja, hogy az események helyesen jutnak el a Meta könyvtárához, és hogy a könyvtár dobja el őket.

Megoldás: ellenőrizd a kategóriát és az eseményblokkolást a Meta Events Managerben. A korlátozás az adatforrásra (a pixelre és a domainre) vonatkozik, ezért a Meta Events Managerben kell megoldani. A Meta rendszeresen átrendezi a felületét, ezért a lenti címkéket útmutatónak tekintsd, nem rögzített útvonalnak:

1. Jelentkezz be a Meta Business Managerbe, és nyisd meg az Events Managert.
2. Válaszd a Data sources részt, és kattints az érintett pixelre.
3. Nyisd meg a Settings fület, és keresd a Manage data source categories részt (kattints a Manage gombra). Itt látszik a Meta által az adatforrásodhoz rendelt üzleti kategória, és itt kategorizálhatod át magad.
4. Még a Settings alatt keresd a Manage event blocking részt (kattints a Review gombra). Ez sorolja fel azokat az eseményeket, amelyeket a Meta jelenleg blokkol az adatforráshoz. A listának egyeznie kell azzal, amit a Pixel Manager a konzolban és a hibakeresési jelentésben jelent.
5. Ha a kategorizálás nem helyes a boltodra, javítsd itt, és ahol a Meta felajánlja, kérj felülvizsgálatot. Ha a kategorizálás helyes, a korlátozás a Meta szabályzati döntése, és minden követőmegoldásra vonatkozik, amit használhatnál, a Meta sajátjára is.
6. Amíg a korlátozás aktív, optimalizáld a kampányokat azokra az eseményekre, amelyeket a Meta még elfogad (például PageView, ViewContent, Search vagy lead-események), és a tényleges bevételi számokhoz használd a bolt jelentéseit, a GA4-et vagy a Pixel Manager pontossági jelentéseit.

A Meta ezeket a korlátozásokat szintekben alkalmazza. A gyakori szint a szabványos konverziós eseményeket (Purchase, AddToCart, Lead és hasonlók) blokkolja, a többit működni hagyja, ami pontosan az itt leírt tünetet adja. A szigorúbb szint a domain minden eseménymegosztását leállítja, ilyenkor még a PageView is eltűnik. A hirdetések közben futhatnak és jóváhagyottak maradhatnak, ezért olyan könnyű a blokkolást elromlott követésbeállítással összetéveszteni.

Hasznos ellenőrzés: ha a hiányzó események mindenkinél hiányoznak, a saját, reklámblokkoló nélkül leadott tesztvásárlásnál is, és a sikeres események továbbra is működnek, az ok szinte sosem az oldalon van. Érdemes korán ellenőrizni, valahányszor egy érzékeny ágazatú bolt azt jelzi, hogy „a pixel csak oldalmegtekintéseket követ”: egyetlen pillantás a pixelkonfiguráció restrictedEventNames mezőjére kizárja vagy igazolja, és napokat spórol, amelyeket egy nem létező bővítmény-, téma- vagy hozzájárulás-problémára kereséssel töltenél.