Gyakori kérdések: általános

Mi az az új „opt-in” funkció a bővítményben? Mibe kell beleegyezni?

Telemetriát gyűjtünk azoktól a felhasználóktól, akik hajlandók megosztani néhány adatot, például a WooCommerce, a WordPress és a PHP verzióját vagy a bolt nyelvét. Ez segít a bővítmény fejlesztési ütemtervének jobb priorizálásában. Például nemrég fordításokon dolgoztunk, és nem tudtuk, melyek a legfontosabbak (a legtöbb felhasználóval rendelkezők), mert a WordPress.org tára erről nem ad sok adatot.

Ha segíteni szeretnél, bekapcsolhatod, de teljesen önkéntes, és semmilyen módon nem változtatja meg a bővítmény működését.

A bolt hátterében furcsán jelennek meg az admin oldalak, és a felugró ablakok nem záródnak be. Hogyan javítsam?

Valószínűleg valamilyen szkript- vagy reklámblokkoló aktív. Kapcsold ki, és a problémák megszűnnek. Általában a blokkolót csak az adott oldalra (a WooCommerce hátteredre) lehet kikapcsolni.

A bővítmény követőpixeleket szúr be a WooCommerce-boltok front endjére. Ennek következtében a Pixel Manager szkriptjei felkerültek egyes adatvédelmi szűrőlistákra. Az ötlet az, hogy a szkriptek ne fussanak le, ha a bolt látogatója reklámblokkolót használ, és meglátogatja a bolt front endjét. A bolt front endjén ez teljesen rendben van. Probléma viszont az olyan adminoknak, akiknek böngészőjében blokkoló van bekapcsolva, és meglátogatják a bolt hátterét. Sajnos nincs módunk arra, hogy a szkriptjeinket általánosan engedélyeztessük minden blokkolóban a WooCommerce háttérre. Ezért azt ajánljuk a bolt adminjainak, hogy zárják ki a saját boltjukat a böngészőjük blokkolójából.

A bővítmény beállításainak megnyitásakor egy figyelmeztetés villan fel, ami fél másodperc után eltűnik. Mi ez?

Ritkán blokkolják azokat a szkripteket, amelyekkel a beállítóoldalt megjelenítjük. Ezekkel a szkriptekkel tesszük gyorsabbá és hasznosabbá a felületet. Nélkülük a beállítóoldal borzalmasan nézne ki. A szkriptek blokkolásának oka egyes felhasználók böngészőjébe telepített reklám- és szkriptblokkolók.

A figyelmeztetést csak azoknak szánjuk, akiknek aktív szkriptblokkolójuk van. Az egyetlen módszer, amit eddig találtunk a szkriptblokkoló észlelésére, ez: az első lépésben a figyelmeztetést mindenkinek kiírjuk az oldal HTML-forrásába, a második lépésben pedig egy szkripttel elrejtjük. Ez a második lépés csak azoknál működik, akiknek nincs szkriptblokkolójuk. Ez a legbiztonságosabb mód, hogy a figyelmeztetést biztosan lássák a szkriptblokkolót használók. Egy hátránya van: ha a szerver kicsit lassú, a szkriptblokkoló nélküli felhasználóknál a szkriptek lassan töltődnek be, és fél másodpercig eltarthat, mire a figyelmeztetés elrejtődik.

Ha ez történik veled, nyugodtan figyelmen kívül hagyhatod a figyelmeztetést, mert azt jelenti, hogy nem fut szkriptblokkoló, és minden helyesen jelenik meg.

Nem működik az elutasítás (dismiss) gomb. Miért?

Valamilyen reklám- vagy szkriptblokkolót használsz a böngészőben. Blokkolja a Pixel Manager azon szkriptjét, amely az értesítés elutasításáért felel. A lehetőségeid:

• Átmenetileg kapcsold ki a böngésző reklám- vagy szkriptblokkolóját, majd utasítsd el az értesítést.
• Vedd fel a szkriptjeinket a blokkoló engedélylistájára.
• Válts másik reklám- vagy szkriptblokkolóra. Nem mindegyik blokkolja a szkriptjeinket.

Az engedélylistára vételt ajánljuk, mert a szkriptekre a bővítmény beállítóoldalán is szükség van.

Felmerülhet, miért pont a mi szkriptjeinket blokkolja a blokkoló. Az ok az, hogy a Pixel Manager segít a konverziók követésében különböző hirdetési platformokhoz. A reklámok blokkolása mellett sok reklámblokkoló szolgáltató azokat a szkripteket is blokkolja, amelyek a látogatók és konverziók követését segítik. Mivel sok szolgáltató nem tudja megkülönböztetni, hogy a szkripteket a front endre vagy a hátterre használják, egyszerűen a háttéren is blokkolják őket, ami a most tapasztalt problémát okozza. Jelentős időt fordítottunk arra, hogy a Pixel Managert eltávolíttassuk a reklám- és szkriptblokkolókból. Egyes esetekben sikerült, másokban nem.

Miért látok ERR_BLOCKED_BY_ORB vagy ERR_BLOCKED_BY_CLIENT hibákat a böngészőmben?

Ezek a hibák általában azt jelentik, hogy egy böngészőbővítmény (például reklámblokkoló vagy adatvédelmi eszköz) beleavatkozik egy szkriptbe vagy erőforrásba az oldalon. A hibák:

• ERR_BLOCKED_BY_CLIENT
• ERR_BLOCKED_BY_ORB
• net::ERR_BLOCKED_BY_CSP
• net::ERR_BLOCKED_BY_RESPONSE
• net::ERR_FAILED

Ezek akkor fordulnak elő, ha a kliensoldalon valami (a böngésző vagy a bővítményei) blokkol egy kérést, amelyet az oldal megpróbál elküldeni. Próbáld ki ezeket:

1. Nyisd meg az oldalt inkognitó módban. (A legtöbb bővítmény ott alapból ki van kapcsolva.)
2. Kapcsold ki az összes bővítményt, majd töltsd újra az oldalt.
3. Kapcsold be őket egyenként, hogy megtaláld a blokkolót.

Látok egy dupla Facebook Purchase eseményt pmw_<véletlen>_<hosszúszám> eseményazonosítóval. Honnan jön?

Ezt a duplát a Meta saját fbevents.js fájlja váltja ki, nem a Pixel Manager. A Meta Events Manager „Track Events Automatically Without Code” funkciójából jön (automatikus eseményészlelésnek, mikroadat-eseményeknek vagy következtetett eseményeknek is hívják). Ha a funkció be van kapcsolva, az fbevents.js a PageView után rövidesen átvizsgálja az oldal strukturált adatait, és elküldi a saját további Purchase eseményét, amelyhez az oldalon legutóbb látott eseményazonosítóhoz belső számlálót fűz.

A Pixel Manager saját Purchase eseményazonosítója pmw_<rendelés_azonosító> formátumú (például pmw_145741). Bármely pmw_<16 véletlen karakter>_<hosszú szám> mintájú azonosítót (például pmw_xq9m1b4a3uqdcc61_26495490706760077) a Meta generál, nem a Pixel Manager.

Az ajánlott javítás: kapcsold ki a Track Events Automatically Without Code beállítást a Meta Events Manager → a pixeled → Settings részen. A teljes hibaelhárítás a diagnózis lépéseivel és egy kódalapú alternatív javítással a Meta (Facebook) hibák fejezetben van.

Ha már kikapcsoltad, és még mindig látsz duplákat, az ok szinte biztosan a Meta saját fbevents.js követőkönyvtárának külön, szakaszos hibája, nem az automatikus eseményészlelés. Egy perc alatt megerősítheted: töltsd be a megerősítő oldalt az URL-hez fűzött ?fbevents-version=2.9.84 paraméterrel. Ha a dupla megszűnik, a Pixel Managernek van PHP-szűrője, amely véglegesen ehhez a régebbi könyvtárverzióhoz rögzít. A lépések és a szűrő kódja ugyanabban a fejezetben vannak.

Milyen beállításokat kell módosítanom a Meta Events Managerben, ha a Pixel Managert használom?

Hármat, és csak hármat. Kapcsold ki az Automatic events beállítást, soha ne használd az Event setup tool eszközt vagy a Set up the selected events for me gombot, és kapcsold le a Meta Conversions API Gateway-ét, ha csatlakoztatva van. Ezek azok a beállítások, amelyek lehetővé teszik a Metának az események önálló gyűjtését, azok mellett, amelyeket a Pixel Manager már megfelelő eseményazonosítókkal és helyes értékekkel küld, és mindegyik olyan konverziókat eredményez, amelyeket a Meta nem tud deduplikálni.

Az Automatic Advanced Matching bekapcsolva maradhat, és a mikroadat-beállítás (Automatically include more detailed page and product info) sem befolyásolja a konverzióid pontosságát. Amíg az Events Managerben vagy, érdemes átnézni a Settings → Integrations részt is, és eltávolítani azokat a kapcsolatokat, amelyeket már nem futtatott követőbővítmények hagytak hátra. A teljes listát a Meta Events Manager beállításai fejezetben találod.

A Meta csak PageView és ViewContent eseményeket kap. Az AddToCart, InitiateCheckout és Purchase hiányzik. Miért?

Ha az oldalmegtekintések megérkeznek a Meta Events Managerbe, de a kosárba tétel, a pénztár és a vásárlás eseményei soha, és sehol nincs hibaüzenet, az ok nagy valószínűséggel nem a weboldalad. A Meta blokkolja a konverziós eseményeket azoknál a pixeleknél, amelyek olyan üzleti kategóriához tartoznak, amelyet érzékenynek tekint, leggyakrabban az egészség és wellness: 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, tesztkészletek és hasonló boltok.

Korlátozott pixelnél a Meta saját fbevents.js könyvtára bármely követőeszköztől elfogadja az AddToCart vagy Purchase hívást, majd elküldés előtt eldobja. Nincs kérés a facebook.com/tr felé, és nincs hiba a konzolban. A Conversions API sem kerüli meg, mert a Meta a korlátozást az adatforrásra alkalmazza, nem a szállítás módjára.

Néhány másodperc alatt megerősítheted: nyisd meg a böngészőben a https://connect.facebook.net/signals/config/<pixel_id> címet, és keresd a restrictedEventNames szót. Az ott lévő nem üres lista pontosan megnevezi a Meta által blokkolt eseményeket. A Pixel Manager ezt is ellenőrzi helyetted, és megnevezi a blokkolt eseményeket a böngészőkonzolban és a hibakeresési jelentésben a Meta Business Category Event Restrictions alatt.

A javítás a Meta oldalán van, az Events Managerben a pixeled Settings részén, a Manage data source categories és a Manage event blocking alatt. A teljes diagnózis, a kontrollteszt és a megoldás lépései a Meta (Facebook) hibák fejezetben vannak.

Másik Meta (Facebook) bővítményt használtam, és a „Receive the same event_id for many events” hibát kapom. Előfordul ez ennél a bővítménynél is?

A Meta (Facebook) CAPI és más Meta-bővítmények használatakor előfordulhat, hogy az alábbi hibák egyikébe ütközöl:

• „Deduplication not set”
• „Receive the same event_id for many events”
• „Event Purchase not deduplicated”

Ez akkor történik, ha a böngészőoldali és a szerveroldali eseményazonosítók nem egyediek minden eseményre. A Pixel Manager ezt helyesen kezeli: minden eseményhez egyedi eseményazonosítót hoz létre, ezért ezzel a problémával nem kell találkoznod a Pixel Managerrel.

Használhatok több Meta (Facebook) pixelt a bővítménnyel?

Röviden: igen, a pmw_facebook_pixel_identifiers szűrővel. De a legtöbb esetben jobb megoldás egyetlen pixel megosztása a hirdetési fiókok között.

Részletesen: a második Meta-pixel leggyakoribb oka, hogy ugyanahhoz a WooCommerce-bolthoz egynél több Meta hirdetési fiókból akarsz kampányokat futtatni. Ehhez általában egyáltalán nincs szükség második pixelre, mert a Meta lehetővé teszi, hogy megoszd a pixelt más Meta hirdetési fiókokkal. A megosztás egy adatforrásban tartja az összes konverziós adatot, az összes egyéni közönséget és az összes tanulást, ezért ez a Meta saját legjobb gyakorlata, és az ajánlásunk is ez marad.

Vannak esetek, amikor a megosztás nem opció: például ha egy médiaügynökséget nem engednek be a Business Managerbe, ha egy partnermárkának saját adatforrás kell, vagy ha egy régi pixelről újra költözöl, és mindkettővel párhuzamosan akarsz adatot gyűjteni. Ezekre az esetekre a Pixel Manager a pmw_facebook_pixel_identifiers szűrőt nyújtja:

• Minden böngészőesemény, minden oldalon, az összes beállított pixelnek megy.
• Minden további pixel saját Conversion API hozzáférési tokent hordozhat, így a szerveroldali események, a vásárlások és az előfizetés-életciklus események is ehhez a pixelhez kerülnek (Pro).
• A további pixelek szinkronizálódnak a Server-Side Proxyval is, ha használod (Szerveroldali követés).

A második pixel néhány sor a gyermektéma functions.php fájljában, a beállításokban maradó fő pixelazonosító mellett:

add_filter('pmw_facebook_pixel_identifiers', function ( $pixel_identifiers ) {
    $pixel_identifiers[] = [
        'pixel_id'   => 'PIXEL_ID_2',
        'capi_token' => 'CAPI_TOKEN_2',
    ];
    return $pixel_identifiers;
});

Ne feledd, hogy minden további pixel megsokszorozza a Metának küldött kérések számát. A második pixel megduplázza a böngészőkéréseket, és ha van Conversion API tokenje, a szerveroldali kéréseket is. Csak azokat a pixeleket add hozzá, amelyekre tényleg szükséged van.

Miért nem küld a Pixel Manager PageView eseményeket a Meta CAPI-nak?

Ha a Meta CAPI be van kapcsolva, a Pixel Manager alapból nem küld PageView eseményeket a Meta CAPI-nak. Az okok:

• A PageView események követése óriási terhelést jelentene a szervernek. Olyan lenne, mintha a szerveren nem lenne gyorsítótár bekapcsolva.
• A kampányok optimalizálásához nem szükséges a PageView-k CAPI-n át követése. A PageView-k többségét a böngészőpixel követi, a Pixel Manager pedig az összes alsó tölcsérbeli eseményt, amelyek fontosak a kampányoptimalizáláshoz, elküldi a CAPI-nak.

A Pixel Manager újabb kiadásai lehetővé teszi a PageView követés bekapcsolását CAPI-n át. A bekapcsolásról az Általános beállítások fejezetben olvashatsz. Ez Pro funkció.

Kikapcsolhatom a böngészőpixelt, és csak a szerveroldali követést (CAPI) használhatom?

Nem, ez nem támogatott.

Hogyan működik a pixel aktiválása: ha hozzáadsz egy pixelazonosítót egy követőpixel-szolgáltatóhoz a Pixel Managerben, a böngészőpixel aktiválódik. Ha a követőpixel szerveroldali követési opciót is kínál (például Meta CAPI, TikTok EAPI stb.), és bekapcsolod, az események mindkét csatornán mennek: a böngészőpixelen és a szerveroldali API-n is.

Miért nem kínálunk lehetőséget a böngészőpixel kikapcsolására a szerveroldali követés megtartása mellett: egyes ügyfelek kérték, hogy a böngészőpixelt a Google Tag Manageren át futtassák, és a Pixel Managerben csak a Conversion API-t használják. Ez a felállás azonban megtörné az események deduplikációját. A hirdetési platformok az event_id alapján azonosítják és deduplikálják a böngészőből és a szerverről kapott eseményeket. A deduplikáció helyes működéséhez ugyanazt az event_id értéket kell elküldeni a böngészőeseménnyel és a szerveroldali eseménnyel is. A Pixel Manager minden eseményhez egyedi event_id értéket állít elő, és mindkét csatornán elküldi, így biztosítja a megfelelő deduplikációt.

Ha a böngészőpixelt egy másik eszköz (például GTM) kezeli, a szerveroldali eseményt pedig a Pixel Manager küldi, minden eszköz saját event_id értéket generál. A hirdetési platform ezeket két különálló eseménynek számolja a deduplikálás helyett, ami felfújt konverziószámokat eredményez. Ezért követeljük meg, hogy szerveroldali követés használatakor a böngészőpixelt és a szerveroldali követést is a Pixel Manager kezelje.

Támogatja a Pixel Manager a Google Tag Managert (GTM)?

Nem, a Pixel Manager közvetlenül nem támogatja a Google Tag Managert (GTM). A Google Tag Manager más követőkód-kezelő, mint a Pixel Manager.

Elméletileg lehetséges a GTM-et a Pixel Manager mellett használni, de nem ajánlott. Az ok az, hogy a GTM nagyon összetett eszköz, amelynek helyes használatához sok tudás kell. Ez igaz magára a GTM-re, és különösen igaz, ha a Pixel Manager mellett használod. Gondoskodnod kell róla, hogy a Google Tag Manager ne zavarja a Pixel Managert, ami mindkét eszköz alapos ismeretét követeli meg.

A másik ok az adatréteg tulajdonlása: a Pixel Manager birtokolja és karbantartja az adatrétegét a kiadások között, így a követés minősége magas marad, miközben a WooCommerce, a pixelek, a böngészők és a hozzájárulási szabályok folyamatosan változnak. A GTM-mel minden konténer egyedi építés, amelyet külön kell karbantartani.

Ha hiányzik valami a Pixel Managerből, amire szükséged van, és szerinted a GTM-mel megoldhatnád, jelezd a támogatásnak. Mindig szívesen adunk hozzá új funkciókat a Pixel Managerhez.

Nem látok e-kereskedelmi eseményeket a dataLayer változóban. Hol tartja az adatait a Pixel Manager?

A Pixel Manager nem használja a Google Tag Manager dataLayer változóját a saját adataihoz. A bolt-, kosár-, termék- és rendelésadatokat a saját adatrétegében tartja: window.pmwDataLayer.

Korábban ezt az objektumot wpmDataLayer néven hívták. A régebbi útmutatók, fórumbejegyzések és módosítási naplók még a régi nevet használják. Elavult, ezért állítsd át az egyedi kódodat, amely még a wpmDataLayer változót olvassa, pmwDataLayer használatára.

A GTM dataLayer csak a Pixel Managerben bekapcsolt Google-pixelek gtag.js parancsait kapja, például a GA4 vagy a Google Ads purchase eseményt. Soha nem kap GTM-stílusú e-kereskedelmi push-okat (event kulcs ecommerce objektummal), ezért egy GTM-eseményindító, amely ilyenre vár, sosem fut le.

Annak ellenőrzéséhez, mit ír ki a Pixel Manager egy oldalon:

1. Nyisd meg a böngészőkonzolt, és írd be: pmwDataLayer. A pmwDataLayer.pmw_loaded értéke true, ha a Pixel Manager betöltődött. A megerősítő oldalon a rendelés a pmwDataLayer.order alatt van.
2. Fűzd az oldal URL-jéhez a ?pmwloggeron paramétert. A konzolnaplózó kiír minden eseményt, amelyet a Pixel Manager elsüt, és azt is naplózza, ha a hozzájárulás blokkol egy pixelt (Konzolnaplózó).

Bekapcsolhatom a Google Analyticset a Pixel Managerben, ha már egy másik alkalmazással használom?

Nem, ne tedd. Ez dupla követéshez és pontatlan adatokhoz vezetne a Google Analyticsben.

Bekapcsolhatok egy követőpixelt a Pixel Managerben, ha már egy másik alkalmazással használom?

Nem, ne tedd. Ez dupla követéshez és pontatlan adatokhoz vezetne az adott hirdetési platformon.

Támogatja a Pixel Manager a Cloudflare Zarazt?

Jelenleg nem. A Pixel Managernek van módja arra, hogy a követési pontosság rovása nélkül jelentősen gyorsítsa az oldalbetöltést: a lusta betöltés funkció (Pro változat) (Általános beállítások). Ezért nincs szükség a Cloudflare Zarazra. Figyelemmel követjük a Cloudflare Zarazt, és a jövőben talán támogatást adunk hozzá.

Használhatom a Pixel Managert egyedi köszönő oldallal?

Ez attól függ, mit erősít meg az oldal, mert a vásárlás és a lead más beállítást igényel.

A vásárlást megerősítő oldalaknak a szabványos WooCommerce order-received végpontot és az is_order_received_page() feltételt kell használniuk. Ezt nem lehet megkerülni: ezen a végponton keresztül tudja meg a Pixel Manager, hogy vásárlás történt és melyik rendelésről van szó, és így olvassa ki a rendelés azonosítóját, értékét, pénznemét és a megvásárolt tételeket, majd adja át a hirdetési platformoknak. Az egyedi köszönő oldalakat kínáló bővítmények többsége követi a WooCommerce specifikációit, ezért alapból működnek.

Ha a bővítményed vagy egyedi kódod nem követi a WooCommerce specifikációit, a Pixel Manager nem fog működni vele, és az egyedi köszönő oldalt a specifikációk megvalósításával kell kijavítanod. Az egyszerű WordPress-oldal, amelyre a vásárlókat a pénztár után átirányítják, nem felel meg a specifikációknak, és semmi sem, ami elirányít a megerősítő oldalról.

Ha ellenőrizni akarod, hogy az egyedi köszönő oldalad követi-e a WooCommerce specifikációit és működik-e a Pixel Managerrel, kövesd a Diagnosztika és tesztelés fejezetben leírt tesztelési eljárást.

A másik eset az olyan köszönő oldalak, amelyek nem rendelést erősítenek meg. Az az oldal, amelyre egy kapcsolatfelvételi űrlap, érdeklődő űrlap, regisztráció vagy hírlevél-feliratkozás irányít, mögött nincs WooCommerce-rendelés, ezért a fenti végpont nem vonatkozik rá. Helyezz el ezen az oldalon egy követő shortcode-ot (Shortcode-ok: lead és egyedi konverziók), és az elsüti a bekapcsolt platformok konverziós pixeleit.

A shortcode-ok nem kerülőmegoldások arra a vásárlást megerősítő oldalra, amely nem követi a WooCommerce specifikációit. A shortcode rendeléssel kapcsolatos adat nélkül süti el a konverziót (nincs rendelésazonosító, rendelési érték, pénznem vagy megvásárolt tétel), és a rendelésduplikáció-védelem nélkül. Az így követett vásárlás érték nélkül érkezne a hirdetési platformokra, és az oldal minden újratöltésekor újra számolódhatna.

Mely Pixel Manager szkripteket és útvonalakat kell kizárnom a gyorsítótárból vagy az optimalizálásból?

Általában egyiket sem. Az oldal gyorsítótárazása a tervezésből adódóan támogatott, és a Pixel Manager automatikusan regisztrálja a szükséges JavaScript-optimalizálási kizárásokat a WP Rocket, a LiteSpeed Cache, a SiteGround Optimizer, az Autoptimize, a WP-Optimize, az Optimocha és a FlyingPress számára.

Ha az optimalizálód nem tartozik ezek közé (a leggyakoribb a NitroPack), zárd ki a bővítménymappát (woocommerce-google-adwords-conversion-tracking-tag az ingyenes, pixel-manager-pro-for-woocommerce vagy woocommerce-pixel-manager a Pro változathoz) a JavaScript-minifikálásból és -összevonásból, zárd ki az inline pmwDataLayer szkriptet az inline JS-optimalizálásból, és ne késleltesd a Pixel Managert az első interakcióig a kosár-, pénztár- és megerősítő oldalon.

A teljes lista konkrét fájlnevekkel, helyettesítő mintákkal, végpontokkal és szolgáltatóspecifikus lépésekkel a Gyorsítótár és optimalizálás: kizárások fejezetben van.

Az optimalizáló bővítményem támogatja a szkriptek lusta betöltését. Azt használjam, vagy a Pixel Manager belső szkript-lusta betöltését?

Az ajánlás: kapcsold be a lusta betöltést mindkettőben, az optimalizáló bővítményedben és a Pixel Managerben is, és zárd ki a Pixel Manager szkriptjét az optimalizáló bővítmény lusta betöltéséből. Ennek eredményeképp az összes harmadik féltől származó szkriptet az optimalizáló bővítmény tölti be lustán, míg a Pixel Manager a saját funkcióinak lusta betöltését maga kezeli.

Miért kapcsold be mindkettőben, aztán miért zárd ki a Pixel Managert az optimalizálóban? A Pixel Manager lusta betöltési logikájában több fejlesztés van. Az egyik optimalizálás, hogy a Pixel Manager a lehető legnagyobb követési pontosság érdekében automatikusan kikapcsolja a lusta betöltést a kosár- és pénztártölcsérben. Ezek olyan oldalak, ahol a követésnek mindig azonnal be kell töltődnie. Egy másik optimalizálás, hogy automatikusan kikapcsolja a lusta betöltést, ha A/B-tesztelő eszközök aktívak a Pixel Managerben. Az érvényes tesztredményekhez az A/B-tesztelő eszközöket mindig azonnal kell betölteni, nem késleltetve.

Ha WP Rockettet használsz, mindkettőben bekapcsolhatod a lusta betöltést anélkül, hogy kézzel ki kellene zárnod a Pixel Managert a WP Rocket lusta betöltéséből. A Pixel Manager automatikusan kizárja magát a WP Rocket lusta betöltéséből.

Miért nem tárolja a Pixel Manager helyben a követőszkripteket?

Gondos elemzés után arra jutottunk, hogy nincs haszna a követőszkriptek (például a Google Analytics) helyi tárolásának. Mindent figyelembe véve a követőszkriptek helyi tárolása hátrányos a felhasználói élményre.

Az az ígéret él, hogy a követőszkriptek helyi tárolása előnyös lenne a sebesség, a gyorsítótárazás és a sebességmérő eszközök (Google PageSpeed Insights, GT Metrix stb.) jobb pontszámai szempontjából. Pontról pontra az elemzés:

• Gyorsítótárazás a weboldal első oldalbetöltésekor. Helyi tárolásnál minden látogató böngészőjének le kell töltenie a szkriptet a te szerveredről. CDN-nél a látogató böngészőjének csak akkor kell letöltenie a szkriptet a CDN-ről, ha még nincs a böngésző gyorsítótárában, ahol már lehet egy korábban meglátogatott, ugyanazt a követőszkriptet tartalmazó weboldalról. Következtetés: nagyon valószínű, hogy a látogatók böngészték a webet, mielőtt elérték az oldaladat, ezért a CDN használata sokkal valószínűbben gyorsít. Sok, ha nem a legtöbb esetben a szkript már a böngésző gyorsítótárában van.
• Gyorsítótárazás a második oldalbetöltésnél. Helyi tárolásnál a böngésző a gyorsítótárból veszi a szkriptet, de ez csak akkor működik, ha a beállítás helyes. Kis esély van rá, hogy a fejlesztő nem állította be helyesen a szkript tárolását, és a böngésző minden oldalbetöltésnél letölti a szkriptet. CDN-nél a böngésző a gyorsítótárból veszi a szkriptet. Következtetés: mindkét módszer a gyorsítótárból veszi a szkriptet, de a CDN-ek általában jobban megtervezettek, ami csökkenti a hibás konfiguráció kockázatát, amely kikapcsolná a böngésző gyorsítótárát.
• A legfrissebb verzió gyorsítótárazása. Helyi tárolásnál a fejlesztőnek logikát kell építenie a legfrissebb verzió rendszeres letöltésére a CDN-ről. Ez bonyolultságot ad, ami elromolhat. Attól függően, milyen gyakran történik, a szervered elavult követőszkript-verziót is kiszolgálhat. CDN-nél a CDN mindig a legfrissebb verziót szolgálja ki. Következtetés: a CDN javára.
• Gyorsítótárazás általában. Ha gyors weboldalt akarsz, nagy eséllyel használsz valamilyen gyorsítótárréteget. A gyorsítótárrétegek általában a helyben tárolt szkripteket a CDN-gyorsítótárrétegükbe töltik, és az elavult követőszkriptet sokkal tovább őrzik. Ráadásul a felhasználók böngészőinek először innen kell letölteniük a szkriptet az első látogatáskor. A webhelyek közötti CDN-gyorsítótár csak akkor működik, ha a követőszkript-szolgáltató CDN-jét használod.
• Sebesség. Helyi tárolásnál a szkript letöltését a szervered sávszélessége korlátozza. CDN-nél a CDN sávszélessége. A CDN-ek sokkal nagyobb sávszélességgel rendelkeznek, és a CDN használata tehermentesíti a saját szerveredet is.
• Sebességmérő eszközök. A sebességmérő eszközök, például a PageSpeed Insights, fej nélküli böngészővel, üres gyorsítótárral tesztelnek. Ez azt jelenti, hogy úgy tesztelnek, mintha az oldalad lenne az első, amit a látogató megnyit a böngészőjében. Ez önmagában különleges eset, mert a legtöbb esetben a látogató már böngészett más oldalakat, és valószínűleg már megvan a követőszkript a böngésző gyorsítótárában. Ezért a CDN-módszer itt is kedvezőbb. Van egy mód, amellyel megtéveszthetők a sebességmérő eszközök, és jelentősen javíthatók a pontszámok: olyan JavaScript-optimalizáló használata, amely minden szkriptet csak az oldal első felhasználói interakciója után tölt be. Ennek viszont hátránya a látogatókövetés pontosságának kismértékű romlása.

Összegzés: használd tovább a szkriptek CDN-változatát. A helyi tárolás technikailag könnyű és nem venne sok időt, de meggyőződésünk, hogy a követőszkript-CDN-ek használata sokkal jobb a weboldal-tulajdonosoknak.

Meta (Facebook) Poor Event Match Quality

Ha a Meta (Facebook) Business Managerben ezt a figyelmeztetést látod, ne aggódj. Nem probléma. A Meta ilyen esetben félrevezetett. Az okok:

• Böngészőazonosító (fbp): az fbp csak akkor állítható be, ha a böngésző betölti a Meta-pixelt. Egyes látogatók reklám- vagy követésblokkolót használnak, amely megakadályozza a Meta-pixel betöltését. Ezért ez a százalék nem lehet 100%.
• Kattintásazonosító (fbc): az fbc csak akkor kerül beállításra, ha a látogató egy Meta-hirdetésre kattint. Ha a látogató nem kattint Meta-hirdetésre, az fbc nem állítható be. Ha nem minden látogatód érkezik Meta-hirdetésre kattintva a weboldaladra, ez a százalék nem lehet 100%. Lényegében annyira magas, mint a Meta-hirdetési kattintásokból érkező forgalom.
• Külső azonosító (External ID): a külső azonosító csak akkor állítható be, ha a látogató be van jelentkezve a boltba. A Pixel Manager nem tudja megállapítani, ki a látogató, ezért nem tudja beállítani a külső azonosítót. Ezért ez a százalék nem lehet 100%.

A Pixel Manager Pro változata lehetővé teszi a Meta (Facebook) Advanced Matching funkciójának bekapcsolását is. Bekapcsolva a Pixel Manager több azonosítót küld a Metának, például keresztnevet, vezetéknevet, e-mail-címet stb. Ez növeli az egyezési minőséget. Gondoskodnod kell azonban róla, hogy az adatvédelmi szabályzatod engedje ezeknek az adatoknak a Metának küldését.

Pinterest Poor Event Match Quality

Ha a Pinterest hirdetéskezelőjében ezt a figyelmeztetést látod, ne aggódj. Általában nem probléma.

• Jelentési időszak: a jelentési időszak 14 nap. Ha nemrég kapcsoltad be a Pinterest-pixelt a Pixel Managerben, akár 14 napig is eltarthat, mire a Pinterest megmutatja a pontos egyezési minőséget.
• Külső azonosító (External ID): a külső azonosító csak bejelentkezett látogatónál áll rendelkezésre. A külső azonosító lényegében a látogató WordPress-felhasználói azonosítója. Ha a látogató nem jelentkezik be a böngészés előtt, a Pixel Manager nem tudja az azonosítót, ezért nem küldhető el, és ezért figyelmen kívül hagyhatod az alacsony lefedettségről szóló figyelmeztetést.
• E-mail: a külső azonosítóhoz hasonlóan az e-mail-cím csak akkor küldhető el, ha az adat rendelkezésre áll. Ez akkor van, ha a látogató be van jelentkezve, vagy a megerősítő oldalon, ha a látogató megadta az e-mail-címét. Ha az e-mail-cím nem kötelező mező a pénztárban, csak akkor kerül elküldésre, ha a látogató önként megadta.
• Kattintásazonosító: a kattintásazonosító csak akkor kerül beállításra, ha a látogató egy Pinterest-hirdetésre kattint. Ha nem kattint, a Pinterest-süti nem olvasható. Ha nem minden látogatód érkezik Pinterest-hirdetésre kattintva, ez a százalék nem lehet 100%. Lényegében annyira magas, mint a Pinterest-hirdetési kattintásokból érkező forgalom.
• PageVisit: a Pixel Manager két okból nem küld Conversion API eseményeket a PageVisit eseményekhez. Lényegében megkerülné a gyorsítótárazás minden fajtáját, értelmetlenné téve a gyorsítótárat, ami nem a legjobb irány. A konverzióoptimalizáláshoz a PageView események értéke nagyon kicsi. Ezért ezeknek a szerveroldali követése sem sok értelmet nyer (és a böngészőpixel követi őket). Lásd még „Miért nem küld a Pixel Manager PageView eseményeket a Meta CAPI-nak?”.

Mely domaineket kell engedélyeznem a Content Security Policyben (CSP), hogy a Pixel Manager működjön?

Ha Content Security Policyt (CSP) használsz, az alábbi domaineket kell engedélyezned a Pixel Manager működéséhez:

• myexternalip.com
• ipify.org
• cloudflare.com
• geojs.io
• ipinfo.io
• ipapi.co

A Pixel Manager ezeket a szolgáltatásokat használja a látogató IP-címének és helyének meghatározására bizonyos körülmények között. Például ha a Pixel Manager úgy van beállítva, hogy csak bizonyos régiókban blokkolja a pixeleket, a látogató helyét meg kell határoznia, és el kell döntenie, hogy a pixeleket blokkolja-e.

Aktívan kell tartanom a Meta (Facebook) CAPI tesztesemény-kódját?

Nem. Eltávolíthatod, miután sikeresen kipróbáltad a Meta (Facebook) CAPI-t. Megtarthatod is, nem árt. Csak arra kell ügyelned, hogy újabb tesztnél frissítsd a tesztesemény-kódot. A Facebook megköveteli a tesztesemény-kód frissítését körülbelül 24 óra után (a Facebook nem ad pontos időkeretet).

Kompatibilis a Pixel Manager a HPOS-szal (High Performance Order Storage)?

Igen.

Mely követőpixelek vannak az ingyenes változatban?

Az ingyenes változat tíz platform böngészőpixelét telepíti:

• Google Ads
• Google Analytics 4
• Meta (Facebook)
• Microsoft Ads (Bing) UET-címke, a Microsoft Ads Consent Mode-dal együtt
• TikTok
• Pinterest
• Snapchat
• Reddit
• OpenAI (hirdetések a ChatGPT-n)
• Hotjar

Mindegyik a teljes vásárlási tölcsért követi, a termékmegtekintésektől a kosárba tételen és a pénztáron át a vásárlásig, rendelésazonosítóval, értékkel és tételsorokkal. Amit az ingyenes változat ezeknél a platformoknál nem tartalmaz, az a szerveroldali fél: a Conversions API és az Events API kapcsolatok, az Advanced Matching, az Enhanced Match és az Enhanced Conversions a Pro változat része.

A Pro változat további 19 pixelt ad hozzá: AB Tasty, AdRoll, Contentsquare, CrazyEgg, Criteo, GroundTruth, Hyros, Klaviyo, LinkedIn, Microsoft Clarity, Mixpanel, Nextdoor, Optimizely, Outbrain, Spotify, Taboola, Triple Whale, VWO és X (Twitter).

A TikTok, Microsoft Ads, Pinterest, Snapchat, Reddit és OpenAI böngészőpixelek újabban kerültek az ingyenes változatba. Előtte csak Pro-ban voltak. A részleteket lásd a Funkciók fejezetben.

Meg kell tartanom az ingyenes változatot, ha a Pixel Manager for WooCommerce (Premium) változata telepítve van?

Nem. A Pro (Premium) változat teljesen önállóan fut, és nem igényli az ingyenes változatot. Miután a Pro változatot telepítetted és aktiváltad, nyugodtan kikapcsolhatod és eltávolíthatod az ingyenes változatot. Az ingyenes változat telepítve hagyása sem árt, de nincs rá szükség.

Mely hozzájárulás-kezelő platformokat (CMP) támogatja a Pixel Manager?

Minden CMP működik a Pixel Managerrel, amely megfelelően megvalósítja a Google Consent Mode-ot, és a CMP-k hosszú listáját a bővítmény automatikusan felismeri és integrálja, beállítás nélkül. A teljes táblázat a PMW pontszámmal platformonként a Hozzájárulás-kezelés: platformok fejezetben van. Külön útmutatók, ajánlott beállításokkal és hibaelhárítási lépésekkel, léteznek a Cookiebothoz, a Cookie Scripthez, a CookiePro by OneTrusthoz, az iubendához, a Complianzhoz és a CookieYes-hez. Az összes CMP-integráció az ingyenes változatban is megvan. A Borlabs Cookie és a Real Cookie Banner nem támogatott.

Kompatibilis a CookieYes a Pixel Managerrel?

Igen. A CookieYes támogatott CMP, az ingyenes és a Pro változatban is, akár a CookieYes WordPress-bővítményt telepíted, akár a CookieYes-t a CookieYes konzolból tölted be. A Pixel Manager beállítás nélkül olvassa a CookieYes hozzájárulási sütijét, és reagál a hozzájárulásfrissítési eseményére. Ha az admin kártya „None detected” üzenetet mutat, bár a CookieYes aktív, valószínűleg a konzolszkriptet futtatod, amelyet a kártya nem lát, miközben az áruházi integráció működik. A CookieYes útmutató az ajánlott beállításokat és a hibaelhárítási lépéseket tartalmazza (Hozzájárulás-kezelés: CookieYes).

A Pixel Manager sütijeinek listája és besorolása

A friss kiadásokban minden süti, amelyet a Pixel Manager beállít, pmw_ előtaggal kezdődik. Ez a lista dokumentációs célra és a hozzájárulás-kezelő platformok szolgáltatóival való integrációhoz használható.

Süti neve	Cél	Besorolás	Időtartam	A szerver olvassa
pmw_consent	A látogató hozzájárulási választását tárolja (marketing, statisztika, és hogy a látogató döntött-e), hogy minden rendelés rögzítse a látogató aktuális hozzájárulását, akkor is, ha a fizetési szolgáltató később, a látogató böngészője nélkül erősíti meg a fizetést. Nem tartalmaz azonosítót. Pro.	Szükséges	Munkamenet	Igen
pmw_click_ids	A vásárláshoz vezető látogatás hirdetési kattintásazonosítóit tárolja (például gclid, fbclid, ttclid), hogy a szerveroldali konverziókövetés a rendelést a hirdetéskattintáshoz tudja rendelni. Csak a Pixel Managerben beállított hirdetési platformokhoz kerül beállításra, és csak azután, hogy a látogató megadta a marketinghozzájárulást. Pro. Részletek: Funkciók: Click ID.	Marketing	90 nap	Igen
pmw_gtg_handler	Megjegyzi, hogyan van kiszolgálva a Google Tag Gateway az oldalon, hogy a szerver a Google-címkét a helyes útvonalról töltse be anélkül, hogy minden oldalon tesztelné. Csak akkor kerül beállításra, ha a Google Tag Gateway be van állítva.	Szükséges	7 nap	Igen
pmw_automatic_conversion_recovery	Az automatikus konverzió-visszaállítás rendelésazonosítóját és rendeléskulcsát tárolja, amely olyan vásárlást követ, amelynek fizetési átjárója sosem mutatta a megerősítő oldalt. Pro.	Szükséges	90 nap	Nem
pmw_cookie_consent	A hozzájárulási API-n át beállított hozzájárulási állapotot tárolja (Hozzájárulás-kezelés: API). Csak akkor kerül beállításra, ha az API-hívás átad duration értéket; egyébként az állapot a _pmw_persistent_data alatt marad.	Szükséges	Az átadott duration napokban	Nem

Böngészőtárolás, amely süti formájában is tartalékot kaphat

A Pixel Manager az alábbi adatokat általában a böngésző sessionStorage és localStorage tárolójában tartja, amelyek nem sütik. Csak ha a böngésző nem kínál tárolót, ugyanezeket az adatokat egyező nevű sütibe írja. A szerver soha nem olvassa őket.

Név	Cél	Besorolás	Időtartam sütiként
_pmw_session_data	Az aktuális látogatás adatai, például a belépő oldal kattintásazonosítói	Szükséges	Munkamenet
_pmw_session_data_cart	A kosáradatokat követi	Szükséges	Munkamenet
_pmw_persistent_data	A látogató hozzájárulási beállításait tárolja a sütikategóriákra (statisztika, marketing, preferenciák, szükséges), és az anonimizált rendelésazonosítókat, amelyek megakadályozzák, hogy a vásárlást kétszer kövessék	Szükséges	400 nap

Átnevezett sütik

Régebben két süti aláhúzással kezdődött. Ha a sütinyilatkozatod felsorolja őket, cseréld az új nevekre:

Régi név	Új név
_pmw_click_ids	pmw_click_ids
_pmw_automatic_conversion_recovery	pmw_automatic_conversion_recovery

Azok a látogatók, akik még a régi sütit hordozzák, nem veszítenek semmit: a Pixel Manager beolvassa, tartalmát az új névre mozgatja, és eltávolítja a régit.

Tárhelyek, amelyek eltávolítják a sütiket

A pmw_consent, a pmw_click_ids és a pmw_gtg_handler sütit a szerver olvassa, ezért egyetlen szabály a pmw_ előtagra mindet lefedi. Ha a tárhelyed eltávolítja az általa nem ismert sütiket, mielőtt a kérés eléri a WordPresst, ahogy a Pantheon alapból, lásd a Gyorsítótár és optimalizálás: kizárások fejezet „Tárhelyek, amelyek eltávolítják a sütiket” részét.

A legtöbb Pixel Manager-sütit a szkriptje írja a látogató böngészőjében. A szerver is írja a pmw_click_ids sütit, és a pmw_automatic_conversion_recovery sütit saját maga írja.

Süti neve	Ki írja	Secure	HttpOnly	SameSite
pmw_consent	Böngésző	HTTPS-oldalakon	Nem	Nincs beállítva (a böngésző alapértelmezése)
pmw_click_ids	Böngésző és szerver	HTTPS-oldalakon. A szerver akkor állítja be, ha a WordPress HTTPS-t észlel	Nem	Nincs beállítva (a böngésző alapértelmezése)
pmw_gtg_handler	Böngésző	HTTPS-oldalakon	Nem	Nincs beállítva (a böngésző alapértelmezése)
pmw_automatic_conversion_recovery	Szerver	Mindig	Nem	Strict
pmw_cookie_consent és a tárolótartalék-sütik	Böngésző	HTTPS-oldalakon	Nem	Nincs beállítva (a böngésző alapértelmezése)

Egyik sem lehet HttpOnly. A böngésző csak a szervertől fogad el HttpOnly sütit, és elrejti a szkriptek elől, miközben a Pixel Manager szkriptje ezeket a sütiket írja vagy olvassa. A HttpOnly erőltetése, például szerverszabállyal, megtörné a hozzájárulás-kezelést és a követést.

PCI-vizsgálati megállapítások. A PCI-megfelelőségi vizsgálatok gyakran felsorolnak minden sütit, amelyből hiányzik a Secure vagy HttpOnly attribútum. Ezek az ellenőrzések azokat a sütiket védik, amelyek bejelentkezést vagy munkamenetet hordoznak, mert egy ellopott süti lehetővé teszi a támadónak a fiók átvételét. Egyetlen Pixel Manager-süti sem tartalmaz bejelentkezést, munkamenet-azonosítót vagy fizetési adatot. A friss kiadás óta az ilyen megállapítás Secure része HTTPS-boltokon megoldott. A HttpOnly esetében a legtöbb vizsgálati szolgáltató elfogad dokumentált kivételt az ilyen nem érzékeny hozzájárulási és követési sütikre, ezért kérj kivételt a vizsgálati szolgáltatódtól, és hivatkozz erre a részre.