# Általános beállítások

> A General fül: lusta betöltés, szerepkörök kizárása, görgetéskövetés, a rendelések értéke, termékazonosító, előfizetések és az ügyfél életre szóló értéke.

Az oldalszintű beállítások a **WooCommerce → Pixel Manager → General** fülön vannak. A beállítások mentése automatikus a módosítás után.

![A General fül beállításai](./kepek/altalanos.webp)

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

## General

| Beállítás | Mit csinál | Alapérték |
|---|---|---|
| **Lazy-load the Pixel Manager** | A követőkönyvtárat a látogató első interakciójáig (kattintás, görgetés, billentyű, érintés, egérmozgás) nem tölti be, ami javítja az oldalsebesség-pontszámokat. A kosár, a pénztár és a megerősítő oldal mindig azonnal betölti, így a konverziók nem vesznek el. Pro funkció. | kikapcsolva |
| **Load deprecated functions** | Az elavult függvény- és eseménynevek kompatibilitási rétege. Csak akkor kell, ha saját front-end JavaScript kódod a régi nevekre támaszkodik. Kikapcsolva kevesebb JavaScriptet tölt le a látogató. | bekapcsolva |
| **Disable tracking for user roles** | A kijelölt szerepkörű bejelentkezett felhasználókat nem követi (például a saját munkatársaidat). Az egyéni szerepkörök is megjelennek. Pro funkció. | semmi sincs kijelölve |
| **Scroll tracker thresholds** | Vesszővel elválasztott görgetési mélységek százalékban (például `25, 50, 75, 100`). Elérésükkor a Google Analyticsbe `scroll` esemény megy a mélységgel. Üresen kikapcsolt. Pro funkció. | üres |

A lusta betöltés kockázata: az a látogató, aki egyetlen interakció nélkül elhagyja az oldalt, nem generál `page_view` és `view_item` eseményt. Ez főleg a mobilon a nézet tetejét elolvasó, majd továbblépő látogatókat érinti. A konverziót nem érinti. A Meta, a Google Ads és a többi pixel kevesebb felső tölcsér-eseményt mutathat, a remarketing célközönségek kisebbek lehetnek, és a Google Ads vagy a Meta ellenőrzője jelezheti, hogy a címke nem aktív az oldalon, mert a robotjuk sem lép interakcióba. Ha nem vagy biztos benne, hagyd kikapcsolva: az oldalsebesség-pontszám csak egy szám, a kimaradt események viszont végleg elvesznek. Bekapcsolás előtt teszteld a saját környezetedben, mert egyes JavaScript-optimalizálók megzavarhatják.

A görgetéskövetőnél: ha egy megadott mélység már látszik az ablakban az oldal betöltésekor, az esemény akkor is elsül, amikor a látogató még nem görgetett.

### Maximális kompatibilitási mód

Ez a beállítás megszűnt, nem kapcsolható be. A szükséges JavaScript-optimalizálási kizárásokat (minifikálás, összevonás, a JS késleltetése a kosár- és pénztároldalon) a bővítmény magától alkalmazza minden támogatott gyorsítótár- és teljesítménybővítményhez. A részleteket a [Kompatibilitás](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/kompatibilitas/) fejezetben találod.

## Order configuration

| Beállítás | Mit csinál | Alapérték |
|---|---|---|
| **Marketing value logic** | A hirdetési platformoknak (Google Ads, Meta stb.) jelentett konverziós érték: **Order subtotal, excl. tax & shipping (default)**, **Order total, incl. tax & shipping** vagy **Profit margin (Pro)**. A statisztikai pixelek mindig a teljes rendelési értéket kapják. | Order subtotal |
| **Send profit as a separate field** | A haszon külön mezőként megy a marketingérték mellett, ahol a platform ezt támogatja. Jelenleg ez a Meta `net_revenue` mezője, amely az Events Managerben Profit néven látszik. Csak azokra a rendelésekre megy, ahol minden termékhez van beszerzési költség. Megosztja a árrésedet a platformmal. | kikapcsolva |
| **Order duplication prevention** | Megakadályozza, hogy ugyanaz a rendelés újra beleszámoljon, ha a megerősítő oldalt újratöltik vagy újra megnyitják. Csak teszteléshez kapcsold ki, 6 óra után magától visszakapcsol. | bekapcsolva |
| **Show tracking info in the order list** | A WooCommerce rendelések listájában Pixel Manager oszlopot jelenít meg, így látod, mely rendeléseket követte a bővítmény. | bekapcsolva |

A **Marketing value logic** részletei: az **Order subtotal** a legóvatosabb, csak a termékbevételt jelenti, az adót, a szállítást és a rendelési díjként felvett pótdíjakat kihagyja, a kedvezményeket, visszatérítéseket és a fizetésfeldolgozói díjakat (Stripe, PayPal) levonja. Az **Order total** azt az összeget jelenti, amit a vevő fizetett. A **Profit margin** csak az árrést jelenti, és beszerzési költség forrást igényel.

## Product data

| Beállítás | Mit csinál | Alapérték |
|---|---|---|
| **Product identifier** | Melyik termékazonosító megy a hirdetési platformoknak a dinamikus remarketinghez. Egyeznie kell a termékfeedben lévő azonosítókkal, különben a remarketing nem találja meg a termékeket. Lehetőségek: **Post ID (default)**, **SKU**, **Post ID with woocommerce_gpf_ prefix (Google Product Feed)**, **Post ID with gla_ prefix (Google for WooCommerce)**. | Post ID |
| **Output product variations as separate items** | A megtekintett vagy megvásárolt konkrét variációt jelenti (például „Kék póló, M”). Csak akkor kapcsold ki, ha a feedben csak szülőtermékek vannak. | bekapcsolva |

## Subscriptions és Customer lifetime value

Ezek Pro funkciók.

| Beállítás | Mit csinál |
|---|---|
| **Subscription value multiplier** | Megszorozza az induló előfizetés értékét, hogy tükrözze a jövőbeli megújításokból származó bevételt. Állítsd az előfizetésenkénti átlagos rendelésszámra (1.00 = nincs módosítás). |
| **Calculate LTV on orders** (BETA) | Kiszámolja minden vásárló összesített életre szóló értékét, és beleteszi a rendelésadatokba (értékalapú licitálás, nagy értékű vásárlók célközönsége). A visszatérítések és lemondások automatikusan frissítik az érintett vásárlót. |
| **Schedule LTV recalculation** | Újraszámolja az összes vásárló értékét a teljes rendeléstörténetből. Futtasd, ha módosítod a rendelésérték-logikát vagy a témádban az értékszűrőt. |

## Extra order data output

A **Output extra order data on order pages** (BETA) kapcsoló a rendelés részleteinél megjeleníti a marketingpixeleknek küldött adatot (és a rendelés URL-jén át a böngésző konzolján is), hibakereséshez. Nem küld ki extra adatot a pixeleknek.

## Adatok törlése eltávolításkor

A **Support → Plugin data** részben a **Delete all plugin data on uninstall** kapcsoló dönt arról, mi történik az adatokkal a bővítmény törlésekor. Alapból a beállítások megmaradnak, így újratelepítés után nem kell újra beállítani. Bekapcsolva a törlés minden adatot eltávolít (beállítások, biztonsági mentések), és ez nem visszavonható. Csak a törlésre vonatkozik (**Bővítmények → Törlés**), a kikapcsolásra nem. Ha meg akarod őrizni a beállításokat, előbb exportáld őket ([Diagnosztika és tesztelés](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/diagnosztika-es-tesztelles/)).

![A Support fül Plugin data kártyája a törlési kapcsolóval](./kepek/elso-lepesek-adatok-torlese.webp)

*A Support fül Plugin data kártyája a törlési kapcsolóval* (https://minta-bolt.hu/wp-admin/admin.php?page=pmw)

Figyelj a **Plugin data** kártyára: a kapcsoló alapból ki van kapcsolva.

## Szerveroldali beállítások a Server-Side fülön

Ezek a **WooCommerce → Pixel Manager → Server-Side → General** részen vannak.

### Send PageView events server-to-server (Pro)

Egyes hirdetési platformok a `PageView` eseményt is fogadják a szerveroldali API-jukon át, ami megbízhatóbbá teszi a mérést, ha a böngészős követés akadozik. Jelenleg ezt a Meta (Facebook) és a Snapchat támogatja. Bekapcsolva a bővítmény minden olyan platformnak elküldi a szerveroldali `PageView` eseményt, amelynél a szerveroldali követés be van kapcsolva.

A többi konverziós eseményt (`AddToCart`, `InitiateCheckout`, `Purchase`) a bővítmény alapból szerveroldalon is küldi, csak a `PageView` van alapból kikapcsolva.

Figyelem: a `PageView` szerveroldali küldése jelentősen megterheli a szervert, mert minden oldalbetöltésnél küld egy eseményt. A terhelés csökkentésére a bővítmény az összes `PageView` eseményt egyetlen kérésbe fogja össze, és a REST API-n át küldi, ami csak a WordPress magját tölti be, így nagyjából kétszer gyorsabb, mint a teljes WordPress-környezet betöltése.

### Always send server-side events (Pro)

Normál esetben a szerveroldali (Conversions API) események a böngészős pixelek kiegészítései. Ha ezt bekapcsolod, a szerveroldali események akkor is elmennek, ha a böngészős pixelek sosem töltődtek be, például mert egy hozzájárulási sáv vagy egy reklámblokkoló megakadályozta. A böngészős követést ez nem érinti, a szerveroldali események a szerveren függetlenül futnak, és a kettőzésmegelőzés miatt nincs dupla számolás.

Arra jó, hogy visszanyerd a konverziókat azokon a platformokon, amelyek támogatják a süti nélküli vagy korlátozott adatú szerveroldali integrációt (például a Meta CAPI). Olyan boltoknál a leghasznosabb, ahol a látogatók nagy része blokkolja a böngészős pixeleket.

A szerveroldali vásárlási események alapból tiszteletben tartják a látogató hozzájárulási döntését: ha a látogató elutasítja a hozzájárulást, a vásárlási esemény nem megy ki szerveroldalon. A Google Analytics 4-hez statisztikai hozzájárulás kell, a hirdetési platformokhoz (Meta, TikTok, Snapchat, Pinterest, Reddit, OpenAI) marketinghozzájárulás. Az **Always send server-side events** ezt írja felül: bekapcsolva minden szerveroldali esemény, a vásárlások is, a hozzájárulás állapotától függetlenül elmennek. A fizetési mód pontossági jelentés megmutatja, hány rendelést zártak ki azért, mert a látogató minden hozzájárulási kategóriát elutasított, és ez a rendelések hány százaléka a kiválasztott időszakban, így előre megítélheted a hatást.

Mivel a beállítás a látogató döntésétől függetlenül küld adatot, győződj meg róla, hogy a te joghatóságodban ez megengedett. Ennek megítélése a boltüzemeltető felelőssége.

### Mely rendelések küldenek szerveroldali vásárlási eseményt

A bővítmény rendelésenként pontosan egy szerveroldali vásárlást küld, minden olyan rendelésnél, amely fizetett állapotot ér el, bármi hozta is létre. Nincs kötelező bolti (front-end) lépés ezen az úton. Ide tartoznak azok a rendelések is, amelyekben böngésző sosem vett részt:

- a WooCommerce REST API-n vagy Store API-n át létrehozott rendelések (ERP, piactér-importáló vagy más integráció),
- a munkatársak által az admin felületen leadott rendelések,
- az előfizetések megújításai,
- régebbi rendelések, amelyeket később állítottak fizetett állapotra, például amikor egy külső oldalon fizetős fizetési mód napokkal később igazolja vissza a fizetést.

Rendelésenként csak egy szerveroldali vásárlás megy ki: a rendelés megjelölődik, amint kiment, és ez a jelölés blokkol minden későbbi állapotváltást, újrapróbálkozást és fizetési visszahívást, így az ismételt állapotváltások nem küldhetik el másodszor.

**Hogyan látszik ez a hirdetési platformban?** A böngésző nélküli rendeléshez nincs böngészős esemény, amivel párosítani lehetne, ezért a platform nyers adataiban csak a szerveroldali csatornán jelenik meg. Ettől megnő a szerver és böngésző arány, és csökken a kettőzésmentesítési lefedettség. Ha a boltban a rendelések többsége integráción át érkezik, a böngészős eseményenkénti öt-tíz szerveroldali esemény a várt kép, nem kettőzési hiba.

Ezért tűnhet úgy, mintha a bővítmény két jelentése ellentmondana egymásnak: a fizetési mód pontossági jelentés (Payment Gateway Tracking Accuracy) csak a bolti pénztáron át létrehozott rendeléseket számolja, mert csak azok juthatnak el a megerősítő oldalra, a Click ID Capture Quality jelentés pedig minden vizsgált rendelést, azokat is, amelyekhez böngésző sosem nyúlt. Az a bolt, amelynek 95%-os a követési pontossága, de a rögzítési minőség szerint a rendelések többségéből hiányzik a böngészős pixel, nincs ellentmondásban: más rendeléshalmazt mérnek.

**Rendelések kizárása:** ha egy adott eredetű rendeléseket teljesen ki akarsz tartani a hirdetési platformokból, használd a `pmw_skip_s2s_purchase_event` szűrőt. Ez minden platformon elnyomja a szerveroldali vásárlást, és a rendelést kizárja a Google Ads konverziókorrekciós feedjéből is, így utólag sem térhet vissza korrekcióként. Az előfizetés-megújításoknak külön kapcsolójuk van: `pmw_subscription_renewal_tracking`.