PHP-szűrők: szerveroldali küldés és rendelések

Ez a fejezet azokat a szűrőket gyűjti össze, amelyek a szerveroldali eseményeket (Conversion API-k, Measurement Protocol, SweetCode Cloud proxy) és a rendelések kezelését érintik. A szűrőket a gyermektéma functions.php fájljába tedd.

Előfizetés-megújítások követésének kikapcsolása az összes pixelnél

A pmw_subscription_renewal_tracking szűrő megakadályozza, hogy a Pixel Manager jelentse a WooCommerce Subscriptions megújítási rendeléseit, minden pixelen.

A megújítás ugyanolyan kifizetett WooCommerce-rendelés, mint bármelyik másik, ezért alapból úgy jelentik, mint bármely más eladást: minden aktív szerveroldali integráció vásárlási eseményt kap róla. A legtöbb bolt ezt akarja, mert a megújítás valódi bevétel. Az a bolt, amely a jelentéseit inkább a megszerzéshez köti, és a vásárlót egyszer számolja, nem havonta, kikapcsolhatja.

add_filter('pmw_subscription_renewal_tracking', '__return_false');

Tedd a téma functions.php fájljába vagy egy kódrészlet-bővítménybe, ne késői hookra. A Meta Conversions API a szűrőt az előfizetés-hookok regisztrálásakor olvassa, ami a kérés korai szakaszában történik. A régebbi változatok a szűrőt csak a Meta Conversions API-ban és a GA4 Measurement Protocolban olvasták, ezért a megújítások rendes vásárlásként tovább eljutottak a Google Adshez, a TikTokhoz, a Pinteresthez, a Snapchathez, a Reddithez, az OpenAI-hoz, a Nextdoorhoz, a Microsoft Advertisinghoz és a Mixpanelhez.

Amit a szűrő kikapcsol:

• a szerveroldali vásárlási esemény minden platformnak
• a Meta RecurringSubscriptionPayment életciklus-eseménye
• a kézi megújítás böngészős konverziója: az ilyet a pénztáron át fizetik, ezért az automatikus megújítással ellentétben eljut a rendelés-megerősítő oldalra, és különben elsütné a böngészőpixeleket
• az Automatic Conversion Recovery, amely különben éppen azokat a konverziókat szerezné vissza, amelyeket most kikapcsoltál

Amit érintetlenül hagy:

• a kezdeti előfizetési rendelést, amely továbbra is normál vásárlásként sül el minden pixelen
• a Meta Subscribe és CancelSubscription életciklus-eseményeit
• a Google Ads konverziómódosítási adatforrást, amely továbbra is visszavonja a lemondott vagy visszatérített megújítást. A Google Ads által nem párosítható módosítást figyelmen kívül hagyja, a visszatartása viszont olyan konverziót hagyna állva, amelyet a szűrő hozzáadása előtt már jelentettek

A Google Analytics előfizetés-megújítás követésének kikapcsolása

A megújításokat kiveszi a Google Analytics 4-ből, miközben a hirdetési platformok továbbra is megkapják őket.

add_filter('pmw_google_analytics_subscription_renewal_tracking', '__return_false');

A visszatérítések követik a vásárlásokat: az a megújítás, amelyet nem jelentenek, refund eseményt sem kap, így a Google Analyticstől sosem kérik olyan bevétel visszavonását, amelyet nem kapott meg. Az a megújítás, amelyet a szűrő hozzáadása előtt jelentettek, megtartja a visszatérítését, így nem marad állva bevétel. A régebbi változatokon a szűrő csak a megújítást jelentő utak egyikét kapuzta, ezért a megújítások a szokásos vásárlási úton így is eljutottak a Google Analyticshez.

A Facebook CAPI előfizetés-megújítás követésének kikapcsolása

A megújításokat kiveszi a Metából, miközben a többi platform továbbra is megkapja őket.

add_filter('pmw_facebook_subscription_renewal_tracking', '__return_false');

Ez azt a két utat is lefedi, amelyen egy megújítás a Metához jut: a megújítási rendelés Purchase eseményét és a RecurringSubscriptionPayment életciklus-eseményt. A kezdeti rendelés Subscribe eseményét és a CancelSubscription eseményt nem érinti. A régebbi változatokon a szűrőnek nem volt hatása, amíg a Purchase Proxy aktív volt, mert a megújítás-ellenőrzés azon az úton nem ismerte fel a megújítást.

A Google Analytics visszatérítés-követés kikapcsolása

A GA4 Measurement Protocol beállítva minden visszatérítést refund eseményként jelent a Google Analyticsnek, így a tulajdonság bevétele korrigálódik. Ezeket az eseményeket a WooCommerce adminból küldi a bővítmény, napokkal a vásárló látogatása után, ezért nincs munkamenetük, és a Google Analytics a visszavont bevételt „(not set)” alatt jeleníti meg.

A pmw_google_analytics_refund_tracking szűrővel a visszatérítési eseményeket teljesen kikapcsolhatod.

add_filter('pmw_google_analytics_refund_tracking', '__return_false');

Figyelem: Kikapcsolt visszatérítési eseményekkel a Google Analytics által jelentett bevétel a visszatérített összegekkel túlbecsült marad. Csak akkor használd, ha a tiszta attribúciós jelentés többet ér neked, mint a helyes bevételi szám.

Ha a legtöbb rendelésnél meg akarod tartani a visszatérítéseket, és csak néhánynál akarod kihagyni, az adatcsomagot szűrd. A visszatérítési adatcsomagok a szerveroldali eseményszűrő láncon refund eseménynéven mennek át, ezért a null visszaadása egyetlen visszatérítési eseményt blokkol:

add_filter('pmw_server_event_payload_google_analytics_refund', function ($payload, $pixel_name, $event_name) {
    if (isset($payload['events'][0]['params']['value']) && $payload['events'][0]['params']['value'] < 10) {
        return null;
    }
    return $payload;
}, 10, 3);

A böngészős vásárlási konverzió elnyomása egyes rendeléseknél

A pmw_conversion_prevention szűrővel megakadályozhatod, hogy a Pixel Manager elsüsse a böngészős vásárlási konverziót egy adott rendelésnél. A true visszaadása visszatartja a rendelés adatait az adatrétegből a rendelés-megerősítő oldalon, ami azt jelenti, hogy egyetlen böngészőpixel sem süt el vásárlási eseményt arra a rendelésre: sem a Google Ads, sem a Meta, sem a Google Analytics, egyik sem. A szűrő az ingyenes és a Pro változatban is elérhető.

A szűrő két argumentumot kap:

Argumentum	Típus	Leírás
$prevent	bool	Elnyomja-e a konverziót. Alapértelmezett: false.
$order	WC_Order	A rendelés, amelyre a megerősítő oldalt elérték.

Mit fed le, és mit nem

• Csak a böngészős vásárlási konverziót érinti. A szerveroldali vásárlási események a rendelési státuszváltásokra futnak, és külön kapuzottak: azok elnyomásához használd a pmw_skip_s2s_purchase_event szűrőt.
• Kiegészíti azokat az ellenőrzéseket, amelyeket a Pixel Manager amúgy is elvégez. A failed, cancelled vagy refunded státuszú rendelések, és a követésből kizárt felhasználói szerepkörök látogatásai soha nem váltanak ki vásárlási konverziót.
• Mivel egyetlen pixel sem sül el, a Pixel Manager nem írja a rendelésre a kettőzésmegelőzési jelölést. A rendelés ezért jogosult marad az Automatic Conversion Recovery (Pro) helyreállítására, és ettől működik az alábbi halasztási minta.

A konverzió halasztása, amíg a rendelést ki nem fizetik

A szűrő leggyakoribb használata olyan fizetési mód, amely a rendeléseket pending payment (fizetésre vár) státuszban hozza létre, és a fizetést később erősíti meg: banki átutalás, számla, kézi ellenőrzés vagy egyedi fizetési mód. A vásárló ettől még eljut a rendelés-megerősítő oldalra, ezért a böngészős vásárlási konverzió elsül egy olyan rendelésre, amelyet esetleg sosem fizetnek ki.

Úgy írd meg a szűrőt, hogy a rendelés aktuális státuszát értékelje, és ne nyomja el kapásból a fizetési módot. Az ACR a vásárló következő bolti látogatásakor ugyanezt a szűrőt újra kiértékeli, így amint a rendelés kifizetett státuszba ér, a szűrő false értéket ad, és a teljes vásárlási konverzió, a Google Ads konverziót is beleértve, visszaszerződik.

add_filter('pmw_conversion_prevention', function ($prevent, $order) {
    if (!$order instanceof WC_Order) {
        return $prevent;
    }

    // Csak az egyedi fizetési módot érinti
    if ($order->get_payment_method() !== 'my_custom_gateway') {
        return $prevent;
    }

    // Visszatartás, amíg a rendelés nem kifizetett státuszú
    if (!in_array($order->get_status(), wc_get_is_paid_statuses(), true)) {
        return true;
    }

    return $prevent;
}, 10, 2);

Vigyázat: Az elnyomást tedd a rendelés státuszától függővé, mint a fenti példában. Az a szűrő, amely feltétel nélkül true értéket ad egy fizetési módra, véglegesen eldobja a konverziót, mert a rendelés a helyreállításra sem lesz jogosult.

Az így visszaszerzett rendelések az ACR oszlopban jelennek meg a Fizetési mód pontossági jelentésben, így ellenőrizheted, hogy a halasztás működik, és nem vész el csendben a konverzió.

A halasztott konverzió követelményei és korlátai

A helyreállítási fél az ACR-től függ, ezért érvényesek a követelményei: a vásárlónak ugyanazzal a böngészővel vissza kell térnie a boltba, miután a rendelés kifizetett státuszba ért. Ha ez sosem történik meg, a konverzió egyáltalán nem rögzül.

Azoknál a platformoknál, amelyeknek van szerveroldali megfelelőjük a Pixel Managerben, inkább a Státuszvezérelt vásárlási konverziók receptet használd. Az a vásárlást a platform Conversion API-ján át irányítja, amely magán a kifizetett státuszba váltáskor sül el, és nem kér visszatérő látogatást. A Google Adsnek nincs szerveroldali vásárlási API-ja a Pixel Managerben, ezért a Google Ads konverzióihoz a fenti szűrő és az ACR együtt az elérhető út.

A szerveroldali vásárlási események kihagyása egyes rendeléseknél

A pmw_skip_s2s_purchase_event szűrővel megakadályozhatod, hogy a Pixel Manager szerveroldali vásárlási eseményt sütsön el egyes rendelésekre (Pro). A true visszaadása minden szerveroldali platformra kihagyja a vásárlási eseményt: Facebook CAPI, TikTok Events API, Pinterest Conversions API, Snapchat CAPI, Reddit CAPI, Microsoft Advertising CAPI, Nextdoor, Mixpanel, OpenAI, Spotify, Klaviyo és a GA4 Measurement Protocol, a SweetCode Cloud (SSP) proxy útvonalat is beleértve. A rendelés ki van zárva a Google Ads konverziómódosítási CSV-adatforrásból is, így később nem küldhető RETRACT vagy RESTATE módosításként.

Mit kapuz a szűrő

A szerveroldali vásárlási esemény a következő rendelési státuszváltásokra van regisztrálva:

• woocommerce_payment_complete
• minden woocommerce_order_status_{kifizetett státusz} váltás, ahol a kifizetett státuszokat a wc_get_is_paid_statuses() adja, alapból processing és completed
• woocommerce_order_status_on-hold

Az on-hold kiváltó szándékos: azok a fizetési módok, amelyek a rendelést fizetésre várva parkoltatják, különben napokkal későn jelentenék a konverziókat, a hirdetési platformok pedig büntetik a késő jelentést. Két következmény:

• Az a rendelés, amely csak on-hold állapotban van, vásárlást küld, bár fizetés nem érkezett.
• A nulla értékű rendelés is küld. A payment_complete() függvényen át kifizetett státuszba jut, és ezen az úton semmi nem vizsgálja a végösszeget.

Ez a szűrő a támogatott mód ennek szűkítésére, például a nullánál nagyobb összegű kifizetett rendelésekre. A teljes mintát, a böngészős oldalt is beleértve, a Státuszvezérelt vásárlási konverziók recept tartalmazza.

A kihagyott rendelést a bővítmény nem jelöli elküldöttnek, ezért a vásárlás egy későbbi váltáskor még kimegy, ha a rendelés eléri a kifizetett státuszt. A szűrő tehát kapu, nem végleges kizárás.

A szűrő három argumentumot kap:

Argumentum	Típus	Leírás
$skip	bool	Kihagyja-e a vásárlási eseményt. Alapértelmezett: false.
$order	WC_Order	A WooCommerce-rendelés.
$context	string	A pixelosztály neve (például SweetCode\Pixel_Manager\Pixels\Facebook\Facebook_CAPI) vagy conversion_adjustments_feed.

Gyakori felhasználás: a programozottan importált piactéri rendelések (Amazon, eBay stb.) kizárása, amelyeknek nem szabad konverzióként számítaniuk. A következő példa kihagyja az összes szerveroldali vásárlási eseményt a magnalister bővítmény által importált rendeléseknél. A magnalister minden importált rendelés vevői megjegyzését a magnalister-Verarbeitung szöveggel kezdi, ami a forrás piactértől függetlenül egyszerű illesztést tesz lehetővé.

add_filter('pmw_skip_s2s_purchase_event', function ($skip, $order, $context) {
    if (strpos((string) $order->get_customer_note(), 'magnalister-Verarbeitung') === 0) {
        return true;
    }
    return $skip;
}, 10, 3);

Egy adott platformot a $context argumentum ellenőrzésével célozhatsz meg:

use SweetCode\Pixel_Manager\Pixels\Facebook\Facebook_CAPI;

add_filter('pmw_skip_s2s_purchase_event', function ($skip, $order, $context) {
    if ($context === Facebook_CAPI::class && $order->get_payment_method() === 'some_gateway') {
        return true;
    }
    return $skip;
}, 10, 3);

A régebbi változatokon a szerveroldali vásárlási útvonal a Pixel Manager belső rendelésobjektumát adta át ennek a szűrőnek, ezért az instanceof WC_Order őrrel kezdődő visszahívás csendben semmit nem csinált, a WC_Order típust előíró pedig a kérést végzetes hibával állította le. Ez javítva van egy újabb kiadásban.

A szerveroldali vásárlási adatcsomag módosítása

A szerveroldali vásárlásokat a WooCommerce-rendelésből építi a bővítmény, nem a böngészőből továbbítja, ezért a pmw_server_event_payload_* lánc sosem látja őket. Ez a két szűrő minden célhely vásárlási adatcsomagján lefut, közvetlenül a küldés előtt, a közvetlen küldésnél és a SweetCode Cloud útvonalon is (Pro):

• pmw_server_purchase_payload a $payload, $destination és $order értékekkel, minden célhelyre
• pmw_server_purchase_payload_{destination} a $payload és $order értékekkel, egy célhelyre

A $destination értéke: facebook, tiktok, pinterest, snapchat, reddit, openai, nextdoor, bing, google_ga4, google_dma, mixpanel, klaviyo, spotify vagy applovin. Az adatcsomag az adott platform saját API-formátumában van, pontosan úgy, ahogy elküldenék.

add_filter('pmw_server_purchase_payload_facebook', function ($payload, $order) {
    $payload['custom_data']['shipping_method'] = $order->get_shipping_method();
    return $payload;
}, 10, 2);

A szűrők a vásárlást módosíthatják, de nem dobhatják el: az a visszahívás, amely nem üres tömbtől eltérőt ad vissza, figyelmen kívül marad, és a szűretlen adatcsomag kerül elküldésre. Vásárlás megállításához használd a pmw_skip_s2s_purchase_event szűrőt.

A vásárlás böngészős másolatát külön építi a bővítmény. Ha olyan mezőt adsz hozzá, amelyet a platform a böngészős eseménnyel is kettőzésmentesít, add hozzá ott is a JavaScript pmw_pixel_data_{pixel} szűrővel (lásd: Eseményszűrők), hogy mindkét másolat ugyanazokat az értékeket hordozza.

A „Mindig küldj szerveroldali eseményeket” szűkítése egyes célhelyekre

A Always send server-side events egyetlen kapcsoló minden szerveroldali célhelyre. Bekapcsolva a rendelést akkor is elküldi, ha a látogató elutasította az érintett hozzájárulási kategóriát. Ez gyakran az, amit a bolt a Conversions API célhelyeitől akar, egy másiktól viszont nem (Pro).

A pmw_s2s_always_send_override szűrővel célhelyenként döntheted el. Ha egy célhelyre false értéket adsz vissza, arra ismét a hozzájárulási kapu érvényes, a többi célhely pedig tovább küld, ahogy addig.

A szűrő három argumentumot kap:

Argumentum	Típus	Leírás
$applies	bool	Vonatkozik-e erre a célhelyre a mindig küldés felülírása. Alapértelmezett: true.
$order	WC_Order	A WooCommerce-rendelés.
$context	string	A pixelosztály neve, például SweetCode\Pixel_Manager\Pixels\Google\Google_DMA.

Két dolgot nem tesz. Nincs hatása, amíg a Always send server-side events ki van kapcsolva, mert akkor a hozzájárulási kapu mindenhol amúgy is érvényes. És nem dönt azokról a rendelésekről, amelyekhez nincs hozzájárulási pillanatkép, például admin rendelésekről vagy piactéri importokról: ezeket alapból elküldi, és a külön pmw_s2s_require_consent_snapshot szűrő szabályozza őket.

A példa a Metát, az OpenAI-t és a többit minden rendelés fogadásán tartja, és csak a Google Ads konverziófeltöltést zárja ki azoknál a vásárlóknál, akik elutasították a marketing-hozzájárulást.

use SweetCode\Pixel_Manager\Pixels\Google\Google_DMA;

add_filter('pmw_s2s_always_send_override', function ($applies, $order, $context) {
    if ($context === Google_DMA::class) {
        return false;
    }
    return $applies;
}, 10, 3);

Vigyázat: Ez a hozzájárulási szabályzatodról szóló döntés, nem műszaki beállítás, ezért azzal hozd meg, aki a szabályzat felelőse. Azt is vedd figyelembe, hogy a Google Ads konverziófeltöltés minden feltöltésnél, a adUserData és adPersonalization hozzájárulási jeleken át, a látogató tényleges választását közli a Google-lel, így a marketinget elutasító vásárló rendelése elutasítottként jelölve érkezik meg, és a Google ezt a saját oldalán alkalmazza.

A Google Ads konverziómódosítási adatforrás sorainak szűrése

A pmw_conversion_adjustments_feed_row szűrővel kizárhatod vagy módosíthatod a Google Ads konverziómódosítási CSV-adatforrás (a lemondott rendelésekből és visszatérítésekből épülő RETRACT / RESTATE adatforrás) egyes sorait (Pro).

Üres érték (null, false vagy []) visszaadásával kihagyhatsz egy sort az adatforrásból. A sor mezőit is módosíthatod: a Pixel Manager utána újra alkalmazza a saját ellenőrzését (a negatív értékeket 0-ra korlátozza, érvényesíti a Google oszlopsorrendjét), így az adatforrás mindig a Google előírásán belül marad.

Ez az ajánlott mód az adatforrás testreszabására. A pmw_skip_s2s_purchase_event szűrővel ellentétben csak az adatforrást érinti, így nincs kockázata, hogy véletlenül elnyomod az éles szerveroldali vásárlási eseményeidet.

A szűrő három argumentumot kap:

Argumentum	Típus	Leírás
$row	array	A sor asszociatív adatai (a kulcsokat lásd alább).
$order	WC_Order	A módosított rendelés.
$type	string	A módosítás forrása: cancelled vagy refund.

A $row tömb kulcsai:

Kulcs	Leírás
order_id	A rendelésszám, amellyel a Google az eredeti konverziót párosítja.
conversion_name	A beállított konverzió neve.
adjustment_time	ISO 8601 időbélyeg, például 2026-06-25T13:00:00+00:00.
adjustment_type	RETRACT vagy RESTATE.
adjusted_value	Az új rendelésérték (csak RESTATE-nél, RETRACT-nál üres).
currency	A pénznem kódja (csak RESTATE-nél).

Példa: csak a Google Ads-kattintásból érkezett rendelések módosításait küldd

A következő példa kihagyja az összes olyan rendelést, amelynek nincs Google Ads kattintásazonosítója. A Pixel Manager a kattintásazonosítót a rendelésen _wpm_gclid néven tárolja, amikor a vásárló eléri a rendelés-megerősítő oldalt. A piactérről (Amazon, eBay stb. a Channable, M2E Cloud, magnalister és hasonló integrátorokon át) importált rendelések soha nem érik el azt az oldalt, ezért kattintásazonosítójuk sincs, és ki lesznek hagyva.

add_filter('pmw_conversion_adjustments_feed_row', function ($row, $order) {
    if (empty($order->get_meta('_wpm_gclid', true))) {
        return null;
    }
    return $row;
}, 10, 2);

Figyelem: Az adatforrás szűrése csökkenti a zajt a Google Ads naplóiban, de az adatok pontosságát nem javítja, sőt csökkentheti. A Google az Enhanced Conversions (kivonatolt e-mail és telefonszám) révén olvasható kattintásazonosító nélkül is párosít konverziókat. Azoknak a rendeléseknek nincs helyi _wpm_gclid értéke, ezért a kattintásazonosító-szűrő eldobja a jogos RETRACT / RESTATE módosításaikat, és a Google tovább számolja az eredeti, de már lemondott vagy visszatérített konverziót. A Google saját dokumentációja szerint a „ez a konverzió nem létezik” válaszok nyugodtan figyelmen kívül hagyhatók. Azt javasoljuk, hogy tölts fel minden módosítást, és hagyd figyelmen kívül ezeket a figyelmeztetéseket. A szűrőt csak akkor használd, ha a naplókat akarod elcsendesíteni, nem a konverziók pontosságának javítására.

Egyedi rendelési folyamatok megjelölése kézi (backend) rendelésként

A pmw_is_backend_manual_order szűrővel megtaníthatod a Pixel Managert az olyan egyedi rendelésletrehozási folyamatokra (B2B árajánlatból rendelés, push-cart, rendelés fizetése stb.), amelyek nem állítják be a _created_via = 'admin' értéket, és nem váltják ki a WooCommerce Order Attribution funkciót (Pro). Ha a rendelést backend-kézinek ismeri fel, a Pixel Manager a rendelés-megerősítő oldalon újra rögzíti a vásárló böngészőazonosítóit, hogy a szerveroldali vásárlási események a valódi vásárlói környezetet hordozzák, ne legyenek üresek, és ne az őket létrehozó munkatársnak tulajdonítódjanak.

A szűrő két argumentumot kap:

Argumentum	Típus	Leírás
$is_backend_manual	bool	Backend-kézinek tekinti-e már a Pixel Manager ezt a rendelést.
$order	WC_Order	A vizsgált WooCommerce-rendelés.

Példa: megjelöl minden olyan rendelést, amelyet egy egyedi árajánlat-bővítmény hozott létre, és amely az eredetét rendelési metában tárolja.

add_filter('pmw_is_backend_manual_order', function ($is_backend_manual, $order) {
    if ($order->get_meta('_my_quote_plugin_origin') === 'staff_quote') {
        return true;
    }
    return $is_backend_manual;
}, 10, 2);

A Pinterestnek küldött külső azonosító szűrése

A Pinterest Conversions API fogad egy external_id értéket, amely egy állandó azonosító, és lehetővé teszi, hogy a Pinterest a vásárló eseményeit munkamenetek és eszközök között összekösse. A Pixel Manager a regisztrált vásárlónál a kivonatolt WordPress-felhasználóazonosítót, a vendégnél a kivonatolt e-mail-címet küldi, mert a legtöbb bolt a rendeléseinek zömét vendégektől kapja (Pro).

A szűrő megkapja az értéket, amelyre a Pixel Manager jutott, és az esemény mögötti teljes felhasználói adatobjektumot, így más azonosítót helyettesíthetsz be, vagy üres szöveg visszaadásával elhagyhatod a mezőt.

add_filter('pmw_pinterest_external_id', function ($external_id, $user_data) {
    return '';
}, 10, 2);

Figyelem: A Pinterest ezt az értéket SHA-256-tal kivonatolva várja. Ha saját azonosítót helyettesítesz be, magad kivonatold, mielőtt visszaadod.

A szerveroldali HTTP-kérések argumentumainak módosítása

A szűrő azt az argumentumtömböt módosítja, amelyet a Pixel Manager a WordPress HTTP API-nak ad át a szerveroldali API-hívásokhoz. Használd lassú hálózaton az időkorlát növelésére, fejléc hozzáadására, vagy helyi környezetben a TLS-ellenőrzés kikapcsolására (Pro).

A szűrő a közvetlen platform-API-hívásokat fedi le: a Meta, a TikTok, a Pinterest, a Snapchat, a Reddit, a Microsoft, a Nextdoor és az OpenAI Conversion API-jait, a Google Analytics Measurement Protocolt, valamint a Mixpanel és a Triple Whale API-ját. A SweetCode Cloud proxyn át irányított kérések nem mennek át ezen az osztályon.

add_filter('pmw_http_post_request_args', function ($args) {
    $args['timeout'] = 10;
    return $args;
});

Az alapértékek: 5 másodperces időkorlát, HTTP 1.0, nem blokkoló kérések, és TLS-ellenőrzés mindenhol, kivéve a localhostot. Amit visszaadsz, az az alapértékekre rétegződik, ezért részleges tömb is elég.

Figyelem: A blocking az egyetlen argumentum, amelyet békén kell hagynod. A Pixel Manager az eseményeit nem blokkolva küldi, hogy egy lassan válaszoló platform-API ne lassíthassa a pénztárat. Ha a blocking értéke true, minden esemény teljes körútja abba a kérésbe kerül, amelyre a vásárlód vár. Ha hibakeresésre kell, használd a lentebb leírt pmw_send_all_s2s_requests_blocking szűrőt, amely pontosan erre való, és könnyebb megtalálni, amikor el akarod távolítani.

Várakozás a platform válaszára a szerveroldali kéréseknél

A szűrő a szerveroldali API-hívásokat blokkolóvá teszi, így a Pixel Manager megvárja az egyes platformok válaszát, ahelyett hogy elküldené a kérést és továbblépne. Ez hibakeresési kapcsoló, nem beállítás (Pro).

add_filter('pmw_send_all_s2s_requests_blocking', '__return_true');

Alapból a szerveroldali események nem blokkolva mennek ki: a WordPress átadja a kérést a hálózati rétegnek, és azonnal visszatér, így egy lassan válaszoló platform nem tarthatja fel az oldalt vagy a pénztárat, amelyre a vásárló vár. Ennek az az ára, hogy a boltban semmi nem látja a választ. Ha azt nyomozod, miért nem kap egy platform eseményt, éppen erre van szükséged.

A HTTP-kérések naplózója (lásd: Naplók) magától blokkolóra állítja a kéréseket, mert amíg a válasz meg nem érkezik, nincs mit leírnia. Akkor használd ezt a szűrőt, ha a naplózó nélkül akarod a blokkoló viselkedést, például miközben hibakeresővel lépkedsz a kódban, vagy ha a saját naplózásod a WordPress HTTP API-n ül.

Figyelem: Vedd ki, ha végeztél. A HTTP-kérések naplózója erre való tekintettel magától kikapcsol, ennek a szűrőnek nincs ilyen biztonsági hálója. Éles boltban benne hagyva minden vásárlás a beállított platform-API-k körútját hozzáadja ahhoz az időhöz, amelyet a vásárló a rendelés-megerősítő oldalra várva tölt.

A Meta Conversion API eseményeinek kivétele a hirdetéskézbesítésből

A szűrő beállítja a Meta opt_out jelzőjét a szerveroldali eseményeken, ami azt mondja a Metának, hogy az eseményeket mérésre és attribúcióra használja, de a hirdetéskézbesítés optimalizálására ne (Pro).

add_filter('pmw_facebook_capi_ads_delivery_opt_out', '__return_true');

A jelző a Pixel Manager által küldött összes Conversion API eseményre be van állítva, a vásárlásra is. Ez a Meta saját dokumentált kapcsolója, és szabályozott területeken működő boltoknál néha kötelező.

A Google Tag Gateway üzemeltetési szűrői

Négy szűrő a Google Tag Gatewayhez. Az alapértékek szinte minden boltnak megfelelnek, ezek arra az esetre vannak, amikor nem.

A kezelő rögzítése

A Pixel Manager felismeri a legjobb elérhető gateway-kezelőt, és a döntést 24 órára gyorsítótárazza. Adj vissza external (a CDN-proxy, például Cloudflare), standalone (a bővítmény önálló PHP-proxyja) vagy wordpress (a WordPressen át irányítva) értéket a felismerés kihagyásához.

add_filter('pmw_gtg_handler', function () {
    return 'standalone';
});

Bármely más visszaadott érték, a null is, a felismerésnél hagyja a döntést. Ezt akkor használd, ha egy CDN-beállítás összezavarja a felismerést, vagy ha egy kezelőt a helyén akarsz tartani, amíg a CDN-nél módosítasz valamit. Az állapotellenőrzés továbbra is azt jelenti, amit a rögzített kezelő ténylegesen csinál.

A proxyzott szkriptek böngészős gyorsítótár-ideje

A proxy azt mondja a böngészőnek, hogy a Google-címke szkriptjeit 6 órára gyorsítótárazza. Csökkentsd hibakeresés közben, vagy növeld, hogy kevesebb kérés érje a szervert.

add_filter('pmw_google_tag_gateway_cache_duration', function ($seconds) {
    return 12 * HOUR_IN_SECONDS;
});

Az érték másodpercben van, és csak a gyorsítótárazható JavaScript-válaszokra érvényes. A mérési kéréseket soha nem gyorsítótárazza.

A felsőbb szintű kérés időkorlátja

A proxy 5 másodpercet ad a Google-nek a válaszra, mielőtt feladja, és a böngésző a Google saját CDN-jére esik vissza.

add_filter('pmw_gtg_proxy_request_timeout', function ($seconds) {
    return 8;
});

Lassú kimenő kapcsolatú tárhelyen emeld meg. A megemelés azt is jelenti, hogy egy elakadt felsőbb szintű kérés tovább foglal egy PHP-munkást, ezért ne emeld túl sokat.

Kérésszám-korlátozás

A proxy kérésszám-korlátozása alapból ki van kapcsolva, mert az éles boltok CDN mögött vannak, amely már korlátoz, és a Google is korlátozza a saját végpontjait. Kapcsold be olyan boltnál, amelynek egyik sincs.

add_filter('pmw_gtg_proxy_enable_rate_limiting', '__return_true');
add_filter('pmw_gtg_proxy_rate_limit_max_requests', function ($max_requests, $client_ip) {
    return 250;
}, 10, 2);

Mindkét szűrő megkapja a kliens IP-jét is, így egy irodai vagy megfigyelő IP-nek külön felső korlát adható.

Figyelem: Az a felső korlát, amely túl alacsony, eldobja a valódi mérési kéréseket, az eldobott kérés pedig elveszett konverzió. Kezdd magasról, és csak számok birtokában csökkentsd.

SSP további domainek (több domain támogatása)

Ez a szűrő megköveteli, hogy a Server-Side Proxy aktív legyen az elsődleges domaineden.

Ha egyetlen WordPress-telepítésed több domaint szolgál ki (WordPress Multisite nélkül), a szűrővel mindegyik domaint a saját SSP proxy végpontjához kötheted. Ez akkor hasznos, ha egyetlen WooCommerce-bolt több domainnéven is elérhető.

Hogyan működik:

1. Állítsd be a Server-Side Proxyt az elsődleges domainedre a szokásos módon, a Pixel Manager beállításain át.
2. A SweetCode Cloud portálon hozz létre új domainbejegyzést minden további domainhez, és másold ki a szinkron-tokent.
3. Add hozzá az alábbi szűrőt a gyermektéma functions.php fájljához.

A Pixel Manager ezután automatikusan:

• minden domainen a látogatóknak a megfelelő SSP proxy URL-t és ellenőrző tokent írja ki,
• a CAPI-célhelyek beállításait minden további domain SSP végpontjára feltölti,
• minden domaint szinkronban tart, valahányszor módosítod a pixelbeállításokat, vagy a napi szinkronizálási ütemezés szerint.

add_filter('pmw_ssp_additional_domains', function ($domains) {
    $domains[] = [
        'sync_token'     => 'ssp_tok_xxxxxxxxxxxx',      // a SweetCode Cloud portálról
        'proxy_hostname' => 'ssp.otherdomain.com',       // az SSP proxy hosztneve
        'shop_origin'    => 'https://otherdomain.com',   // a WordPress-oldal eredete
    ];
    return $domains;
});

Az egyes domainbejegyzések paraméterei:

Paraméter	Leírás
sync_token	A domain szinkron-tokenje a SweetCode Cloud portálról. Minden domainnek saját, egyedi tokenje van.
proxy_hostname	A teljes SSP proxy hosztnév (például ssp.otherdomain.com). Egyeznie kell a SweetCode Cloudban létrehozott domainnel.
shop_origin	A domainen futó WordPress-oldal teljes eredet-URL-je, a protokollal együtt (például https://otherdomain.com). Pontosan egyeznie kell azzal, ami a böngésző címsorában látszik.

Figyelem: A további domainek kezdeti beállításfeltöltése a következő napi szinkronnál történik, vagy kézzel indíthatod a Pixel Managerben a Server-Side → SweetCode Server-Side Proxy oldalról. A szűrő hozzáadása után indíts szinkront, hogy a további domainek azonnal aktiválódjanak.

Tipp: A Pixel Manager beállítófelülete csak az elsődleges SSP domain állapotát mutatja. A további domainek helyes szinkronját a SweetCode Cloud portálon ellenőrizheted: ott látható minden domain szinkronállapota, útválasztási állapota és eseménytevékenysége.