A GA4-es tulajdonod 4,180 vásárlást jelentett a múlt hónapban. A rendelési táblázatod 4,690-et mutat. Arra a kérdésre, hogy melyik a helyes, az őszinte válasz egyik sem, amíg meg nem tudod mondani, hová tűntek a hiányzó 510 rendelés. Ez nem a rendszerezés problémája. Minden kísérleti eredmény és minden priorizálási pontszám, amit létrehozol, egy ismeretlen mértékben és ismeretlen irányban hibás szám alapján kerül kiszámításra.
A Google egy nagy, nem mért szeletet normálisan kezel: a beleegyezési mód viselkedésmodellezése nem kapcsol be, amíg egy tulajdonság nem rögzíti a legalább 1,000 esemény naponta analytics_storage='denied' legalább 7 napigEz alatt a hiányzó adatok hiányoznak.
Ez azoknak szól, akik e-kereskedelmi csapatokban analitikai vagy konverzióvezérelt marketinggel foglalkoznak. A végére lesz egy egyeztető táblázatod, a hiányosságok felosztása megnevezett okokra, mindegyikhez teszttel, valamint egy toleranciaérték, amelyet meg tudsz védeni.
Mit mér valójában egy vásárlási egyeztetés?
Az egyeztetés nem azt jelenti, hogy „összeegyeztetjük a számokat”. Soha nem fognak megegyezni, és egy csapat, amelyik erre kényszeríti őket, általában valami rosszabbat tett, mint hogy magára hagyta a rést. Három kérdésre ad választ: mekkora a rést, mely elnevezett mechanizmusok hozzák létre, és mennyit lehet visszaszerezni és milyen áron. Minden kísérletezés előtt lefuttatjuk, mert egy olyan konverziós eseményen mért teszt, amely csendben elveszíti a megrendelések ismeretlen arányát, nem kísérlet.
1. lépés: két olyan tábla kiválasztása, amelyek a rendelésazonosító alapján összekapcsolhatók
Rendelésenként egy sorra van szükség, mindkét rendszerből, ugyanarra a naptártartományra, mindkét oldalon létező kulccsal.
- háttér: rendelésazonosító, létrehozási időbélyeg a tulajdon jelentési időzónájában, rendelési érték ugyanazon adó- és szállítási alapon, amelyet a GA4-ben konfigurált, fizetési mód, eszköz, ország, állapot.
- GA4: a BigQuery export, nem a felhasználói felület. Lekérdezés
purchaseeseményekecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, az eszköz kategóriája és a forgalom forrása.
Használja tudatosan a BigQuery-t. A beleegyezési módból származó modellezett adatok megjelennek a GA4 szabványos jelentéseiben és néhány felfedezésben, de a Google kijelenti, hogy azok... nem a BigQuery exportálásában, a közönségekben, a felhasználókeresőben, a kohorsz- vagy megtartásfeltárásokban, illetve a prediktív metrikákban. Hasonlítsa össze a felhasználói felületet a rendelési táblázattal, és egy becslést hasonlít össze egy ténnyel.
Ezután teljes külső illesztés a rendelésazonosítón. Most három tárolóed van: mindkettőben, csak a háttérben, csak a GA4-ben. A harmadik kisebb, de a leginkább diagnosztikai jellegű.
2. lépés: a rést háromféleképpen fejezd ki, ne egyként
Egyetlen havi százalék mindent elrejt. Számítsd ki mindhármat:
- Rendelésszám-különbség: (háttérrendelések mínusz a párosított GA4-vásárlások) / háttérrendelések. Ez elkülöníti a követési veszteséget.
- Bevételi rés: Ugyanez a számítás vonatkozik az értékre is. Ha a darabszámbeli különbség 3%, a bevételbeli különbség pedig 11%, akkor nem nyomon követési problémáról van szó, hanem értékmeghatározási problémáról (adó, szállítás, kedvezmények, valuta, ajándékkártyák).
- Napi rés variancia: Ábrázolja a napi rendelésszám-különbséget. Az egyenes vonal strukturális okot jelent, például beleegyezést vagy blokkolókat. A kiugró értékek telepítéseket, kampánykitöréseket vagy fizetési szolgáltatói incidenst jelenthetnek.
3. lépés: bontsd le a rést megnevezett okokra
Dolgozd végig ezt a táblázatot. Minden oknak van egy tesztje, amivel egy órán belül meg lehet erősíteni vagy ki lehet zárni azt.
| Okoz | Hogyan teszteljük | Aláírás az adatokban |
|---|---|---|
| Hozzájárulás megtagadva, a címke soha nem aktiválódik | Hasonlítsa össze a CMP hozzájárulási állapotnaplóját a GA4-munkamenetekkel ugyanazon időszakra vonatkozóan. | Stabil napi százalékos arány; az EU és a török forgalomra koncentrálódik |
| Hirdetés- és nyomkövetőblokkolók | Számolja a megerősítő URL-hez tartozó szervernapló-kérelmeket, és hasonlítsa össze az adott URL-hez tartozó GA4 vásárlási eseményekkel. | Ferdíti az asztali, Firefox és adatvédelmi böngészőket; idővel stabil |
| A megerősítő oldal soha nem töltődik be | A szervernaplókban számolja a csak a háttérben futó, de soha nem kért megerősítő URL-t tartalmazó rendeléseket. | Banki átirányításra és 3DS fizetési módokra koncentrál |
| Ismétlődő vásárlási események | GA4 vásárlási események számlálása transaction_id | A GA4 egyes napokon túllépi a backend határidejét; frissítse és nyomja vissza a nagy mennyiségű oldalt |
| A domainek közötti link hibás | Vizsgálja meg, hogy _gl túléli a fizetési szolgáltatótól való visszautat | A vásárlások új munkamenetekben jelennek meg, amelyeket a fizetési domainhez rendelnek hivatkozásként. |
| Süti élettartamának visszaállítása | Új felhasználók arányának szegmentálása böngésző szerint | Felfújt új felhasználók és közvetlen forgalom Safariban és iOS-en |
| Modellezett vs. nyers | Hasonlítsa össze a GA4 UI összesítéseket a BigQuery-vel azonos dátumtartomány esetén | A két Google-szám már azelőtt eltér, hogy megnyitnád a rendelési táblázatot. |
| Érték meghatározása | A háttérbeli bevétel újraszámítása adókkal, szállítással és kedvezményekkel, valamint azok nélkül | A számok egyeznek, a bevétel nem |
| Időzóna határ | Újra összesítés teljes hetekre | A heti részletességnél a rés nullához közelít |
Kettő fokozott törődést érdemel. transaction_id A deduplikáció csak webes streameken működik, alkalmazásstreameken nem, és a Google figyelmeztet, hogy egy üres karakterlánc küldése az Analytics duplikációmentesítését eredményezi. minden vásárlási eseményhordozó transaction_id=''Ez az egyetlen hiba szinte egy napot kiüríthet. Különben a nem kívánt hivatkozások listája adatfolyamonként 50 domainre van korlátozva, ami különösen akkor fontos, ha több elfogadót, tárcát és banki oldalt használsz.
[SZÜKSÉGES BELSŐ ADATOK: e kilenc ok megfigyelt eloszlása a Switas egyeztetési megbízások között, hogy az olvasók láthassák, melyek dominálnak általában.]
4. lépés: Állítson be egy olyan toleranciát, amelyet meg tud védeni
A Google nem tesz közzé elfogadható eltérési értéket, és a széles körben idézett „5% rendben van” kifejezés sem szerepel egyetlen Google-dokumentációban sem, amit találtunk. Állítson be sajátot, a felbontás függvényében, ne csak a szám alapján.
| Havi rendelésszám-különbség | Olvasás | Akció |
|---|---|---|
| Akár 2% | Időzóna-szélek és normál deduplikáció | Jegyezze fel az okokat, és negyedévente ellenőrizze újra |
| 2%-ról 5% | Csak akkor elfogadható, ha minden pontot egy megnevezett oknak tulajdonítanak. | Dokumentáld, majd folytasd a kísérletezést |
| 5%-ról 10% | Legalább egy strukturális ok nincs kijavítva | Javítsa ki, mielőtt abszolút konverziós számokra hagyatkozna |
| 10% felett | Nem alkalmas kísérletezésre | A GA4-vásárlások elsődleges kísérleti mutatóként való használatának leállítása a probléma megoldásáig |
Ezek a mi működési küszöbértékeink, nem iparági szabványok. A lényeg a megszorítás: egy megmagyarázatlan 3% rosszabb, mint egy megmagyarázott 8%.
5. lépés: Javítsa ki azt a sorrendet, amely óránként a legtöbb rendelést állítja helyre
- Értékdefiníció és időzóna. Konfiguráció, nem mérnöki munka, és általában egy délután.
- Ismétlődések és üres tranzakcióazonosítók. Egy adatréteg-javítás.
- Domainek közötti és nem kívánt hivatkozások. Konfiguráld mindkettőt, majd teszteld újra az élő fizetési visszatérési útvonalat, ne egy átmeneti útvonalat.
- Szerveroldali vásárlási esemény. Küldje el a vásárlást a rendelési rendszeréből a Measurement Protocol segítségével, a következő használatával:
client_ida webcímkéd generálódott. A Google-nak ezekre az eseményekre az eredeti kliensoldali esemény időbélyegétől számított 48 órán belül van szüksége, különben a hozzárendelés nem a várt módon kerül feldolgozásra. Ez az, ami helyreállítja a blokkolók és a soha meg nem jelenített megerősítő oldalak miatt elveszett rendeléseket. - Hozzájárulási architektúra. A leglassabb és leginkább politikai jellegű. A fennmaradó részt ismert, nagyságrendű, dokumentált hiányosságként kezeljük.
Mi változik, ha Törökországban vagy az EU-ban értékesítesz?
Két regionális tény mozgatja a számokat.
A hozzájárulás Törökországban is önkéntes alapon történik, de a Google biztonsági hálója nélkül. A török adatvédelmi hatóság a 2022/1358. számú (2022. december 23.) határozatában 300 000 líra bírságot szabott ki egy weboldal üzemeltetőjére, amiért jogalap nélkül futtatott hirdetési és marketing sütiket, és a nem létfontosságú sütik esetében aktív hozzájárulást írt elő. Számos török webhely válaszul egy olyan bannerrel válaszolt, amely közvetlenül blokkolja a Google-címkét, ahelyett, hogy beleegyezési módú jeleket küldene. Ez a megkülönböztetés költséges: modellezésre van szükség. analytics_storage='denied' események létezését. Egy semmit sem aktiváló banner nem ad a Google-nek semmit a modellezéshez, így az adatok elvesznek, nem pedig becslések.
A török 3DS csomagok postai úton küldik vissza a vásárlónak. Az iyzico segítségével a kereskedő egy dekódolt 3DS oldalt jelenít meg, majd az OTP megerősítése után az iyzico átirányít a kereskedő oldalára. callbackUrl ahol status, paymentId és a mdStatusA POST-vezérelt visszatérést pontosan az jelenti, amit a Google a domainek közötti mérés megszegésének nevez, mivel az átirányítások eltávolíthatják a _gl mielőtt a célállomásra berakodnak. Ha a különbség a kártyás fizetéseknél van, és az utánvétes fizetéseknél közel nulla, akkor ez az oka.
Két széles körben ismétlődő állítás, amit nem tudtunk ellenőrizni
„A Safari 7 napra korlátozza a belső sütik használatát.” Pontatlan. A WebKit dokumentációja szerint az ITP 7 nap elteltével törli a JavaScript sütiket és más szkriptekkel írható tárolóeszközöket. nincs felhasználói interakció, és külön 24 órára korlátozza a JavaScript sütiket, amikor a céloldalra egy titkosított domainről érkező linkdekoráció révén jutottak el. Simo Ahava tesztelése azt mutatta, hogy az óra a böngészőhasználat napjai alapján jár, nem pedig a naptári napok alapján, így egy visszatérő ügyfél akár egy hétnél is tovább birtokolhat azonosítót.
"5%-os eltérés elfogadható." Nem találtunk Google-forrást ehhez az adathoz. Beszállítói blogokban és fórumokon kering. Használd népmesélésként, ne küszöbértékként.
Ahol ez a módszer hibás
Nem terjed ki az alkalmazásstreamekre, ahol transaction_id A deduplikáció nem alkalmazható, illetve előfizetéses és részleges szállítási modellek esetén, ahol a „rendelés” nem egyetlen esemény. Nem tudja visszaállítani a beleegyezését megtagadó felhasználó azonosságát, csak a mennyiséget becsüli meg. Nem oldja meg a csatorna-hozzárendelést, ami egy különálló és nehezebb probléma. És feltételezi, hogy a rendelési táblázatod tiszta: ha a törölt és a csalás miatt blokkolt rendelések száma inkonzisztens a két oldalon, akkor egy olyan rést fogsz keresni, amely csak a lekérdezésedben létezik.
Gyakran Ismételt Kérdések
Milyen gyakran kellene ezt futtatnunk? Egyszer teljesen, majd egy napi résdiagrammal. Futtassa le újra a teljes felbontást minden fizetési, CMP-, fizetési szolgáltató- vagy címkekezelő-változás után.
Miért nem használom a GA4 felületet a BigQuery helyett? A felület tartalmazhat olyan modellezett felhasználókat és munkameneteket is, amelyeket az export nem tartalmaz, így a két Google-szám nem tér el egymástól. Egy becsléssel való egyeztetés lehetetlenné teszi a különbség felbontását.
Vajon a szerveroldali címkézés teljesen áthidalja a szakadékot? Nem. Helyreállítja a blokkolók és a soha meg nem jelenített megerősítő oldalak miatt elveszett rendeléseket. Nem állítja vissza azokat a felhasználókat, akik megtagadták a hozzájárulásukat.
A GA4 magasabb szintű, mint a backendünk. Lehetséges ez? Igen. Általában ismétlődő vásárlási események az oldalfrissítésekből, egy üres vagy újrafelhasznált oldalból. transaction_id, vagy a termelési területre irányuló átmeneti parancsok.
Vajon a beleegyezési mód megoldja a török beleegyezési rést? Részben. A letiltott jelek lehetővé teszik a modellezést, a Google mennyiségi küszöbértékeinek függvényében. A török szabályok értelmében ez nem helyettesíti a legális bannert.
Mi számít jó résnek? Olyan, ahol minden százalékpontnak neve van. A dokumentált 8% felülmúlja a megmagyarázatlan 3%-ot.
Újra kellene közölnünk a korábbi jelentéseket, miután ezt kijavítottuk? Nem. Jegyezze fel a javítás dátumát, és kezelje az időszakokat különálló sorozatként. A nyomon követett konverziók újbóli megadása tönkreteszi az auditnaplót.
Futtathatunk A/B teszteket, miközben a különbség meghaladja a 10%-ot? Futtasd le őket a tesztelőeszközön belül mért relatív mérőszámokon, de ne jelentsd a GA4 abszolút bevételre gyakorolt hatását, amíg a különbséget nem bontottad le.
Futtassa le ezt az egyeztetést a saját üzletében ebben a hónapban, vagy kérje meg elemző csapatunkat, hogy futtassa le Önnel és átadom neked a felbontást, a tűréshatárt és a javítási sorrendet.
Források
- [GA4] Viselkedésmodellezés beleegyezési módhoz, Google Analytics Súgó
- [GA4] Ismétlődő kulcsfontosságú események minimalizálása tranzakcióazonosítókkal, Google Analytics Súgó
- [GA4] Nem kívánt hivatkozások, Google Analytics Súgó
- [GA4] Több domainre kiterjedő mérés, Google Analytics Súgó
- Measurement Protocol események küldése a Google Analytics és a Google for Developers szolgáltatásba
- Hozzájárulási mód paraméterei, Google Tag Platform dokumentáció
- Követésmegelőzés a WebKitben
- Simo Ahava szerint eltávolították a JavaScript sütik lejárati korlátját a WebKit böngészőkben.
- KVKK Kurul karari 2022/1358, 2022. december 23
- 3DS implementáció, iyzico fejlesztői dokumentáció
