# Meta (Facebook) hibák

> Figyelmeztetések és eltérések a Meta Events Managerben: érvénytelen egyezési kulcsok, dupla Purchase, Event Setup Tool szabályok, Conversions API Gateway, események hiánya és blokkolt üzleti kategória.

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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/pixelek-meta-events-manager/) 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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/hozzajarulas/)).

## 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:

```php
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:

```php
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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/altalanos/) 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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/hozzajarulas/) 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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/funkciok-acr/) 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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/szerveroldal/)) 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é:

```js
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.