# Bolt beállításai

> A rendelés marketingértéke, haszonkövetés, kettőzés megelőzése, dinamikus remarketing, előfizetések és az ügyfél életre szóló értéke.

A WooCommerce-hez kötődő beállítások a **WooCommerce → Pixel Manager → General** fülön vannak, a **WooCommerce** címke alatt.

![A General fül a bolt beállításaival](./kepek/elso-lepesek-bolt-beallitasok.webp)

*A General fül a bolt beállításaival* (https://minta-bolt.hu/wp-admin/admin.php?page=pmw)

Figyelj az **Order configuration**, a **Product data**, a **Subscriptions**, a **Customer lifetime value** és az **Extra order data output** kártyákra.

## Marketing value logic

Ez a beállítás szabja meg, mekkora összeget kapnak a marketingpixelek (Google Ads, Facebook Ads és a többi). A statisztikai pixelek, például a Google Analytics, mindig a teljes kosárértéket kapják adóval és szállítással együtt. A beállítás az **Order configuration** kártyán van.

### Order subtotal (alapértelmezett)

Csak a termékbevételt jelenti. A rendelés összegéből kihagyja a szállítási költséget és az adót, levonja a kedvezményeket, a visszatérítéseket és, ha elérhető, a fizetésfeldolgozók (PayPal, Stripe) díját.

- A pótdíjak (rendelési díjak, például ajándékcsomagolás, utánvételi felár, kis rendelés díja, előleg részlete) nem részei az értéknek. Nem is vonódnak le, mert a WooCommerce rendelési részösszege eleve csak a termékeket tartalmazta. Ha a pótdíjat bevételként is jelenteni akarod, a marketing konverziós érték szűrővel add hozzá, vagy válaszd az **Order total** opciót.
- A fizetésfeldolgozói díj más: azt a szolgáltató tartja vissza a kifizetésből, a vevő nem fizeti meg, ezért levonódik.
- A visszatérítés a termékekre eső részével csökkenti az értéket. A kizárólag szállításra vagy díjra vonatkozó visszatérítés nem változtat az értéken. A WooCommerce tételenként vagy sima összegként is enged visszatérítést. A sima összegnél a bővítmény nem tudja, melyik rész ment vissza, ezért az egészet a termékekre számolja, és az érték alacsonyabb lehet. Ha pontos értéket akarsz, tételenként térítsd vissza.

### Order total

Azt az összeget jelenti, amit a vevő fizetett, a szállítással és az adóval együtt.

### Profit margin (Pro)

A bővítmény kiszámolja a rendelés árrését, és azt küldi a marketingpixeleknek. A termékbevételből kiindulva levonja az egyes termékek beszerzési költségét, a kedvezményeket, a visszatérítéseket és a fizetésfeldolgozói díjakat. Minden érték nettó, és a termék sorokból származik: az adó, a szállítás, az ajándékcsomagolási díj, az utánvételi felár és az előleg nincs benne.

A beállításhoz aktív beszerzési költség (COGS) forrás kell az alábbiak egyikéből:

- a WooCommerce beépített COGS-funkciója (**WooCommerce → Beállítások → Speciális → Funkciók → Cost of Goods Sold**, külön bővítmény nélkül),
- WooCommerce Cost of Goods (SkyVerge),
- Cost of Goods for WooCommerce (WPFactory),
- vagy egyéni postmeta mező (lásd lent).

**A szállítás mindkét oldalon kimarad, a fuvarozói költséged is.** A WooCommerce azt rögzíti, mennyit számláztál a vevőnek szállításért, azt viszont nem, mennyit számlázott neked a fuvarozó, ezt a bővítmény nem tudhatja. Ha a szállítás pénzbe kerül, a jelentett árrés ennyivel magasabb, a díjmentes szállítású rendeléseknél még magasabb. A szállítási nyereséget a shipping profit szűrővel adhatod meg nettó értékekkel (a bruttó fuvarozói díj rendelésenként ugyanannyival hibás).

**Ha egy terméken nincs beszerzési költség,** a bővítmény nullát használ, vagyis a termék teljes bevételét csendben haszonnak jelenti. A `Profit_Margin::order_has_complete_cogs()` függvénnyel megtudhatod, hogy egy rendelés érintett-e.

**Visszatérítésnél** a visszaküldött tételek beszerzési költsége hozzáadódik az árréshez a visszatérített bevétel mellett. Ehhez a visszatérített mennyiség kell, amit a WooCommerce csak tételenkénti visszatérítésnél rögzít. Sima összegű visszatérítésnél a teljes összeg levonódik az árrésből, ami alacsonyabb értéket ad.

#### Honnan jön a termék költsége

A bővítmény sorban megkérdezi az aktív forrásokat, és az első megtalált költséget használja. Az inaktív forrást sosem olvassa, így egy kikapcsolt bővítményben maradt költség nem használódik tovább. Minden termék sornál a sorrend:

1. A rendelés soron tárolt költség, azaz a rendeléskori költség. A WooCommerce beépített COGS-a a sorösszeget tárolja (`_cogs_value`, egységköltség × mennyiség), a bővítmények az egységköltséget (`_wc_cog_item_cost` a SkyVerge-nél, `_alg_wc_cog_item_cost` a WPFactory-nál).
2. A terméken tárolt költség, a források saját API-ján át lekérdezve. A beépített COGS-nál ez azt is eldönti, hogy egy variáció örökli-e a szülő költségét, vagy hozzáad.
3. A termék postmetája tartalékként, ha a forrás aktív, de az API-ja nem érhető el: `_cogs_total_value` (beépített), `_wc_cog_cost` (SkyVerge), `_alg_wc_cog_cost` (WPFactory). A saját érték nélküli variáció a szülőé után megy.

Ha egyik sem tartalmaz költséget, a termék nulla költséggel számít. A kulcsokat ne olvasd ki a saját kódodban, mert forrásonként, verziónként és sorra, illetve termékre különböznek. Használd a fenti függvényt. A WooCommerce beépített COGS-a a nulla költséget törli, ezért egy valóban ingyenes termék nem különböztethető meg attól, amelyiknek nem adtak meg költséget. Ha ez számít, adj az ingyenes és promóciós termékeknek jelképes költséget.

#### Egyéni postmeta mező a költséghez

Ezzel a szűrővel a bővítmény a beszerzési költséget egyéni termék-postmeta mezőből olvashatja. Amint a szűrő aktív, a **Profit margin** logika is kiválasztható a beállításokban. Ugyanezt a kulcsot a rendelés soron is olvassa, ahol az egységköltséget várja.

Tedd a gyermektéma `functions.php` fájljába (`/wp-content/themes/child-theme/functions.php`):

```php
add_filter('pmw_custom_cogs_product_meta_key', function () {
	return 'AZ_EGYENI_POSTMETA_KULCS_NEVE';
});
```

A szűrő korábbi neve `pmw_custom_cogs_meta_key` volt. A régi név még működik, de WordPress-elavulási figyelmeztetést ad. Használd az újat.

#### Fizetésfeldolgozói díjak

A bővítmény a fizetési díjakat is megpróbálja levonni. A WooCommerce-ben nincs szabványos hely a díjaknak, minden bővítmény másképp tárolja, sokan nem is. Ezért a bővítmény a népszerű fizetési módok rendelés-metáiból olvassa ki őket. Jelenleg a következőknél tudja levonni:

- Stripe for WooCommerce
- WooCommerce PayPal Payments
- WooCommerce PayPal Checkout Payment Gateway

Más fizetési módnál a díjat a rendelési díjak (order fees) szűrőjével adhatod meg. Ez az **Order subtotal** opciónál is érvényes, mert az ugyanezeket a díjakat vonja le. Mielőtt felveszed a szűrőt: megváltoztatja, mit jelent a meglévő konverziós műveleted. Az **Order subtotal** mellett a hirdetési platformoknak küldött érték a szűrő élesítésétől a díjjal csökkentett részösszeg lesz, ami lépcsőt okoz a jelentett bevételi idősorban, látható ok nélkül a beállításokban. Ez általában a cél, de számolj vele.

#### Mikor vonódik le a díj

A díj csak akkor vonható le, ha a fizetési bővítmény már eltárolta a rendelésen. A bővítmény két időpontban számolja a konverziós értéket:

- **A böngészős események** (a megerősítő oldal pixele) az oldal betöltésekor, pár másodperccel a fizetés után. Ekkorra a fizetési bővítmény általában már eltárolta a díjat.
- **A szerveroldali események** (Conversions API-k, SweetCode Cloud) annak a kérésnek a végén, amelyben a fizetési bővítmény fizetettre állította a rendelést. A bővítmények a díjat ugyanabban a kérésben tárolják, így a szerveroldali érték is tartalmazza.

A két csatorna így ugyanazt az értéket jelenti. A hirdetési platformok a böngészős és a szerveroldali eseményt a közös eseményazonosítóval kettőzésmentesítik, és az elsőként érkezőét tartják meg, ezért az értékeknek egyezniük kell.

Ha a fizetési bővítmény a díjat egy későbbi kérésben tárolja (például percekkel később érkező webhookkal), egyik számítás sem fedi le. Az ilyen rendelések a díj levonása nélkül kerülnek jelentésre, mert a legtöbb hirdetési platformon utólag nem javítható a vásárlás értéke. Ha ez fontos, számold ki a díjat magad a fizetési módból és a rendelés összegéből az order fees szűrőben, amely az érték számításakor fut, és nem függ attól, hogy a bővítmény eltárolt-e valamit.

## Send profit as a separate field (Pro)

A marketing value logic dönti el a konverziós értéket. Ez a közvetlenül alatta lévő beállítás a rendelés haszonát is hozzáadja az érték mellé, azokon a platformokon, ahol erre külön mező van. A konverziós érték maradhat bevétel, miközben a platform azt is megtanulja, mennyit hozott egy rendelés.

- Jelenleg csak a Meta támogatja: a haszon `net_revenue` néven megy a Purchase eseménnyel, a böngészőben és a Conversions API-n is, az Events Manager pedig Profit néven jelenti. A Meta Ads Manager haszonoptimalizálásához ez kell, és az adatmennyiségtől és időtől függ, mikor válik elérhetővé.
- A haszon számítása ugyanaz, mint a **Profit margin** logikánál.
- Csak azoknál a rendeléseknél megy ki, ahol minden termékhez van beszerzési költség. Egyetlen hiányzó költség eltúlozná a hasznot, ezért az ilyen rendeléseken nincs haszonmező, nem 0 és nem becslés.
- Alapból ki van kapcsolva, mert megosztja az árrésedet a platformmal, és kikerül a megerősítő oldal adatrétegébe, ahol a vevő az oldalforrásban láthatja.
- Ha a marketing value logic **Profit margin**, a beállítás be van kapcsolva és zárolt, mert ott már eldöntötted, hogy a haszon elhagyja a szervered.

## Order duplication prevention

A kettőzésmegelőzés több módszerrel gátolja meg, hogy ugyanazt a rendelést kétszer számolják. Nélküle a Google Analytics, a Meta (Facebook) és más pixelek gyakran kétszer számolnák ugyanazt a rendelést. Átlagosan 10-20%-kal, néha többel felfújt bevételi jelentések is lehetnek, ami nem elfogadható.

A kapcsoló a **General → Order configuration** kártyán van. Maradjon bekapcsolva, csak tesztelés idejére kapcsold ki (6 óra után magától visszakapcsol).

- **Alap, sütiket használó megelőzés:** a bővítmény sütikkel és a böngésző tárhelyével észleli, ha ugyanaz a böngésző többször próbálja elküldeni ugyanazt a konverziót. Elküldéskor elmenti a konverziót a böngészőbe, és újratöltéskor vagy későbbi újralátogatáskor nem küldi el újra. Ez a módszer önmagában 2-4%-ra csökkenti a felfújást.
- **Haladó, szerveroldali megelőzés (Pro):** a böngészős megelőzés után az eseményt a WooCommerce rendeléseinek adatbázisában is eltárolja. Bármelyik eszközön nyitják meg újra a megerősítő oldalt, a konverzió soha többé nem fut le.
- **Kivétel a Google Ads.** A bővítmény minden rendelésnél küld tranzakcióazonosítót, így a Google Ads a saját oldalán kettőzésmentesít. Ez néha órákig tart, ezért előfordulhat, hogy egy napon belül kettősnek látszó konverziók éjszaka eltűnnek. A licitálási algoritmust ez nem zavarja, mert a Google csak kettőzésmentesített adatot használ.
- **Sikertelen rendelések kihagyása:** a bővítmény felismeri a sikertelen fizetésű rendeléseket, és nem futtatja rájuk a konverziós pixeleket, ezzel növeli a mérés pontosságát.

## Dinamikus remarketing

A dinamikus remarketinghez fel kell töltened a termékeidet a platform katalógusába (Google Merchant Center a Google Adshez, Meta katalógus a Facebookhoz stb.), vagy egyéni üzleti feedet kell feltöltened a Google Ads fiókodba. Erősen ajánlott a termékeket a bejegyzésazonosítóval (post ID) feltölteni, az SKU sokkal több problémát és nehezebb hibakeresést okozhat.

1. Ellenőrizd a **Product identifier** beállítást, és ha kell, igazítsd. Egyeznie kell a katalógusba feltöltött azonosítókkal.
2. A variációk kiadása alapból be van kapcsolva. Ehhez a variációkat is fel kell töltened a feeddel, az `item_group_id` mezővel együtt. Egyes feedbővítményeknél ez alapból be, másoknál ki van kapcsolva, ezért ellenőrizd. A variációk feltöltését javasoljuk.

### Product identifier

Azt dönti el, melyik termékazonosító megy a hirdetési platformoknak (Google Ads, Meta, Microsoft Advertising stb.) a dinamikus remarketinghez és a kosáradatokhoz. A beállítás a **General → Product data** kártyán van. Az itt választott azonosítónak pontosan egyeznie kell a katalógus vagy a feed azonosítóival, különben a platform nem tudja összepárosítani a termékeket, a dinamikus remarketing leáll, és „item ID not found” vagy „product not found” hibákat láthatsz.

Azt az opciót válaszd, amelyik a termékeidet feltöltő feedbővítményhez illik. Ha nem használsz külön feedbővítményt, hagyd a **Post ID** opción, ez a WooCommerce alapértéke.

| Opció | Mit küld | Mikor válaszd |
|---|---|---|
| **Post ID (default)** | a WooCommerce termék (bejegyzés) azonosítója, pl. `123` | a termékeket sima WooCommerce-azonosítókkal töltöd fel. Alapérték, a legtöbb boltnak ez ajánlott |
| **SKU** | a termék cikkszáma, ha nincs, a post ID | a katalógusod vagy feeded cikkszám szerint kulcsolt. Előtte olvasd el az alábbi figyelmeztetést |
| **Post ID with woocommerce_gpf_ prefix (Google Product Feed)** | a post ID `woocommerce_gpf_` előtaggal, pl. `woocommerce_gpf_123` | a WooCommerce.com Google Product Feed bővítményét használod, ami így előtagolja az azonosítókat |
| **Post ID with gla_ prefix (Google for WooCommerce)** | a post ID `gla_` előtaggal, pl. `gla_123` | a Google Listings & Ads (Google for WooCommerce) bővítményt használod, ami így előtagolja az azonosítókat |

Az SKU azért problémás, mert nem kötelező, lehet duplikált, és a bolt és a feed között gyakran eltér. Bármelyik opciót választod, pontosan olyan azonosítót kell kiadnia, mint ami a katalógusban van. A beállítás módosítása után ellenőrizd vagy töltsd fel újra a feedet.

### Output product variations as separate items

Azt dönti el, hogy a változó termékeknél variációszintű vagy szülőtermék-szintű adatot küld-e a bővítmény. Alapból be van kapcsolva, és a legtöbb boltnak ez ajánlott. A beállítás a **General → Product data** kártyán van.

Ha a vevő változó termékkel (például különböző méretű és színű póló) lép kapcsolatba, a bővítmény eldönti, melyik azonosító megy az eseményekkel:

- **Bekapcsolva (ajánlott):** a konkrét variáció azonosítója megy (például „Kék póló, M”).
- **Kikapcsolva:** a szülőtermék azonosítója megy (például „Póló”), függetlenül a kiválasztott variációtól.

A beállítás minden termékhez kapcsolódó eseményt érint, és minden platformra egyformán vonatkozik: `view_item` (termékoldal megtekintése, a variáció kiválasztásával együtt), `add_to_cart`, `remove_from_cart`, `view_item_list` (kategória- és keresési találati oldalak), `search` és `purchase`.

**Mikor kapcsold be:** ha a katalógus vagy a feed a variációkat külön tételként tartalmazza. Így pontosabb a remarketing (a vevő azt a variációt látja viszont, amit megnézett), jobb a célközönség-szegmentálás variációszinten, és pontosabb a konkrét variációk konverziókövetése. A feedbe feltöltött variációknál ügyelj arra, hogy a feedbővítmény tartalmazza a csoportosító mezőt, ami a variációkat a szülőhöz köti. A Google Merchant Centernél ez az `item_group_id`.

**Mikor kapcsold ki:** csak ha a katalógus a változó termékeknél csak a szülőtermékeket tartalmazza. Ez lehet, ha a feedbővítményed nem tud variációkat exportálni, nagyon nagy a katalógusod és egyszerűsíteni akarod a feedet, vagy a hirdetési platformnak korlátai vannak a variációszintű követéssel.

Ha kikapcsolod, miközben a feed variációkat tartalmaz (vagy bekapcsolva hagyod, miközben csak szülők vannak), a bővítmény által küldött és a katalógusban lévő azonosítók eltérnek, ami megszakítja a dinamikus remarketinget, és „product not found” hibákat okoz.

### Google Ads: termékfeed

A termékeket többféleképpen töltheted fel a Google Merchant Centerbe, a legegyszerűbb egy feedbővítmény.

- **Google Product Feed (WooCommerce.com):** viszonylag könnyen használható, nehezen kezeli a nagy feedeket, és csak a Google Adshez és a Microsoft Adshez jó.
- **WooCommerce Product Feed Manager (WPMarketingRobot):** sok beállítása van, de nehezebb beállítani, nagyon jól kezeli a nagy feedeket, és sok marketingcsatornát támogat.

**Egyéni üzleti feed:** azokban az országokban, ahol a Google Merchant Center nem érhető el, a termékeket egyéni üzleti feeddel töltheted fel a Google Adsben. Ehhez a Google üzleti kategóriát (Business Vertical) „Custom” értékre kell állítani, ami a Pro változatban érhető el.

### Business vertical (Pro)

Megmondja a Google-nek, melyik katalógustípushoz tartoznak a dinamikus remarketing események. A Google ez alapján párosítja a bővítmény által küldött azonosítókat a megfelelő katalógussal, ezért az itt választott értéknek egyeznie kell a feltöltött feed típusával. A beállítás a **Tracking Pixels → Google (Ads & GA4)** kártyán van, a **Show advanced settings** alatt, a **Business vertical** mezőben.

Lehetőségek: **Retail** (alapérték, fizikai termékeket árusító webáruházak, a legtöbb WooCommerce-boltnak ez jó), **Education**, **Hotels and Rentals**, **Jobs**, **Local Deals**, **Real Estate**, **Travel**, **Custom** (egyéni üzleti feedhez). Ha a termékeid szabványos Google Merchant Center retail feeden át vannak feltöltve, hagyd **Retail** értéken. Csak akkor válts **Custom**ra, ha egyéni üzleti feedet állítottál be a Google Adsben, és ügyelj arra, hogy mindkét oldalon egyezzen, mert eltérés esetén a párosítás megszakad.

### Dinamikus remarketing célközönségek a Google Adsben

1. A Google Adsben nyisd meg a **Shared Library → Audience Manager → Audience Sources** oldalt, és kattints a **Setup Tag** gombra.
2. Add meg az alapbeállításokat.
3. Fejezd be a beállítást.

Ezután a Google Ads magától létrehoz négy dinamikus remarketing célközönséget.

## Subscription value multiplier (Pro)

Alapból az előfizetések konverziós értéke a fizetős hirdetési pixeleknek csak az első előfizetési rendelés értékét tartalmazza. Egy előfizetés viszont jóval nagyobb tényleges értéket vagy ügyfél-élettartam-értéket (CLV) hozhat, mert általában több automatikus rendelést is létrehoz a jövőben. Ezeket a hirdetési pixelek nem tudják rögzíteni, mert a vevőnek nem kell hozzájuk böngészőben fizetnie. A szorzó az előfizetés értékét felszorozza, hogy közelebb kerüljön a tényleges értékhez.

Az alapértéke `1.00`, ennél nagyobb szorzót állíthatsz be. A beállítás a **General → Subscriptions** kártyán, a **Subscription value multiplier** mezőben van.

Nincs minden boltra érvényes szorzó, ez attól függ, átlagosan meddig tart egy előfizetés a boltodban. Jó módszer: vedd az összes előfizetési rendelés (kezdő és megújítási) számát, és oszd el a kezdő előfizetések számával. Ez az átlagos megújítási szám, és ezt használhatod szorzónak. Érdemes kicsit alacsonyabb számot választani a konzervatívabb irányban, mert a tényleges megújítási szorzó idővel ingadozik.

## Customer lifetime value (Pro)

A bővítmény ki tudja számolni az ügyfél életre szóló értékét (LTV) az összes rendelés teljes és marketingértéke alapján. Az érték megjelenik a rendelés részletei oldalon, és a marketingpixelek használhatják a kampányok optimalizálásához.

Két LTV-t számol:

- **Total order value LTV:** az azonos számlázási e-mail-címmel rendelkező rendelések teljes értékének összege.
- **Marketing order value LTV:** ugyanezen rendelések marketingértékének összege, a **Marketing value logic** szerint (rendelés összege, részösszege, árrés vagy a marketing konverziós érték szűrő eredménye).

A bővítmény az LTV-t azoknak a marketingpixeleknek küldi, amelyek támogatják.

### Bekapcsolás

1. Nyisd meg a **General → Customer lifetime value** kártyát.
2. Kapcsold be a **Calculate LTV on orders** kapcsolót.
3. Mentsd.

A rendelés szerkesztő oldalán egy ablak mutatja az ügyfél LTV-jét.

**Miért tér el a WooCommerce ügyféltörténetétől?** A bővítmény a számlázási e-mail-cím alapján számol, a WooCommerce az ügyfélazonosító alapján. A visszatérő vevők néha bejelentkezve vásárolnak, néha vendégként, és a vendégrendelés nem ugyanazon az ügyfélazonosítón mentődik. Az azonos számlázási e-mail-cím szinte biztosan ugyanazt az ügyfelet jelenti, ezért a bővítmény szerint ez van közelebb a valósághoz.

### Újraszámítás

Az LTV minden rendelésnél automatikusan frissül az érintett ügyfélnél, a visszatérítések és lemondások is automatikusan frissítik. A teljes újraszámítást te indítod. Az újraszámítás mindkét LTV-t frissíti.

Az LTV halmozottan tárolódik minden rendelésen, ezért ha egy korábbi rendelés értéke megváltozik, az ügyfél minden későbbi rendelése a régi értéket hordozza az újraszámításig. Futtass teljes újraszámítást, ha olyat változtatsz, ami a már leadott rendelések értékét érinti:

- megváltoztatod a rendelésérték-logikát,
- hozzáadsz vagy módosítasz egy marketing konverziós érték szűrőt vagy más értékszűrőt a témádban vagy egy bővítményben,
- korábbi rendeléseket importálsz vagy migrálsz.

A bővítmény ezeket a változásokat tervezetten nem érzékeli magától: a szűrő a téma `functions.php` fájljában vagy egy bővítményben él, nincs olyan esemény, amit figyelhetne, és az észleléshez újra kellene számolnia mindent, éppen azt a drága műveletet, amit el akar kerülni. A korábbi automatikus észlelés komoly teljesítményproblémát okozott nagy rendeléstörténetű boltoknál, ezért kivették.

1. Nyisd meg a **General → Customer lifetime value → Manual LTV recalculation** részt.
2. Kattints a **Schedule LTV recalculation** gombra. A futás a bolt helyi idő szerinti 2:00-ra van ütemezve, hogy ne a forgalmas órákra essen.
3. Amíg ütemezve van, két újabb opció jelenik meg: a **Run it now** azonnal elindítja az újraszámítást, a **Stop all LTV calculations** pedig megszakítja. Ez a visszatérítések és lemondások által sorba állított ügyfélenkénti újraszámításokat is törli, ezért akkor használd, ha az összes LTV-munkát le akarod állítani.

Az összes ügyfél újraszámítása sokáig tarthat és sok szerver-erőforrást használ, ezért ha nincs azonnal szükséged az új értékekre, inkább az éjszakai futást válaszd. A háttérfutáshoz a bővítmény az Action Schedulert használja, ami időtúllépési üzeneteket írhat a naplófájlokba. Ezek figyelmen kívül hagyhatók, a bővítmény kezeli őket, és a számítás befejeződik.

## Extra order data output

A bővítmény extra rendelésadatot tud megjeleníteni, ami segít megérteni és hibakeresni, mit küld a marketingpixeleknek.

1. Nyisd meg a **General → Extra order data output** kártyát.
2. Kapcsold be az **Output extra order data on order pages** kapcsolót.

Ezután minden rendelés részletei oldalán látszik az extra adat, benne a **Order URL**. Ennek a speciális hivatkozásnak a megnyitásakor a bővítmény emberi olvasásra alkalmas formában kiírja a böngésző fejlesztői konzoljára mindazt, amit a marketingpixeleknek küld. Ajánlott a hivatkozást jobb kattintással inkognitóablakban megnyitni, ott pedig megnyitni a fejlesztői konzolt. A funkció nem küld extra adatot a pixeleknek.