# GA4 anon_* kliensazonosítók

> Mikor küld a Pixel Manager anon_* kezdetű GA4 client_id értéket, mit jelent, miért marad a vásárlás „(not set)” alatt, és hogyan vizsgálhatsz meg egy konkrét rendelést.

A szerveroldali Google Analytics 4 Measurement Protocol követés a Pro változat funkciója.

Ha a Pixel Manager naplóit nézed, találkozhatsz szerveroldali GA4 vásárlási eseményekkel, amelyek `client_id` értéke így néz ki:

```
anon_76413.1786483870
```

a böngésző szokásos GA4 kliensazonosítója helyett, amely így néz ki:

```
171933599.1747821527
```

A fejezet leírja, mikor állít elő a Pixel Manager `anon_*` értéket, tartaléknak számít-e, és mit jelent a GA4 Measurement Protocol attribúciójára és a „(not set)” jelentésekre nézve.

## Röviden

A Pixel Manager az `anon_*` GA4 `client_id` értéket csak tartalékként használja, és csak a szerveroldali GA4 Measurement Protocol eseményeknél. Ha a rendeléshez rögzítették a böngésző GA4 `client_id` értékét, mindig azt használja. Nincs olyan eset, hogy `anon_*` értéket küldene, miközben használható böngészőazonosító áll rendelkezésre.

Az `anon_*` érték ezért önmagában nem hiba és nem is a gyökérok. Jelzés arról, hogy a böngésző GA4 kliensazonosítóját ennél a rendelésnél nem rögzítették. Ez a hiányzó azonosság akadályozza meg, hogy a GA4 a szerveroldali vásárlást az eredeti böngészős munkamenethez kösse, és ez okozza a „(not set)” attribúciót.

## Mely eseményeket érinti

Az `anon_*` csak három szerveroldali GA4 Measurement Protocol üzenetben jelenhet meg:

- `purchase`,
- teljes `refund`,
- részleges `refund`.

A böngészőoldali GA4 eseményeket sosem érinti: azok mindig a `gtag` által kiadott valódi kliensazonosítót használják.

A visszatérítések a kliensazonosítótól független okból kerülnek a „(not set)” alá: a WooCommerce adminban dolgozzák fel őket, a látogató munkamenete után jóval később, így nincs élő munkamenet, amelyhez köthetők volnának. A visszatérítések jelentéséről és kikapcsolásáról a [Követőpixelek](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/pixelek-google-analytics/) fejezetben olvashatsz.

## Mi az anon_* kliensazonosító

Az érték egy véletlen 10 jegyű számból és az aktuális Unix-időbélyegből épül fel, majd az első öt karaktert lecserélik az `anon_` előtagra. Az eredmény megtartja a GA4 kliensazonosító általános alakját.

| Tulajdonság | Viselkedés |
|---|---|
| Eredet | Véletlenszerűen jön létre az üzenet összeállításának pillanatában |
| A vásárlóból, rendelésből, böngészőből vagy munkamenetből származik? | Nem |
| Tárolódik valahol? | Nem. Sosem kerül rendelés-metába, WooCommerce munkamenetbe vagy sütibe |
| Állandó az események között? | Nem. Ugyanannak a rendelésnek a vásárlása és egy későbbi visszatérítése különböző `anon_*` értéket kap |
| Tartós vagy determinisztikus? | Egyik sem |
| Elfogadja a GA4? | Igen, a GA4 bármilyen szöveget szintaktikailag érvényes `client_id`-nek tekint |

Mivel véletlen és soha nem használják újra, az `anon_*` érték semmit nem azonosít. Kizárólag azért létezik, mert a GA4 Measurement Protocol minden üzenetben megköveteli a `client_id` mezőt.

## Az azonosító kiválasztása

| Helyzet | Van böngészős GA4 kliensazonosító? | Elküldött `client_id` | Elküldött `session_id` | Várt GA4-attribúció |
|---|---|---|---|---|
| Szokásos pénztár, statisztikai hozzájárulás megadva, a `_ga` süti olvasható | Igen | A böngésző kliensazonosítója | Igen | Csatlakozik az eredeti munkamenethez, a szokásos forrás, közeg és kampány |
| A `_ga` süti hiányzik a pénztárnál (sosem írták meg, törölték vagy blokkolták) | Nem | `anon_*` | Nem | Új, nem hozzárendelt felhasználó és munkamenet, jellemzően „(not set)” |
| A `_ga` süti megvan, de hibás (kevesebb mint négy ponttal elválasztott rész) | Nem | `anon_*` | Nem | Ugyanaz |
| Statisztikai hozzájárulás megtagadva, az „always send server-side events” ki van kapcsolva | Nem értelmezhető | Semmi nem megy ki | Semmi | Egyáltalán nincs GA4 vásárlás, tervezetten |
| Statisztikai hozzájárulás megtagadva, az „always send server-side events” be van kapcsolva | Általában nem, mert a Consent Mode megakadályozza, hogy a `gtag` megírja a `_ga` sütit | `anon_*` | Nem | „(not set)”. Ez a leggyakoribb módja, hogy egy bolt nagy számban kap `anon_*` értéket |
| A pénztárat csak keresztdomain fizetési átjáró iframe-jében figyelték meg | Nem | `anon_*` | Nem | „(not set)” |
| Előfizetés-megújítási rendelés | Igen, a szülőrendelésből | A szülőrendelés kliensazonosítója | A szülőrendelés tárolt munkamenet-azonosítója | Ugyanahhoz a felhasználóhoz rendelődik; munkamenetszintű csatlakozás valószínűtlen, mert az eredeti munkamenet rég véget ért |
| A rendelést a WordPress háttérben hozták létre, a vásárló a front enden fizette ki | Igen, a fizető vásárló böngészőjéből frissítve | A böngésző kliensazonosítója | Igen | Szokásos attribúció |
| Érvényes böngészős kliensazonosító létezik és rögzítették | Igen | Mindig a böngésző kliensazonosítója | Igen | Az `anon_*` ilyenkor sosem használatos |

## Honnan jön a böngésző kliensazonosítója

A Pixel Manager a GA4 kliensazonosítót a `gtag` által megírt `_ga` sütiből olvassa. A süti így néz ki: `GA1.1.171933599.1747821527`, a kliensazonosító pedig a harmadik és negyedik rész összefűzve: `171933599.1747821527`.

Három részlet számít a hibakereséskor:

1. A kliensazonosító a pénztárnál kerül rögzítésre, nem a küldéskor. A WooCommerce munkamenetbe, majd a rendelésre kerül, és a Measurement Protocol esemény elküldésekor a rendelésről olvassa vissza. Ha a süti nem volt olvasható a rendelés létrehozásakor, nem tárolódik kliensazonosító, és később semmi nem tudja pótolni. Ezért nem tudják a késleltetett fizetések, a webhookok és a cron által indított küldések kijavítani a hiányzó azonosságot: ezekben a helyzetekben nincs böngésző.
2. Az azonosítórögzítés kimarad iframe-ben. Egyes fizetési átjárók keresztdomain iframe-ben jelenítik meg a pénztárat, ahol a szülő környezet olvasása hibás adatot adna. A Pixel Manager itt szándékosan kihagyja a rögzítést.
3. A hibás süti figyelmen kívül marad. Ha a `_ga` sütinek nincs legalább négy ponttal elválasztott része, használhatatlannak számít.

## A session_id együtt utazik a kliensazonosítóval

A GA4 munkamenet-azonosítója külön sütiből, a `_ga_<MÉRÉSI_AZONOSÍTÓ_VÉGE>` sütiből jön. A Pixel Manager csak akkor ad `session_id` mezőt az üzenethez, ha ezt a sütit rögzítette, és mellé az `engagement_time_msec` mezőt is hozzáadja.

Mivel a `gtag` a `_ga` és a `_ga_*` sütiket együtt írja, ha a `_ga` süti hiányzik, a munkamenet-süti is szinte mindig hiányzik. Egy `anon_*` vásárlás ezért általában `session_id` nélkül megy ki, és ez az ismeretlen felhasználó munkamenet-hivatkozás nélkül kombináció teszi lehetetlenné a csatlakozást.

## A HTTP 204 nem bizonyítja az attribúciót

Ez a fejezet legfontosabb megkülönböztetése.

A `HTTP 204` válasz azt jelenti, hogy a Google elfogadta a Measurement Protocol kérést. Az attribúcióról semmit nem mond.

A GA4 Measurement Protocol éles végpontja akkor sem ad hibaválaszt, ha az üzenet hibás. A `204` ezért semmit nem erősít meg az alábbiak közül:

- hogy a `client_id` egy meglévő GA4-felhasználóhoz tartozott,
- hogy az eseményt az eredeti böngészős munkamenethez csatlakoztatták,
- hogy forrás, közeg és kampány hozzárendelődött,
- hogy az esemény úgy jelenik meg a jelentésekben, ahogy vártad.

Az üzenet szabályosságának ellenőrzésére használd a Google Measurement Protocol érvényesítő végpontját, amely hibákat is visszaad. De még ott is igaz, hogy egy érvényes üzenet `anon_*` kliensazonosítóval továbbra is hozzárendeletlen marad.

## Mit jelentenek a rendelés jelzői

A `wpm_google_analytics_4_mp_purchase_hit` közvetlenül a kérés elküldése után kerül beírásra, a válasz vizsgálata nélkül. Azt jelenti: „a Pixel Manager egyszer elküldte ezt a vásárlást”, és a dupla küldés megakadályozására van. Nem állítás a GA4-attribúcióról, sőt arról sem, hogy a GA4 feldolgozta az eseményt.

A Pixel Manager rendelés-meta kulcsai:

- `wpm_google_analytics_4_mp_purchase_hit`,
- `wpm_google_analytics_4_mp_full_refund_hit`,
- `wpm_google_analytics_4_mp_partial_refund_hit`,
- `wooptpm_google_analytics_4_mp_purchase_hit` (régi kulcs, még figyelembe veszi).

A `_ga_tracked` nem Pixel Manager rendelés-meta kulcs. A bővítményben sehol nem létezik. Ha a rendeléseiden látod, egy másik bővítmény vagy egyedi integráció írta, és a jelentését az dönti el, ami megírta.

## Hozzájárulás

A szerveroldali GA4 vásárlási eseményeket a statisztikai hozzájárulási kategória szabályozza, nem a marketing, mert a GA4 elemző célpont.

- **Statisztikai hozzájárulás megtagadva, „always send” kikapcsolva.** A vásárlási esemény teljesen elnyomódik. Semmi nem megy ki, `anon_*` találatot sem látsz. Az adott rendelés visszatérítései is elnyomódnak, így a GA4 nem kap visszatérítést olyan vásárlásra, amelyet sosem látott. Ez a várt viselkedés, nincs teendő.
- **Statisztikai hozzájárulás megtagadva, „always send” bekapcsolva.** A hozzájárulási kapu megkerülődik, és az esemény elmegy. De a Google Consent Mode `analytics_storage` értékét `denied`-ra állítja, ezért a `gtag` nem írja meg a `_ga` sütit, nincs rögzíthető böngészős kliensazonosító, és a találat `anon_*` értékkel és `session_id` nélkül megy ki. Ha bekapcsoltad az „always send server-side events” opciót, és a látogatók érdemleges része megtagadja a statisztikai hozzájárulást, szinte biztosan innen jönnek az `anon_*` találataid és a „(not set)” bevételed.
- **Nincs hozzájárulási pillanatkép a rendelésen.** A hozzájárulási kapu bevezetése előtti, vagy olyan integrációval létrehozott rendeléseket, amely sosem jelentett hozzájárulási állapotot, a régi viselkedés megőrzésére alapból elküldi. A szigorú beállítások ezeket is elnyomhatják a `pmw_s2s_require_consent_snapshot` szűrővel.

A kompromisszum szándékos: az „always send” bekapcsolva megtartod a bevételi számot a GA4-ben, de elveszíted az attribúcióját; kikapcsolva elveszíted a vásárlást, de sosem küldesz hozzárendelhetetlent. Egyik beállítás sem tud hozzárendelt vásárlást adni olyan látogatótól, aki megtagadta a statisztikai hozzájárulást, mert sosem létezhetett azonosság.

## Miért „(not set)”, amikor minden rendben látszik

A jelentett minta: a WooCommerce rendelés-attribúciója helyesen tárolódik, a Pixel Manager rendelésjelzői be vannak állítva, a Measurement Protocol `HTTP 204` választ ad, és a GA4 mégis „(not set)” alatt jelenti a vásárlások egy részét.

Ezek a tények összefér egymással, mert különböző dolgokat mérnek:

| Tény | Mit bizonyít | Mit nem bizonyít |
|---|---|---|
| A WooCommerce attribúció `source=google`, `medium=cpc` | A WooCommerce megfigyelte és eltárolta a hivatkozót | Semmit a GA4-ről. A WooCommerce rendelés-attribúciója teljesen különálló rendszer, a GA4 nem tudja olvasni |
| A `wpm_google_analytics_4_mp_purchase_hit` be van állítva | A Pixel Manager egyszer elküldte az eseményt | Hogy a GA4 elfogadta, feldolgozta vagy hozzárendelte |
| A Measurement Protocol `HTTP 204`-et adott | A Google elfogadta a kérést | Hogy munkamenethez csatolták vagy hozzárendelték |

A három közül egyik sem mondja meg, azonosítani tudta-e a GA4 a felhasználót. Ezt csak az üzenetben lévő `client_id` és `session_id` mutatja.

Miután a kézbesítés megerősítést nyert, az attribúció még ezekből az okokból hiányozhat:

1. `anon_*` kliensazonosító és nincs munkamenet-azonosító. Nincs csatlakozás, a GA4 új, hozzárendeletlen felhasználót rögzít, a vásárlás a „(not set)” alá kerül.
2. Valódi kliensazonosító, de nincs munkamenet-azonosító. A GA4 azonosítani tudja a felhasználót, de nincs munkamenet, amelyhez az eseményt csatolhatná.
3. Valódi kliensazonosító és munkamenet-azonosító, de a munkamenet lejárt. A fizetés után jóval később elküldött szerveroldali események, például napokkal később kifizetett banki átutalás vagy számla esetén, az eredeti munkamenet vége után érkeznek.
4. A 72 órás visszadátumozási korlát. A Pixel Manager `timestamp_micros` mezőt küld, hogy a GA4 a vásárlást a rendelés leadásának pillanatához rendelje, de a GA4 csak a beérkezés előtti legfeljebb 72 órás időbélyeget fogadja el. A 71 óránál régebbi rendeléseknél ezért a Pixel Manager egyáltalán nem küld `timestamp_micros` mezőt, és a GA4 a beérkezés idejére, gyakorlatilag a fizetés idejére rögzíti a vásárlást.
5. A GA4 Measurement Protocol általános korlátai, amelyeket egyetlen bővítményoldali változtatás sem szüntet meg.

Ezek közül csak az 1. pontot jelzi maga az `anon_*`, és ott is az érték a tünet, nem az ok. A „(not set)” javítása a böngészős azonosság visszaállítását jelenti a pénztárnál, nem azt, hogy a tartalék mást küldjön.

## Egy konkrét rendelés vizsgálata

1. A Pixel Managerben nyisd meg a **Support → Logger** részt, kapcsold be az **Enable logger** opciót, a naplószintet állítsd **Debug**-ra, és jelöld be a **Log HTTP requests** opciót. A részleteket a [Naplók](https://hub.hellowp.io/hu/plugins/woocommerce-pixel-manager/fejlesztoknek-naplok/) fejezetben találod. A HTTP-kérések naplózása 3 óra múlva magától kikapcsol.
2. Reprodukálj egy vásárlást, vagy várd meg az érintett rendelést.
3. Nyisd meg a naplófájlt a `/wp-content/uploads/wc-logs/` mappában. A fájlnevek `pmw-` előtaggal kezdődnek.
4. Keresd meg a GA4-kérés `json payload:` sorát, és jegyezd fel:
   - a `client_id` értéket, és hogy `anon_` kezdetű-e,
   - van-e `session_id`,
   - az esemény időbélyegét és a WooCommerce rendelés azonosítóját,
   - a utána következő válaszkódot,
   - a Pixel Manager verzióját.
5. Majd kövesd a döntési fát:

| Mit mutat a napló | Mit jelent | Mit tegyél |
|---|---|---|
| A `client_id` `anon_` kezdetű, nincs `session_id` | A böngészős azonosságot ennél a rendelésnél sosem rögzítették | Vizsgáld meg, miért hiányzott a `_ga` süti a pénztárnál: statisztikai hozzájárulás, az „always send server-side events” beállítás, iframe-es pénztár, reklámblokkolók vagy törölt sütik |
| A `client_id` így néz ki: `171933599.1747821527` | Az azonosságot helyesen rögzítették, az `anon_*` nem a probléma | Vizsgáld a munkamenet időzítését, a 72 órás korlátot és a GA4 feldolgozási késését |
| Egyáltalán nincs GA4-kérés, és van egy napló sor a hozzájárulási elnyomásról | A hozzájárulási kapu elnyomta az eseményt | Várt viselkedés, nincs teendő, hacsak nem akarod bekapcsolni az „always send” opciót |
| A kérést hibaválasszal naplózták | Konfigurációs vagy kapcsolati probléma | Ellenőrizd a mérési azonosítót, az API-titkot és a kimenő kapcsolatot |

A jelentésekből ne vonj le következtetést a GA4 feldolgozási késésének figyelembevétele nélkül. Ha percekkel a találat után hasonlítod össze a vásárlást a DebugView-ban vagy egy jelentésben, félrevezet.

## Mit küldj a támogatásnak

Ha a napló normális böngészős `client_id`-t és `session_id`-t mutat, és az attribúció mégis hiányzik, vagy `anon_*` értéket látsz olyan rendeléseken, ahol bizonyítani tudod, hogy a `_ga` süti létezett a pénztárnál, küldj kérést a támogatásnak ezekkel:

- a Pixel Manager, a WooCommerce és a WordPress verziója,
- az érintett rendelések azonosítói időbélyeggel és időzónával,
- hogy `anon_*` vagy böngészős GA4 kliensazonosító került a naplóba, és volt-e `session_id`,
- a vonatkozó naplófájl-hivatkozások (a naplózó panel „Copy log file links” gombjával),
- a hozzájárulás-kezelő platformod és beállítása, valamint az „always send server-side events” állapota,
- hogy ugyanezeknél a pénztáraknál látszanak-e a böngészőoldali GA4-kérések,
- a GA4 „(not set)” eredményét mutató képernyőkép vagy exportálás,
- hogy a probléma minden rendelést érint-e vagy csak egy részüket, és nagyjából mekkora hányadot.

Ne tegyél közzé teljes kliensazonosítókat, vásárlói adatokat, GA4 API-titkokat vagy szerkesztetlen naplófájlokat nyilvános csatornákon, például a WordPress támogatói fórumán. Ezekhez használj e-mailt, vagy a hozzáférés-védett naplófájl-hivatkozásokat.

## Gyakori kérdések

**Mikor állít elő a Pixel Manager `anon_*` GA4 kliensazonosítót?**
Csak akkor, ha szerveroldali GA4 Measurement Protocol üzenetet (vásárlás, teljes vagy részleges visszatérítés) állít össze, és az adott rendeléshez nem rögzítettek böngészős GA4 kliensazonosítót.

**Miért használ a Pixel Manager `anon_*` kliensazonosítót?**
Mert a GA4 Measurement Protocol minden üzenetben megköveteli a `client_id` mezőt. Helyőrző nélkül a kérés érvénytelen lenne, és a vásárlás a bevételével együtt teljesen kimaradna a GA4-ből.

**Az `anon_*` csak tartalék, ha a böngésző szokásos GA4 kliensazonosítója nem érhető el?**
Igen, csak ebben az esetben használatos.

**Használhatja a Pixel Manager az `anon_*` értéket, ha az eredeti GA4 kliensazonosító elérhető?**
Nem. Ha a rendeléshez rögzítettek kliensazonosítót, mindig azt használja. Nincs kivétel, beállítás vagy szűrő, amely a véletlen értéket részesítené előnyben a valódival szemben.

**Az `anon_*` GA4 kliensazonosító okoz „(not set)” attribúciót?**
Önmagában nem, és a különbség számít. Az `anon_*` azért használatos, mert a böngészős azonosság nem volt elérhető, és ugyanez a hiány akadályozza meg, hogy a GA4 a vásárlást az eredeti munkamenethez csatolja. Az `anon_*` találat nem fog hozzárendelődni, de a tartalék lecserélése mással nem javítaná az attribúciót, mert nincs elküldhető azonosság. Az `anon_*` a diagnosztikai jel, nem a hiba.

**Miért látok „(not set)” értéket a GA4-ben, ha a Measurement Protocol vásárlási kérés `HTTP 204` választ adott?**
Mert a `HTTP 204` csak azt jelenti, hogy a Google elfogadta a kérést. A befogadás, a tárolás, a munkamenethez csatolás és a forrás-attribúció négy különálló dolog, és a válaszkód csak az elsőt erősíti meg.

**Miért nem garantálja a `_ga_tracked=1` és a `wpm_google_analytics_4_mp_purchase_hit=1` a GA4 forrás, közeg és kampány attribúcióját?**
A `wpm_google_analytics_4_mp_purchase_hit` a kérés elküldése után azonnal íródik, a válasz ellenőrzése nélkül, kizárólag a dupla küldés megakadályozására. Azt rögzíti, hogy a Pixel Manager elvégezte a dolgát, nem azt, hogy a GA4 hozzárendelte az eredményt. A `_ga_tracked` egyáltalán nem Pixel Manager kulcs, ezért a jelentését az a bővítmény vagy integráció határozza meg, amely megírta.

**Hogyan ellenőrizhetem, hogy a Pixel Manager a böngésző GA4 kliensazonosítóját vagy `anon_*` tartalékot használt?**
Kapcsold be a naplózót Debug szinten a **Log HTTP requests** opcióval, majd olvasd a GA4-kérés `json payload:` sorát a `/wp-content/uploads/wc-logs/pmw-*.log` fájlokban. Lásd az „Egy konkrét rendelés vizsgálata” részt.

**Befolyásolhatja a sütihozzájárulás, a blokkolt tárhely vagy a böngésző adatvédelmi beállítása a Pixel Manager által küldött GA4 kliensazonosítót?**
Igen, közvetetten, mert azt határozzák meg, hogy létezik-e a rögzíthető `_ga` süti. Vedd észre az aszimmetriát: a statisztikai hozzájárulás megtagadása általában teljesen elnyomja a szerveroldali vásárlást, nem küld `anon_*` értéket. Hozzájárulás-korlátozott látogatásból csak akkor kapsz `anon_*` értéket, ha az „always send server-side events” be van kapcsolva. A blokkolt vagy törölt tárolás és az iframe-es pénztárak hozzájárulás nélkül is `anon_*` értéket adnak.