Uw GA4-rapportage meldt 4,180 aankopen vorige maand. Uw ordertabel geeft 4,690 aan. Op de vraag welke van de twee klopt, is het eerlijke antwoord: geen van beide, totdat u kunt aangeven waar de ontbrekende 510 orders gebleven zijn. Dit is geen kwestie van netheid. Elk experimentresultaat en elke prioriteringsscore die u genereert, is gebaseerd op een getal dat met een onbekende hoeveelheid en in een onbekende richting afwijkt.
Google beschouwt een groot, niet-gemeten deel als normaal: gedragsmodellering voor de toestemmingsmodus wordt pas ingeschakeld wanneer een property gegevens registreert. minstens 1,000 evenementen per dag met analytics_storage='denied' gedurende minimaal 7 dagenDaaronder blijven ontbrekende gegevens ook daadwerkelijk ontbreken.
Dit is bedoeld voor iedereen die verantwoordelijk is voor analytics of CRO binnen een e-commerce team. Aan het eind heb je een reconciliatietabel, een ontleding van je tekortkoming in benoemde oorzaken met een test voor elk, en een tolerantiegrens die je kunt verdedigen.
Wat een aankoopverrekening daadwerkelijk meet
Een reconciliatie is niet "de cijfers laten kloppen". Ze zullen nooit kloppen, en een team dat ze forceert, heeft meestal iets ergers gedaan dan de discrepantie te laten bestaan. Het beantwoordt drie vragen: hoe groot is de discrepantie, welke mechanismen veroorzaken deze, en hoeveel kan er worden teruggewonnen tegen welke kosten. We voeren deze reconciliatie uit vóórdat we met experimenten beginnen, omdat een test die wordt gemeten op basis van een conversiegebeurtenis waarbij stilletjes een onbekend deel van de orders verloren gaat, geen experiment is.
Stap 1: selecteer twee tabellen die gekoppeld kunnen worden op basis van het order-ID.
Je hebt per bestelling één rij nodig, uit beide systemen, voor hetzelfde kalenderbereik, met een sleutel die aan beide kanten voorkomt.
- backend: Order-ID, aanmaaktijdstempel in de rapportagetijdzone van de property, orderwaarde op basis van dezelfde belasting- en verzendkosten die u in GA4 hebt geconfigureerd, betaalmethode, apparaat, land, status.
- GA4: De BigQuery-export, niet de gebruikersinterface. Query
purchaseevenementen metecommerce.transaction_id,event_timestamp,ecommerce.purchase_revenue, apparaatcategorie en verkeersbron.
Gebruik BigQuery bewust. Gemodelleerde gegevens uit de toestemmingsmodus verschijnen in de standaardrapporten van GA4 en in sommige onderzoeken, maar Google stelt dat dit niet het geval is. niet In de BigQuery-export kunt u doelgroepen, gebruikersverkenner, cohort- of retentieanalyses of voorspellende statistieken bekijken. Vergelijk de gebruikersinterface met uw ordertabel en u vergelijkt een schatting met een feit.
Vervolgens een volledige outer join op order-ID. Je hebt nu drie buckets: in beide, alleen backend, alleen GA4. De derde is kleiner, maar wel de meest diagnostische.
Stap 2: Geef de kloof op drie manieren weer, niet op één.
Een enkel maandelijks percentage verbergt alles. Bereken ze alle drie:
- Verschil in orderaantal: (backendbestellingen minus overeenkomende GA4-aankopen) / backendbestellingen. Dit isoleert het verlies aan traceerbaarheid.
- Omzetkloof: Dezelfde berekening geldt voor de waarde. Als het verschil in aantallen 3% is en het verschil in omzet 11%, dan is er geen probleem met de registratie, maar met de waardebepaling (belasting, verzendkosten, kortingen, valuta, cadeaubonnen).
- Dagelijkse afwijking van het verschil: Teken de dagelijkse kloof tussen het aantal bestellingen en het werkelijke aantal orders. Een vlakke lijn duidt op een structurele oorzaak, zoals toestemmingsproblemen of blokkades. Pieken duiden op implementaties, campagne-uitbarstingen of een incident bij de betalingsprovider.
Stap 3: Ontleed de kloof in benoemde oorzaken
Doorloop deze tabel. Voor elke oorzaak is er een test die deze binnen een uur kan bevestigen of uitsluiten.
| Veroorzaken | Hoe het te testen | Handtekening in de gegevens |
|---|---|---|
| Toestemming geweigerd, tag wordt nooit geactiveerd | Vergelijk het logboek met toestemmingsstatussen van uw CMP met GA4-sessies voor dezelfde periode. | Stabiel dagelijks percentage; geconcentreerd in EU- en Turks verkeer. |
| Advertentie- en trackerblokkers | Tel het aantal serverlogboekverzoeken voor de bevestigings-URL en vergelijk dit met de GA4-aankoopgebeurtenissen op die URL. | Vertekent desktopbrowsers, Firefox en privacybrowsers; stabiel over tijd. |
| De bevestigingspagina laadt nooit. | Tel het aantal backend-only bestellingen waarvan de bevestigings-URL nooit is opgevraagd in de serverlogboeken. | Gespecialiseerd in bankoverschrijvingen en 3DS-betaalmethoden. |
| Dubbele aankoopgebeurtenissen | Tel GA4-aankoopgebeurtenissen per transaction_id | GA4 overbelast de backend op sommige dagen; pagina's die veel verversen en terugklikken vereisen. |
| Cross-domain link verbroken | Controleer of _gl overleeft de retourzending van de betalingsaanbieder. | Aankopen komen terecht in nieuwe sessies die als verwijzing aan het betalingsdomein zijn toegewezen. |
| Levensduur van cookies resetten | Segmenteer het aantal nieuwe gebruikers per browser | Het aantal nieuwe gebruikers en het directe verkeer op Safari en iOS is sterk gestegen. |
| Gemodelleerd versus ruw | Vergelijk de totalen in de GA4 UI met die in BigQuery voor hetzelfde datumbereik. | De twee Google-nummers spreken elkaar tegen nog voordat je de besteltabel opent. |
| Waarde definitie | Herbereken de omzet aan de backend met en zonder btw, verzendkosten en kortingen. | Aantallen komen overeen, omzet niet. |
| Tijdzonegrens | Wederomrekenen naar volledige weken | Het verschil neemt wekelijks af tot bijna nul. |
Twee verdienen extra zorg. transaction_id Ontdubbeling werkt alleen op webstreams, niet op appstreams, en Google waarschuwt dat het verzenden van een lege tekenreeks ervoor zorgt dat Analytics ontdubbelt. elk aankoopevenement met transaction_id=''Die ene bug kan al een groot deel van een dag in beslag nemen. Daarnaast is de lijst met ongewenste verwijzingen beperkt tot 50 domeinen per datastroom, wat vervelend is als je meerdere acquirers, wallets en bankpagina's gebruikt.
[INTERNE GEGEVENS NODIG: de waargenomen verdeling van deze negen oorzaken over de Switas-verzoeningstrajecten, zodat lezers kunnen zien welke doorgaans dominant zijn.]
Stap 4: Stel een tolerantiegrens vast die je kunt verdedigen.
Google publiceert geen acceptabel afwijkingspercentage en de veel geciteerde uitspraak "5% is prima" komt in geen enkele Google-documentatie voor die we hebben kunnen vinden. Stel uw eigen afwijkingspercentage in, afhankelijk van de ontleding in plaats van alleen het getal zelf.
| Maandelijks verschil in orderaantal | lezing | Actie |
|---|---|---|
| Tot 2% | Tijdzonegrenzen en normale deduplicatie | Noteer de oorzaken en controleer dit elk kwartaal opnieuw. |
| 2% tot 5% | Alleen acceptabel als elk punt aan een benoemde oorzaak wordt toegeschreven. | Documenteer eerst, en ga daarna pas experimenteren. |
| 5% tot 10% | Ten minste één structurele oorzaak is nog niet verholpen. | Corrigeer eventuele problemen voordat u absolute conversiecijfers vertrouwt. |
| Boven 10% | Niet geschikt voor experimenten. | Stop met het gebruiken van GA4-aankopen als de primaire experimentele meeteenheid totdat dit is opgelost. |
Dit zijn onze operationele drempelwaarden, geen industriestandaard. De nuancering is cruciaal: een onverklaard percentage van 3% is slechter dan een verklaard percentage van 8%.
Stap 5: Stel de volgorde in die het meeste aantal bestellingen per gewerkt uur oplevert.
- Waardedefinitie en tijdzone. Configuratie, geen engineering, en meestal een middagje werk.
- Dubbele en lege transactie-ID's. Een dataLayer-fix.
- Doorverwijzingen naar andere domeinen en ongewenste doorverwijzingen. Configureer beide en test vervolgens het daadwerkelijke betalingsretourproces opnieuw, niet een testomgeving.
- Aankoopgebeurtenis aan de serverzijde. Verzend de aankoop vanuit uw bestelsysteem met het meetprotocol, gebruikmakend van de
client_idUw webtag is gegenereerd. Google vereist dat deze gebeurtenissen binnen 48 uur na de oorspronkelijke tijdstempel van de client-side gebeurtenis plaatsvinden, anders wordt de toewijzing mogelijk niet correct verwerkt. Dit is wat orders herstelt die verloren zijn gegaan door blokkeringen en bevestigingspagina's die nooit zijn weergegeven. - Consensusarchitectuur. Het langzaamste en meest politieke proces. Beschouw de rest als een bekende, vastgestelde en gedocumenteerde kloof.
Wat verandert er als je in Turkije of de EU verkoopt?
Twee regionale factoren beïnvloeden de cijfers.
Ook in Turkije is toestemming opt-in, maar zonder het vangnet van Google. De Turkse autoriteit voor gegevensbescherming heeft een websitebeheerder een boete van 300,000 TL opgelegd in besluit 2022/1358 (23 december 2022) voor het plaatsen van reclame- en marketingcookies zonder wettelijke basis en voor het vereisen van actieve toestemming voor niet-essentiële cookies. Veel Turkse websites reageerden hierop met een banner die de Google-tag volledig blokkeert in plaats van een banner die toestemmingssignalen verzendt. Dat onderscheid is kostbaar: het modelleren ervan vereist... analytics_storage='denied' Er moeten gebeurtenissen plaatsvinden. Een banner die niets doet, geeft Google geen basis om een model mee te bouwen, waardoor de data verloren gaat in plaats van geschat te worden.
Turkse 3DS-producten worden per post naar de koper teruggestuurd. Met iyzico toont de verkoper een gedecodeerde 3DS-pagina en na bevestiging met de OTP-code stuurt iyzico je door naar de website van de verkoper. callbackUrl with status, paymentId en mdStatusEen POST-return is precies wat Google bedoelt met het verbreken van de cross-domain-meting, aangezien redirects dit kunnen voorkomen. _gl voordat de bestemming wordt geladen. Als uw tekort aan kaartbetalingen groot is en uw tekort aan contante betalingen bij levering bijna nul is, dan is dit de reden.
Twee veelvuldig herhaalde beweringen die we niet konden verifiëren.
"Safari beperkt de bewaartermijn van eigen cookies tot 7 dagen." Onnauwkeurig. Volgens de documentatie van WebKit verwijdert ITP JavaScript-cookies en andere door scripts beschrijfbare opslag na 7 dagen. geen gebruikersinteractieEn afzonderlijk worden JavaScript-cookies beperkt tot 24 uur wanneer de landingspagina is bereikt via een link van een advertentiedomein. Uit tests van Simo Ahava bleek dat de teller loopt op basis van het aantal dagen browsergebruik, niet op kalenderdagen, waardoor een terugkerende klant een identificatiecode langer dan een week kan behouden.
"Een afwijking van 5% is acceptabel." We hebben geen bron op Google gevonden voor dit cijfer. Het circuleert via blogs van leveranciers en forumreacties. Beschouw het als een algemeen bekend gegeven, niet als een absolute grens.
Waar deze methode faalt
Het dekt geen app-streams, waar transaction_id Het verwijderen van duplicaten is niet van toepassing op abonnements- en deelleveringsmodellen, waarbij "een bestelling" geen enkele gebeurtenis is. Het kan de identiteit van een gebruiker die geen toestemming heeft gegeven niet achterhalen, maar alleen het volume schatten. Het lost het probleem van kanaaltoewijzing niet op, een apart en complexer probleem. Bovendien wordt ervan uitgegaan dat uw besteltabel schoon is: als geannuleerde en door fraude geblokkeerde bestellingen aan beide zijden inconsistent worden geteld, zult u een hiaat opsporen dat alleen in uw query bestaat.
Veelgestelde vragen
Hoe vaak moeten we dit uitvoeren? Voer de volledige analyse eerst volledig uit, en daarna een dagelijkse gap-grafiek. Herhaal de volledige analyse na elke wijziging in de checkout, CMP, betalingsprovider of tagmanager.
Waarom niet de GA4-interface gebruiken in plaats van BigQuery? De interface kan gemodelleerde gebruikers en sessies bevatten die de export niet bevat, waardoor de twee Google-cijfers niet met elkaar overeenkomen. Door ze te vergelijken met een schatting, is het onmogelijk om het verschil te ontrafelen.
Zal tagging aan de serverzijde het verschil volledig dichten? Nee. Het herstelt bestellingen die verloren zijn gegaan door blokkeringen en bevestigingspagina's die nooit zijn weergegeven. Het herstelt geen gebruikers die geen toestemming hebben gegeven.
GA4 heeft een hogere versie dan onze backend. Is dat mogelijk? Ja. Meestal gaat het om dubbele aankoopgebeurtenissen als gevolg van het vernieuwen van pagina's, een lege pagina of hergebruikte pagina's. transaction_id, of het uitvoeren van commando's die op het productieterrein worden afgevuurd.
Lost de toestemmingsmodus het Turkse hiaat in de toestemmingsprocedure op? Gedeeltelijk. Geweigerde signalen maken modellering mogelijk, afhankelijk van de volumelimieten van Google. Het is geen vervanging voor een wettige banner volgens de Turkse wetgeving.
Wat wordt beschouwd als een goede kloof? Een systeem waarin elk procentpunt een naam heeft. Een gedocumenteerde 8% is beter dan een onverklaarde 3%.
Moeten we de historische rapporten opnieuw publiceren nadat dit is opgelost? Nee. Noteer de correctiedatum en behandel de perioden als afzonderlijke reeksen. Het opnieuw vastleggen van geregistreerde conversies vernietigt het auditspoor.
Kunnen we A/B-tests uitvoeren als het verschil groter is dan 10%? Voer de tests uit op basis van relatieve meetwaarden die binnen de testtool zijn vastgesteld, maar rapporteer de absolute omzetimpact van GA4 pas nadat het verschil is geanalyseerd.
Voer deze afstemming deze maand uit voor uw eigen winkel, of Laat ons analyseteam het samen met u uitvoeren. en u de ontleding, de tolerantie en de volgorde van de correcties overhandigen.
Bronnen
- [GA4] Gedragsmodellering voor toestemmingsmodus, Google Analytics Help
- [GA4] Minimaliseer dubbele sleutelgebeurtenissen met transactie-ID's, Google Analytics Help
- [GA4] Ongewenste verwijzingen, Google Analytics Help
- [GA4] Cross-domain meting, Google Analytics Help
- Verzend Measurement Protocol-gebeurtenissen naar Google Analytics en Google voor ontwikkelaars.
- Parameters voor de toestemmingsmodus, documentatie van Google Tag Platform
- Trackingpreventie in WebKit
- De vervallimiet voor JavaScript-cookies in WebKit-browsers is verwijderd, aldus Simo Ahava.
- KVKK Kurul karari 2022/1358, 23 december 2022
- 3DS-implementatie, iyzico-ontwikkelaarsdocumentatie
