Bolt beállításai

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

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

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 Customra, 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.