GA4-eiendommen din rapporterer 4,180 kjøp forrige måned. Bestillingstabellen din viser 4,690. Spurt om hva som er riktig, er det ærlige svaret ingen av delene, helt til du kan si hvor de manglende 510 bestillingene ble av. Dette er ikke et ryddighetsproblem. Hvert eksperimentresultat og hver prioriteringspoengsum du produserer, beregnes ut fra et tall som er feil med en ukjent mengde i en ukjent retning.
Google behandler en stor umålt del som normalt: atferdsmodellering for samtykkemodus slås ikke på før en egenskap registreres minst 1,000 hendelser per dag med analytics_storage='denied' i minst 7 dagerUnder det forblir manglende data manglende.
Dette er for alle som eier analyse eller CRO i et e-handelsteam. Til slutt vil du ha en avstemmingstabell, en dekomponering av gapet ditt i navngitte årsaker med en test for hver, og et toleransetall du kan forsvare.
Hva en kjøpsavstemming egentlig måler
En avstemming er ikke å «få tallene til å stemme». De vil aldri stemme, og et team som tvinger dem til det har vanligvis gjort noe verre enn å la gapet være i fred. Den svarer på tre spørsmål: hvor stort er gapet, hvilke navngitte mekanismer som produserer det, og hvor mye som kan gjenopprettes til hvilken kostnad. Vi kjører den før ethvert eksperiment, fordi en test målt på en konverteringshendelse som stille slipper en ukjent andel av ordrene ikke er et eksperiment.
Trinn 1: Hent to tabeller som kan slås sammen på ordre-ID
Du trenger én rad per ordre, fra begge systemene, for samme kalenderperiode, med en nøkkel som finnes på begge sider.
- backend: bestillings-ID, opprettet tidsstempel i eiendommens rapporteringstidssone, bestillingsverdi på samme skatte- og fraktbasis som du konfigurerte i GA4, betalingsmåte, enhet, land, status.
- GA4: BigQuery-eksporten, ikke brukergrensesnittet. Spørsmål
purchasearrangementer medecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, enhetskategori og trafikkilde.
Bruk BigQuery bevisst. Modellerte data fra samtykkemodus vises i GA4-standardrapporter og noen utforskninger, men Google oppgir at det er ikke i BigQuery-eksporten, målgrupper, brukerutforsker, kohort- eller retensjonsutforskninger eller prediktive beregninger. Sammenlign brukergrensesnittet med bestillingstabellen din, og du sammenligner et estimat med et faktum.
Deretter full outer join på ordre-ID. Du har nå tre bøtter: i begge, kun backend, kun GA4. Den tredje er mindre, men den mest diagnostiske.
Trinn 2: uttrykk gapet på tre måter, ikke én
En enkelt månedlig prosentandel skjuler alt. Beregn alle tre:
- Gap i antall ordrer: (backend-ordrer minus samsvarende GA4-kjøp) / backend-ordrer. Dette isolerer sporingstap.
- Inntektsgap: samme beregning på verdi. Hvis tellegapet er 3 % og inntektsgapet er 11 %, har du ikke et sporingsproblem, du har et verdidefinisjonsproblem (avgift, frakt, rabatter, valuta, gavekort).
- Daglig gapvarians: plott det daglige gapet mellom ordre og antall. En flat linje betyr en strukturell årsak, som samtykke eller blokkeringer. Topper betyr utrullinger, kampanjeutbrudd eller en hendelse hos betalingsleverandøren.
Trinn 3: Dekomponer gapet i navngitte årsaker
Arbeid deg nedover denne tabellen. Hver årsak har en test som kan bekrefte eller eliminere den på under en time.
| Årsak | Hvordan teste det | Signatur i dataene |
|---|---|---|
| Samtykke nektet, taggen utløses aldri | Sammenlign CMP-ens samtykkestatuslogg med GA4-økter for samme periode | Stabil daglig prosentandel; konsentrert i trafikken i EU og Tyrkia |
| Annonse- og sporingsblokkering | Tell serverloggforespørsler for bekreftelses-URL-en, sammenlign med GA4-kjøpshendelser på den URL-en | Skjevheter på skrivebordet, Firefox og nettlesere med personvern; stabilt over tid |
| Bekreftelsessiden lastes aldri inn | Tell kun backend-bestillinger der bekreftelses-URL-en aldri ble forespurt i serverloggene | Konsentrert på bankomdirigering og 3DS-betalingsmetoder |
| Dupliserte kjøpshendelser | Tell GA4-kjøpshendelser per transaction_id | GA4 overgår backend-funksjonen noen dager; sider med mye oppdatering og tilbakeknapping |
| Lenke på tvers av domener ødelagt | Inspiser om _gl overlever returreisen fra betalingsleverandøren | Kjøp lander i nye økter tilskrevet betalingsdomenet som en henvisning |
| Tilbakestilling av levetid for informasjonskapsler | Segmenter nybrukerrate etter nettleser | Oppblåste nye brukere og direkte trafikk på Safari og iOS |
| Modellert kontra rå | Sammenlign GA4 UI-totaler med BigQuery for en identisk datoperiode | De to Google-tallene stemmer ikke overens før du i det hele tatt åpner bestillingstabellen |
| Verdidefinisjon | Beregn backend-inntekter på nytt med og uten skatt, frakt og rabatter | Opptellingene stemmer overens, inntektene stemmer ikke |
| Tidssonegrense | Aggreger på nytt til hele uker | Gapet krymper mot null ved ukentlig granularitet |
To fortjener ekstra omsorg. transaction_id deduplisering fungerer bare på nettstrømmer, ikke appstrømmer, og Google advarer om at sending av en tom streng fører til deduplisering av Analytics hver kjøp arrangementsbæring transaction_id=''Den ene feilen kan slette mesteparten av en dag. Separat er listen over uønskede henvisninger begrenset til 50 domener per datastrøm, noe som er negativt hvis du bruker flere innløsere, lommebøker og banksider.
[INTERNE DATA NØDVENDIG: den observerte fordelingen av disse ni årsakene på tvers av Switas-forliksoppdrag, slik at leserne kan se hvilke som vanligvis dominerer.]
Trinn 4: Sett en toleranse du kan forsvare
Google publiserer ingen akseptable avvikstall, og den mye siterte «5 % er greit»-tallsstatistikken vises ikke i noen Google-dokumentasjon vi kunne finne. Sett din egen, betinget av dekomponering snarere enn bare tallet.
| Månedlig gap i ordreantall | Lesning | Handling |
|---|---|---|
| Opptil 2% | Tidssonegrenser og normal deduplisering | Registrer årsakene, sjekk på nytt hvert kvartal |
| 2% til 5% | Kun akseptabelt hvis hvert poeng tilskrives en navngitt årsak | Dokumenter, og fortsett deretter med eksperimentering |
| 5% til 10% | Minst én strukturell årsak er uløst | Fiks før du stoler på absolutte konverteringstall |
| Over 10% | Ikke egnet for eksperimentering | Slutt å bruke GA4-kjøp som primær eksperimentberegning inntil dette er løst |
Dette er våre driftsterskler, ikke en bransjestandard. Poenget er kvalifiseringen: uforklarlige 3 % er verre enn forklarte 8 %.
Trinn 5: fiks i rekkefølgen som gjenoppretter flest ordrer per arbeidstime
- Verdidefinisjon og tidssone. Konfigurasjon, ikke prosjektering, og vanligvis en ettermiddag.
- Duplikater og tomme transaksjons-ID-er. Én dataLayer-rettelse.
- Henvisninger på tvers av domener og uønskede henvisninger. Konfigurer begge, og test deretter den aktive betalingsreturveien på nytt, ikke en midlertidig løsning.
- Kjøpshendelse på serversiden. Send kjøpet fra bestillingssystemet ditt med måleprotokollen, ved hjelp av
client_iddin genererte webtag. Google krever at disse hendelsene skjer innen 48 timer etter det opprinnelige tidsstempelet for klientsiden, ellers kan det hende at attribusjonen ikke behandles som forventet. Dette gjenoppretter ordrer som er tapt på grunn av blokkeringer og bekreftelsessider som aldri ble gjengitt. - Samtykkearkitektur. Den tregeste og mest politiske. Behandle resten som et kjent, stort og dokumentert gap.
Hva endres hvis du selger i Tyrkia eller EU
To regionale fakta endrer tallene.
Samtykke er også valgfritt i Tyrkia, men uten Googles sikkerhetsnett. Den tyrkiske datatilsynet ga en nettstedsoperatør en bot på 300 000 TL i avgjørelse 2022/1358 (23. desember 2022) for å ha kjørt reklame- og markedsføringskapsler uten juridisk grunnlag, og krevde aktiv påmelding for ikke-essensielle informasjonskapsler. Mange tyrkiske nettsteder svarte med et banner som blokkerer Google-taggen fullstendig i stedet for et som sender samtykkesignaler. Dette skillet er dyrt: modellering trenger analytics_storage='denied' hendelser eksisterer. Et banner som ikke utløser noe gir Google ingenting å modellere fra, så dataene er borte i stedet for estimert.
Tyrkiske 3DS-leveringer returneres til kjøperen via POST. Med iyzico gjengir selgeren en dekodet 3DS-side, og etter OTP-bekreftelse omdirigerer iyzico til selgerens callbackUrl med status, paymentId og mdStatusEn POST-drevet retur er akkurat det Google kaller en løsning som bryter måling på tvers av domener, siden viderekoblinger kan fjerne _gl før destinasjonen lastes. Hvis gapet ditt er i kortbetalinger og er nesten null for kontant ved levering, er dette grunnen.
To mye gjentatte påstander vi ikke kunne bekrefte
«Safari setter en grense på 7 dager for førsteparts informasjonskapsler.» Upresist. WebKits dokumentasjon sier at ITP sletter JavaScript-informasjonskapsler og annen skriptskrivbar lagring etter 7 dager. ingen brukerinteraksjon, og begrenser separat JavaScript-informasjonskapsler til 24 timer når landingssiden ble nådd via lenkedekorasjon fra et klassifisert domene. Simo Ahavas testing fant at klokken går på dager med nettleserbruk, ikke kalenderdager, slik at en tilbakevendende kunde kan ha en identifikator godt utover en uke.
«Et avvik på 5 % er akseptabelt.» Vi fant ingen Google-kilde for dette tallet. Det sirkulerer gjennom leverandørblogger og forumsvar. Bruk det som folklore, ikke som en terskel.
Hvor denne metoden bryter sammen
Den dekker ikke appstrømmer, der transaction_id Deduplisering gjelder ikke, eller abonnements- og delforsendelsesmodeller, der «en bestilling» ikke er én hendelse. Den kan ikke gjenopprette identiteten til en bruker som har nektet samtykke, bare estimere volumet. Den fikser ikke kanaltatribusjon, et separat og vanskeligere problem. Og den forutsetter at bestillingstabellen din er ren: hvis kansellerte og svindelblokkerte bestillinger telles inkonsekvent på de to sidene, vil du jage etter et gap som bare finnes i spørringen din.
Ofte stilte spørsmål
Hvor ofte bør vi kjøre dette? Fullstendig én gang, deretter et daglig gap-diagram. Kjør den fullstendige dekomponeringen på nytt etter eventuelle endringer i kassen, CMP-en, betalingsleverandøren eller tag-manageren.
Hvorfor ikke bruke GA4-grensesnittet i stedet for BigQuery? Grensesnittet kan inkludere modellerte brukere og økter som eksporten ikke inkluderer, slik at de to Google-tallene stemmer ikke overens med hverandre. Avstemming mot et estimat gjør det umulig å dekomponere gapet.
Vil tagging på serversiden tette gapet fullstendig? Nei. Den gjenoppretter ordrer som er tapt på grunn av blokkeringer og bekreftelsessider som aldri ble gjengitt. Den gjenoppretter ikke brukere som nektet samtykke.
GA4 er høyere enn backend-systemet vårt. Er det mulig? Ja. Vanligvis dupliserte kjøpshendelser fra sideoppdateringer, en tom eller gjenbrukt side transaction_id, eller iscenesettelsesordrer som avfyres inn i produksjonsområdet.
Løser samtykkemodusen det tyrkiske samtykkegapet? Delvis. Avviste signaler gjør modellering mulig, underlagt Googles volumgrenser. Det er ikke en erstatning for et lovlig banner i henhold til tyrkiske regler.
Hva teller som et godt mellomrom? En der hvert prosentpoeng har et navn. Dokumenterte 8 % slår uforklarlige 3 %.
Bør vi omformulere historiske rapporter etter at vi har fikset dette? Nei. Anmerk fikseringsdatoen og behandle periodene som separate serier. Å gjenta sporede konverteringer ødelegger revisjonssporet.
Kan vi kjøre A/B-tester mens gapet er over 10 %? Kjør dem på relative målinger målt i testverktøyet, men ikke rapporter absolutt inntektspåvirkning fra GA4 før gapet er dekomponert.
Kjør denne avstemmingen i din egen butikk denne måneden, eller få analyseteamet vårt til å kjøre det sammen med deg og gi deg dekomponeringen, toleransen og fikseringsrekkefølgen.
Kilder
- [GA4] Atferdsmodellering for samtykkemodus, Google Analytics Hjelp
- [GA4] Minimer dupliserte viktige hendelser med transaksjons-ID-er, Hjelp med Google Analytics
- [GA4] Uønskede henvisninger, Google Analytics-hjelp
- [GA4] Måling på tvers av domener, Hjelp med Google Analytics
- Send Measurement Protocol-hendelser til Google Analytics og Google for utviklere
- Parametere for samtykkemodus, dokumentasjon for Google Tag Platform
- Sporingsforebygging i WebKit
- Utløpsgrense fjernet fra JavaScript-informasjonskapsler i WebKit-nettlesere, Simo Ahava
- KVKK Kurul karari 2022/1358, 23. desember 2022
- 3DS-implementering, iyzico-utviklerdokumentasjon
