Din GA4-ejendom rapporterer 4,180 køb sidste måned. Din ordretabel viser 4,690. Adspurgt om, hvad der er rigtigt, er det ærlige svar ingen af delene, indtil du kan sige, hvor de manglende 510 ordrer blev af. Dette er ikke et ryddelighedsproblem. Hvert eksperimentresultat og hver prioriteringsscore, du producerer, beregnes ud fra et tal, der er forkert med en ukendt mængde i en ukendt retning.
Google behandler en stor, umålt del som normalt: Adfærdsmodellering for samtykketilstand aktiveres ikke, før en ejendom registreres. mindst 1,000 arrangementer om dagen med analytics_storage='denied' i mindst 7 dageDerunder forbliver manglende data manglende.
Dette er for alle, der ejer analyser eller CRO i et e-handelsteam. Til sidst vil du have en afstemningstabel, en opdeling af dit gab i navngivne årsager med en test for hver, og et tolerancetal, du kan forsvare.
Hvad en købsafstemning egentlig måler
En afstemning er ikke "få tallene til at stemme overens". De vil aldrig stemme overens, og et team, der tvinger dem til det, har normalt gjort noget værre end at lade forskellen være. Den besvarer tre spørgsmål: hvor stor er forskellen, hvilke navngivne mekanismer der producerer den, og hvor meget kan inddrives til hvilken pris. Vi kører den før enhver eksperimentel engagement, fordi en test målt på en konverteringshændelse, der lydløst dropper en ukendt andel af ordrer, ikke er et eksperiment.
Trin 1: Hent to tabeller, der kan forbindes på ordre-ID
Du skal bruge én række pr. ordre, fra begge systemer, for det samme kalenderinterval, med en nøgle, der findes på begge sider.
- Backend: Ordre-ID, oprettet tidsstempel i ejendommens rapporteringstidszone, ordreværdi på samme moms- og forsendelsesbasis, som du konfigurerede i GA4, betalingsmetode, enhed, land, status.
- GA4: BigQuery-eksporten, ikke brugergrænsefladen. Forespørgsel
purchasebegivenheder medecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, enhedskategori og trafikkilde.
Brug BigQuery bevidst. Modellerede data fra samtykketilstand vises i GA4-standardrapporter og nogle udforskninger, men Google angiver, at det er ikke i BigQuery-eksporten, målgrupper, brugerudforsker, kohorte- eller fastholdelsesudforskninger eller prædiktive metrics. Sammenlign brugergrænsefladen med din ordretabel, og du sammenligner et estimat med en kendsgerning.
Derefter fuld outer join på ordre-ID. Du har nu tre buckets: i begge, kun backend, kun GA4. Den tredje er mindre, men den mest diagnostiske.
Trin 2: Udtryk forskellen på tre måder, ikke én
En enkelt månedlig procentdel skjuler alt. Beregn alle tre:
- Forskel i ordreantal: (backend-ordrer minus matchede GA4-køb) / backend-ordrer. Dette isolerer sporingstab.
- Indtægtsforskel: den samme beregning på værdi. Hvis forskellen i optælling er 3 %, og forskellen i omsætning er 11 %, har du ikke et sporingsproblem, men et problem med værdidefinitionen (skat, forsendelse, rabatter, valuta, gavekort).
- Daglig gapvarians: plot det daglige forskel i ordreantal. En flad linje betyder en strukturel årsag, såsom samtykke eller blokeringer. Spikes betyder implementeringer, kampagneudbrud eller en hændelse hos betalingsudbyderen.
Trin 3: Opdel hullet i navngivne årsager
Arbejd ned ad denne tabel. Hver årsag har en test, der kan bekræfte eller eliminere den på under en time.
| Årsag | Sådan testes det | Underskrift i dataene |
|---|---|---|
| Samtykke nægtet, tag aktiveres aldrig | Sammenlign din CMP's samtykkestatuslog med GA4-sessioner for samme periode | Stabil daglig procentdel; koncentreret i EU- og Tyrkiets trafik |
| Annonce- og tracker-blokkere | Tæl serverlogforespørgsler for bekræftelses-URL'en, og sammenlign med GA4-købshændelser på den URL | Skråner desktop, Firefox og privatlivsbrowsere; stabilt over tid |
| Bekræftelsessiden indlæses aldrig | Tæl kun backend-ordrer, hvis bekræftelses-URL aldrig blev anmodet om i serverlogfiler | Koncentreret om bankomdirigering og 3DS-betalingsmetoder |
| Duplikerede købshændelser | Tæl GA4-købshændelser pr. transaction_id | GA4 overgår backend på nogle dage; sider med mange opdaterings- og tilbageknapknapper |
| Link på tværs af domæner er ødelagt | Undersøg om _gl overlever returrejsen fra betalingsudbyderen | Køb lander i nye sessioner tilskrevet betalingsdomænet som en henvisning |
| Nulstilling af cookielevetid | Segmentér antallet af nye brugere efter browser | Oppustede nye brugere og direkte trafik på Safari og iOS |
| Modelleret versus rå | Sammenlign GA4 UI-totaler med BigQuery for et identisk datointerval | De to Google-numre stemmer ikke overens, før du overhovedet åbner ordretabellen |
| Værdi definition | Genberegn backend-indtægter med og uden moms, fragt og rabatter | Optællinger stemmer overens, omsætning ikke |
| Tidszonegrænse | Aggreger igen til hele uger | Forskellen krymper mod nul ved ugentlig granularitet |
To fortjener ekstra omsorg. transaction_id Deduplikering fungerer kun på webstreams, ikke appstreams, og Google advarer om, at afsendelse af en tom streng får Analytics til at deduplikere hver køb af eventbæring transaction_id=''Den ene fejl kan slette det meste af en dag. Separat er listen over uønskede henvisninger begrænset til 50 domæner pr. datastrøm, hvilket er en ulempe, hvis du bruger flere indløsere, tegnebøger og banksider.
[INTERNE DATA NØDVENDIGE: den observerede fordeling af disse ni årsager på tværs af Switas-afstemningsaftaler, så læserne kan se, hvilke der normalt dominerer.]
Trin 4: Indstil en tolerance, du kan forsvare
Google offentliggør intet acceptabelt uoverensstemmelsestal, og det bredt citerede "5% er fint" optræder ikke i nogen Google-dokumentation, vi kunne finde. Angiv din egen, betinget af dekomponering snarere end udelukkende på tallet.
| Månedligt forskel i ordreantal | Læsning | Handling |
|---|---|---|
| Op til 2% | Tidszonegrænser og normal deduplikering | Registrer årsagerne, og tjek igen hvert kvartal |
| 2% til 5% | Kun acceptabelt, hvis hvert point tilskrives en navngiven årsag | Dokumentér, og fortsæt derefter med eksperimentering |
| 5% til 10% | Mindst én strukturel årsag er uafklaret | Rettelse før tillid til absolutte konverteringstal |
| Over 10% | Ikke egnet til eksperimenter | Stop med at bruge GA4-køb som den primære eksperimentmåling, indtil problemet er løst |
Dette er vores driftsgrænser, ikke en branchestandard. Pointen er kvalifikationen: uforklarlige 3% er værre end forklarede 8%.
Trin 5: Rettelse i den ordre, der genvinder flest ordrer pr. arbejdstime
- Værdifinition og tidszone. Konfiguration, ikke ingeniørarbejde, og normalt en eftermiddag.
- Dubletter og tomme transaktions-ID'er. Én rettelse af dataLayer.
- Henvisninger på tværs af domæner og uønskede henvisninger. Konfigurer begge, og test derefter den live betalingsretursti igen, ikke en faseopdelt sti.
- Købsbegivenhed på serversiden. Send købet fra dit ordresystem med måleprotokollen ved hjælp af
client_idDit webtag genererede. Google kræver, at disse hændelser udføres inden for 48 timer efter det oprindelige tidsstempel for klientsidens hændelser, ellers behandles tilskrivningen muligvis ikke som forventet. Dette er det, der gendanner ordrer, der er gået tabt på grund af blokkere og bekræftelsessider, der aldrig blev gengivet. - Samtykkearkitektur. Den langsomste og mest politiske. Behandl resten som et kendt, dimensioneret, dokumenteret hul.
Hvad ændrer sig, hvis du sælger i Tyrkiet eller EU
To regionale fakta ændrer tallene.
Samtykke er også tilvalg i Tyrkiet, men uden Googles sikkerhedsnet. Den tyrkiske databeskyttelsesmyndighed idømte en hjemmesideoperatør en bøde på 300,000 TL i afgørelse 2022/1358 (23. december 2022) for at køre reklame- og marketingcookies uden et juridisk grundlag og krævede aktiv tilmelding til ikke-essentielle cookies. Mange tyrkiske websteder svarede med et banner, der blokerer Google-tagget fuldstændigt i stedet for et, der sender samtykkesignaler. Denne sondring er dyr: modellering kræver analytics_storage='denied' hændelser eksisterer. Et banner, der ikke udløser noget, giver Google intet at modellere ud fra, så dataene er væk i stedet for estimeret.
Tyrkiske 3DS-leverancer returneres til køberen med POST. Med iyzico gengiver forhandleren en afkodet 3DS-side, og efter OTP-bekræftelse omdirigerer iyzico til forhandlerens callbackUrl med status, paymentId og mdStatusEn POST-drevet retur er præcis, hvad Google kalder en løsning, der bryder cross-domain-målinger, da omdirigeringer kan fjerne _gl før destinationen indlæses. Hvis dit mellemrum er i kortbetalinger og er næsten nul for kontant ved levering, er det derfor.
To gentagne påstande, som vi ikke kunne bekræfte
"Safari begrænser førstepartscookies til 7 dage." Upræcis. WebKits dokumentation siger, at ITP sletter JavaScript-cookies og anden script-skrivbar lagring efter 7 dages brug. ingen brugerinteraktion, og begrænser separat JavaScript-cookies til 24 timer, når landingssiden blev nået via linkdekoration fra et klassificeret domæne. Simo Ahavas test viste, at uret kører på dage med browserbrug, ikke kalenderdage, så en tilbagevendende kunde kan have et id langt ud over en uge.
"En forskel på 5% er acceptabel." Vi fandt ingen Google-kilde til dette tal. Det cirkulerer gennem leverandørers blogs og forumsvar. Brug det som folklore, ikke som en tærskel.
Hvor denne metode bryder sammen
Det dækker ikke app-streams, hvor transaction_id Deduplikering gælder ikke, eller abonnements- og delvise forsendelsesmodeller, hvor "en ordre" ikke er én begivenhed. Den kan ikke gendanne en brugers identitet, der har fået afvist samtykke, kun estimere volumen. Den løser ikke kanalattribution, et separat og vanskeligere problem. Og den antager, at din ordretabel er ren: hvis annullerede og svindelblokerede ordrer tælles inkonsistent på de to sider, vil du jagte et hul, der kun findes i din forespørgsel.
Ofte stillede spørgsmål
Hvor ofte skal vi køre dette? En komplet diagram, derefter et dagligt gap-diagram. Kør den fulde opdeling igen efter enhver ændring af checkout, CMP, betalingsudbyder eller tag manager.
Hvorfor ikke bruge GA4-grænsefladen i stedet for BigQuery? Grænsefladen kan inkludere modellerede brugere og sessioner, som eksporten ikke inkluderer, så de to Google-tal stemmer ikke overens med hinanden. Afstemning mod et estimat gør det umuligt at opdele forskellen.
Vil server-side tagging lukke hullet fuldstændigt? Nej. Den gendanner ordrer, der er gået tabt på grund af blokeringer og bekræftelsessider, der aldrig blev gengivet. Den gendanner ikke brugere, der har nægtet samtykke.
GA4 er højere end vores backend. Er det muligt? Ja. Normalt duplikerer købshændelser fra sideopdateringer, en tom eller genbrugt side transaction_ideller iscenesættelse af ordrer, der affyres ind i produktionsejendommen.
Løser samtykkefunktionen det tyrkiske samtykkehul? Delvist. Afviste signaler muliggør modellering, underlagt Googles volumengrænser. Det er ikke en erstatning for et lovligt banner i henhold til tyrkiske regler.
Hvad tæller som et godt mellemrum? En hvor hver procent har et navn. Dokumenterede 8% slår uforklarlige 3%.
Skal vi gentage historiske rapporter efter at have rettet dette? Nej. Anmærk fastsættelsesdatoen, og behandl perioderne som separate serier. Gentagelse af sporede konverteringer ødelægger revisionssporet.
Kan vi køre A/B-tests, mens forskellen er over 10%? Kør dem på relative metrikker målt i testværktøjet, men rapporter ikke den absolutte omsætningspåvirkning fra GA4, før gabet er dekomponeret.
Kør denne afstemning i din egen butik denne måned, eller Få vores analyseteam til at køre det sammen med dig og give dig dekomponeringen, tolerancen og fixrækkefølgen.
Kilder
- [GA4] Adfærdsmodellering for samtykketilstand, Hjælp til Google Analytics
- [GA4] Minimer dubletter af nøglehændelser med transaktions-id'er, Hjælp til Google Analytics
- [GA4] Uønskede henvisninger, Hjælp til Google Analytics
- [GA4] Måling på tværs af domæner, Hjælp til Google Analytics
- Send Measurement Protocol-hændelser til Google Analytics og Google for Developers
- Parametre for samtykketilstand, dokumentation for Google Tag Platform
- Sporingsforebyggelse i WebKit
- Udløbsgrænse fjernet fra JavaScript-cookies i WebKit-browsere, Simo Ahava
- KVKK Kurul karari 2022/1358, 23. december 2022
- 3DS-implementering, iyzico-udviklerdokumentation
