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

> Szűrők a szerveroldali vásárlási események kihagyására és módosítására, a böngészős konverzió visszatartására, előfizetések és visszatérítések kezelésére, valamint a szerveroldali kérések beállítására.

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.

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

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

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

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

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

```php
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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/diagnosztika-es-tesztelles/), í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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/fejlesztoknek-receptek-statuszvezerelt-vasarlas/) 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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/fejlesztoknek-receptek-statuszvezerelt-vasarlas/) 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é.

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

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

```php
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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/fejlesztoknek-esemenyszurok/)), 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.

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

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

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

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

```php
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).

```php
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](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/fejlesztoknek-naplok/)) 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).

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

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

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

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

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

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