GA4 anon_* kliensazonosítók

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