Din GA4-egendom rapporterar 4 180 köp förra månaden. Din ordertabell visar 4 690. På frågan om vilket som är rätt är det ärliga svaret ingetdera, tills du kan säga vart de saknade 510 ordrarna tog vägen. Detta är inte ett städproblem. Varje experimentresultat och varje prioriteringspoäng du producerar beräknas på ett tal som är fel med ett okänt belopp i en okänd riktning.
Google behandlar en stor, ouppmätt del som normalt: beteendemodellering för samtyckesläge aktiveras inte förrän en egendom registreras. minst 1 000 händelser per dag med analytics_storage='denied' i minst 7 dagarNedanför detta förblir saknade data saknade.
Detta är för alla som ansvarar för analys eller CRO på ett e-handelsteam. I slutet kommer ni att ha en avstämningstabell, en uppdelning av ert gap i namngivna orsaker med ett test för varje, och en toleransnivå ni kan försvara.
Vad en inköpsavstämning faktiskt mäter
En avstämning är inte "få siffrorna att stämma". De kommer aldrig att stämma, och ett team som tvingar dem att göra det har oftast gjort något värre än att lämna gapet ifred. Den besvarar tre frågor: hur stort är gapet, vilka namngivna mekanismer som producerar det, och hur mycket som kan återvinnas till vilken kostnad. Vi kör den innan vi genomför något experiment, eftersom ett test som mäts på en konverteringshändelse som tyst tappar en okänd andel ordrar inte är ett experiment.
Steg 1: hämta två tabeller som kan kopplas samman med order-ID
Du behöver en rad per beställning, från båda systemen, för samma kalenderintervall, med en nyckel som finns på båda sidor.
- backend: order-ID, skapad tidsstämpel i egendomens rapporteringstidszon, ordervärde på samma moms- och fraktbasis som du konfigurerade i GA4, betalningsmetod, enhet, land, status.
- GA4: BigQuery-exporten, inte användargränssnittet. Fråga
purchaseevenemang medecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, enhetskategori och trafikkälla.
Använd BigQuery medvetet. Modellerad data från samtyckesläget visas i GA4-standardrapporter och vissa utforskningar, men Google uppger att det är inte i BigQuery-exporten, målgrupper, användarutforskare, kohort- eller retentionsutforskningar eller prediktiva mätvärden. Jämför användargränssnittet med din ordertabell så jämför du en uppskattning med ett faktum.
Sedan full outer join på order-ID. Du har nu tre buckets: i båda, endast backend, endast GA4. Den tredje är mindre men den mest diagnostiska.
Steg 2: uttryck skillnaden på tre sätt, inte ett
En enda månatlig procentsats döljer allt. Beräkna alla tre:
- Skillnad mellan orderantal och antal: (backend-ordrar minus matchade GA4-köp) / backend-ordrar. Detta isolerar spårningsförlust.
- Inkomstgap: samma beräkning på värde. Om skillnaden i antal är 3 % och skillnaden i intäkter är 11 % har du inget spårningsproblem, du har ett problem med värdedefinitionen (skatt, frakt, rabatter, valuta, presentkort).
- Daglig gapvarians: Rita det dagliga gapet mellan orderantal och antal. En rak linje betyder en strukturell orsak, såsom samtycke eller blockeringar. Toppar betyder utrullningar, kampanjutbrott eller en incident hos betalningsleverantören.
Steg 3: dela upp gapet i namngivna orsaker
Räkna ut den här tabellen. Varje orsak har ett test som kan bekräfta eller eliminera den på under en timme.
| Orsak | Hur man testar det | Signatur i uppgifterna |
|---|---|---|
| Samtycke nekas, taggen aktiveras aldrig | Jämför din CMP:s logg för samtyckesstatus med GA4-sessioner under samma period | Stabil daglig andel; koncentrerad till trafik inom EU och Turkiet |
| Annons- och spårningsblockerare | Räkna serverloggförfrågningar för bekräftelse-URL:en, jämför med GA4-köphändelser på den URL:en | Skevgör skrivbord, Firefox och sekretesswebbläsare; stabilt över tid |
| Bekräftelsesidan laddas aldrig | Räkna endast backend-order vars bekräftelse-URL aldrig begärdes i serverloggar | Koncentrerad på bankomdirigering och 3DS-betalningsmetoder |
| Duplicerade köphändelser | Räkna GA4-köphändelser per transaction_id | GA4 överträffar backend vissa dagar; sidor med många uppdateringar och bakåtknappar |
| Länk mellan domäner trasig | Kontrollera om _gl överlever återresan från betalningsleverantören | Köp landar i nya sessioner som tillskrivs betalningsdomänen som en remiss |
| Återställning av cookielivstid | Segmentera andelen nya användare efter webbläsare | Uppblåsta nya användare och direkt trafik på Safari och iOS |
| Modellerad kontra rå | Jämför GA4 UI-totaler med BigQuery för ett identiskt datumintervall | De två Google-siffrorna stämmer inte överens innan du ens öppnar ordertabellen |
| Värdedefinition | Omräkna backend-intäkter med och utan moms, frakt och rabatter | Siffrorna stämmer, intäkterna stämmer inte |
| Tidszonsgräns | Aggregera om till hela veckor | Gapet krymper mot noll vid veckovis granularitet |
Två förtjänar extra omsorg. transaction_id deduplicering fungerar endast på webbströmmar, inte appströmmar, och Google varnar för att om man skickar en tom sträng dedupliceras Analytics. varje köp evenemangstransport transaction_id=''Den där buggen kan radera större delen av en dag. Separat är listan över oönskade hänvisningar begränsad till 50 domäner per dataström, vilket är svårt om du använder flera inlösare, plånböcker och banksidor.
[INTERNA DATA BEHÖVS: den observerade fördelningen av dessa nio orsaker över Switas avstämningsuppdrag, så att läsarna kan se vilka som vanligtvis dominerar.]
Steg 4: sätt en tolerans som du kan försvara
Google publicerar ingen acceptabel avvikelsetal, och det allmänt citerade "5 % är okej" förekommer inte i någon Google-dokumentation vi kunde hitta. Sätt din egen, villkorad av dekomposition snarare än enbart på siffran.
| Månatligt gap i orderantal | Läsning | Handling |
|---|---|---|
| Upp till 2% | Tidszonsgränser och normal deduplicering | Registrera orsakerna, kontrollera igen varje kvartal |
| 2% till 5% | Endast godtagbart om varje poäng tillskrivs en namngiven orsak | Dokumentera och fortsätt sedan med experimentet |
| 5% till 10% | Åtminstone en strukturell orsak är ouppklarad | Åtgärda innan du litar på absoluta konverteringssiffror |
| Över 10% | Ej lämplig för experiment | Sluta använda GA4-köp som primärt experimentmått tills det är åtgärdat |
Det här är våra operativa tröskelvärden, inte en branschstandard. Kvalificeringen är poängen: oförklarade 3 % är sämre än förklarade 8 %.
Steg 5: fixa i den ordning som återställer flest ordrar per arbetstimme
- Värdefinition och tidszon. Konfiguration, inte teknik, och vanligtvis en eftermiddag.
- Dubbletter och tomma transaktions-ID:n. En dataLayer-fix.
- Domänöverskridande och oönskade hänvisningar. Konfigurera båda och testa sedan om returvägen för livebetalningar, inte en mellanliggande väg.
- Köphändelse på serversidan. Skicka köpet från ditt ordersystem med mätprotokollet, med hjälp av
client_iddin webbtagg genererades. Google kräver att dessa händelser sker inom 48 timmar från den ursprungliga tidsstämpeln för klientsidans händelse, annars kanske attributionen inte behandlas som förväntat. Det är detta som återställer ordrar som förlorats på grund av blockerare och bekräftelsesidor som aldrig renderades. - Samtyckesarkitektur. Den långsammaste och mest politiska. Behandla resten som ett känt, dimensionerat, dokumenterat gap.
Vad som ändras om du säljer i Turkiet eller EU
Två regionala fakta påverkar siffrorna.
Samtycke är frivilligt även i Turkiet, men utan Googles skyddsnät. Den turkiska dataskyddsmyndigheten bötfällde en webbplatsoperatör med 300 000 TL i beslut 2022/1358 (23 december 2022) för att ha kört reklam- och marknadsföringscookies utan rättslig grund och krävde aktivt deltagande för icke-nödvändiga cookies. Många turkiska webbplatser svarade med en banner som blockerar Google-taggen helt istället för en som skickar samtyckessignaler. Den skillnaden är dyr: modellering behöver... analytics_storage='denied' händelser att existera. En banner som inte aktiverar någonting ger Google inget att modellera utifrån, så data är borta snarare än uppskattade.
Turkiska 3DS-flöden returnerar köparen via POST. Med iyzico renderar handlaren en avkodad 3DS-sida och, efter OTP-bekräftelse, omdirigerar iyzico till handlarens callbackUrl med status, paymentId och mdStatusEn POST-driven retur är precis vad Google kallar för att bryta mätning över flera domäner, eftersom omdirigeringar kan strippa _gl innan destinationen laddas. Om ditt gap är i kortbetalningar och är nära noll för postförskott, är det därför.
Två ofta upprepade påståenden som vi inte kunde verifiera
"Safari begränsar förstapartscookies till 7 dagar." Oprecis. WebKits dokumentation säger att ITP tar bort JavaScript-cookies och annan skriptskrivbar lagring efter 7 dagar av ingen användarinteraktion, och begränsar separat JavaScript-cookies till 24 timmar när landningssidan nåddes via länkdekoration från en sekretessbelagd domän. Simo Ahavas tester visade att klockan går på dagar då webbläsaren användes, inte kalenderdagar, så en återkommande kund kan ha en identifierare långt längre än en vecka.
"En skillnad på 5 % är acceptabel." Vi hittade ingen Google-källa för denna siffra. Den cirkulerar via leverantörsbloggar och forumsvar. Använd den som folklore, inte som ett tröskelvärde.
Där den här metoden bryts ner
Det täcker inte appströmmar, där transaction_id Deduplicering gäller inte, eller prenumerations- och delleveransmodeller, där "en beställning" inte är en enda händelse. Den kan inte återställa en användares identitet med nekat samtycke, utan bara uppskatta volymen. Den åtgärdar inte kanalattribution, ett separat och svårare problem. Och den förutsätter att din beställningstabell är ren: om avbrutna och bedrägeriblockerade beställningar räknas inkonsekvent på båda sidorna, kommer du att jaga ett gap som bara finns i din fråga.
Vanliga frågor och svar
Hur ofta ska vi köra detta? Heltäckande en gång, sedan ett dagligt gapdiagram. Kör den fullständiga uppdelningen igen efter varje ändring av utcheckning, CMP, betalningsleverantör eller tagghantering.
Varför inte använda GA4-gränssnittet istället för BigQuery? Gränssnittet kan inkludera modellerade användare och sessioner som exporten inte gör, så de två Google-siffrorna stämmer inte överens med varandra. Att stämma av mot en uppskattning gör det omöjligt att bryta ner skillnaden.
Kommer serversidestaggning att täcka gapet helt? Nej. Den återställer beställningar som förlorats på grund av blockerare och bekräftelsesidor som aldrig renderades. Den återställer inte användare som vägrat att samtycka.
GA4 är högre än vår backend. Är det möjligt? Ja. Vanligtvis duplicerar köphändelser från siduppdateringar, en tom eller återanvänd sida transaction_id, eller iscensätta order som avfyras in i produktionsfastigheten.
Åtgärdar samtyckesläget det turkiska samtyckesklyftan? Delvis. Nekade signaler möjliggör modellering, med förbehåll för Googles volymgränser. Det är inte en ersättning för en laglig banner enligt turkiska regler.
Vad räknas som ett bra mellanrum? En där varje procentenhet har ett namn. Dokumenterade 8 % slår oförklarade 3 %.
Bör vi omarbeta historiska rapporter efter att vi har åtgärdat detta? Nej. Anteckna fixdatumet och behandla perioderna som separata serier. Om du återställer spårade konverteringar förstörs revisionsloggen.
Kan vi köra A/B-tester medan gapet är över 10 %? Kör dem på relativa mätvärden som mäts inuti testverktyget, men rapportera inte absolut intäktspåverkan från GA4 förrän gapet är utjämnat.
Kör denna avstämning i din egen butik denna månad, eller Låt vårt analysteam köra det med dig och ge dig upplösningen, toleransen och fixordningen.
Källor
- [GA4] Beteendemodellering för samtyckesläge, Google Analytics hjälp
- [GA4] Minimera dubbletter av viktiga händelser med transaktions-ID:n, Google Analytics hjälp
- [GA4] Oönskade hänvisningar, Google Analytics hjälp
- [GA4] Mätning över flera domäner, Google Analytics hjälp
- Skicka Measurement Protocol-händelser till Google Analytics, Google for Developers
- Parametrar för samtyckesläge, dokumentation för Google Tag Platform
- Spårningsförebyggande i WebKit
- Utgångsgräns borttagen från JavaScript-cookies i WebKit-webbläsare, Simo Ahava
- KVKK Kurul karari 2022/1358, 23 december 2022
- 3DS-implementering, iyzico-utvecklardokumentation
