Een verandering in rapporttijdzone verklaren

Een omzetcijfer per dag hangt af van minstens drie grenzen. De eerste is die van je bron, bijvoorbeeld het bestelsysteem of de betaalprovider, die bestellingen tijdstempelt in zijn eigen tijdzone. De tweede is het moment waarop je meting de gebeurtenis ontvangt. De derde is de tijdzone waarin het rapport de gebeurtenissen aan een kalenderdag toewijst.

Verschillen tussen die drie leiden niet tot verloren bestellingen, wel tot bestellingen die op een andere dag terechtkomen. Een bestelling om 23:30 UTC is in België al de volgende dag, want Brussel ligt een of twee uur voor op UTC, afhankelijk van winter- of zomertijd. Een rapport in de ene zone en een export in de andere geven dus verschillende dagtotalen bij hetzelfde aantal bestellingen.

Noteer daarom eerst per systeem welke tijdzone het gebruikt. Waar je dat bij jouw account vindt, verschilt per tool en kan wijzigen. Vraag de beheerder het na in de instellingen van het rapport of de property, en neem niets aan op basis van de taal of regio van je interface.

Een tijdzoneverschuiving laat een herkenbaar spoor na. Kijk naar vier signalen voor je een oorzaak kiest:

• Startmoment: begint het verschil op een scherp afgebakende dag, of sluipt het erin?
• Weekpatroon: schuiven vooral late avondbestellingen naar de volgende dag, en klopt dat met je gewone avondpiek?
• Meerdaagse som: is het totaal over een ruime periode gelijk gebleven, terwijl de dagcijfers anders verdeeld zijn?
• Gelijktijdigheid: veranderde er op dezelfde dag iets anders, zoals een tagwijziging, een nieuwe campagne of een zomertijdwissel?

Een gelijke som met verschoven dagen wijst op een grensverschil. Een lager totaal wijst op verlies in meting of verkoop, bijvoorbeeld door gemiste of te laat binnengekomen gebeurtenissen (volgens de bron negeert Analytics gebeurtenissen die meer dan 2 kalenderdagen na activering binnenkomen). Beide kunnen tegelijk voorkomen, dus behandel de uitkomst als aanwijzing en niet als bewijs. Je meting kan bovendien ook zelf gewijzigd zijn, wat een apart onderzoek vraagt.

1. Kies een afgebakende periode van enkele dagen rond het kantelpunt, plus dezelfde periode een week eerder.
2. Exporteer uit de bron elke bestelling met volledig tijdstempel, inclusief tijdzone-aanduiding, bestelnummer en bedrag.
3. Zet alle tijdstempels om naar één vaste zone, bijvoorbeeld de zone van je rapport.
4. Tel per dag het aantal bestellingen volgens de bron en vergelijk met het rapport.
5. Markeer bestellingen die in de bron op dag X staan en in het rapport op dag X+1 of X-1.
6. Test de meting zelf. Volgens de uitleg over gebeurtenissen in Analytics toont het Realtime-rapport gebeurtenissen van de afgelopen 30 minuten, en toont DebugView de gebeurtenissen van één gebruiker met foutopsporingsmodus. Doe in een veilige testomgeving een testbestelling met fictieve gegevens en controleer of gebeurtenis en parameters aankomen. Dat bewijst alleen dat de gebeurtenis is ontvangen, niet dat de bestelling of betaling correct is afgerond. Stuur geen persoonsgegevens mee in parameters. DebugView vraagt extra configuratie.
7. Controleer in de code of de gebeurtenis pas na het laden van de Google-tag wordt verstuurd. De documentatie over gebeurtenissen instellen gaat uit van een geplaatste Google-tag en toegang tot de broncode. Bevestig de volgorde dus in je eigen testomgeving.

Een testbestelling in een live shop kan echte data vervuilen. Markeer ze en sluit ze achteraf uit je vergelijking.

Een tijdzonewijziging is pas aannemelijk als je de verschoven bestellingen individueel hebt aangewezen. Een gelijkende curve volstaat niet.

Dit is een verzonnen voorbeeld met alleen invoer en verwachte controles. Een webshop ziet dat de rapportcijfers voor zondag lager liggen dan de bestelexport. De export staat in UTC, het rapport in de zone van Brussel.

Invoer: drie fictieve bestellingen met tijdstempel zaterdag 23:10 UTC, zaterdag 23:45 UTC en zondag 00:20 UTC, in de periode met zomertijd (UTC+2).

Verwachte controle: na omzetting naar Brusselse tijd vallen ze op zondag 01:10, zondag 01:45 en zondag 02:20. In een UTC-export staan er dus twee op zaterdag en een op zondag, in een Brussels rapport alle drie op zondag. Valt jouw verschil hier mee samen, dan is een grensverschil plausibel.

Controleer daarna de waarde. De documentatie over ecommerce meten beveelt aan om de valuta op gebeurtenisniveau mee te sturen bij omzetwaarden. Ontbreekt die, dan kan een afwijkend bedrag een tweede oorzaak zijn, los van de dagverdeling.

Heb je een zone of rapportagegrens aangepast, controleer dan na een volledige dag opnieuw. Herhaal de vergelijking met dezelfde bronexport, kijk of de dagen nu overeenkomen en testbestellingen in DebugView nog correct aankomen. Hoe snel gegevens volledig verwerkt zijn, verschilt per situatie. Plan je controle dus niet op een vaste tijd en bevestig de uitkomst zelf in de rapporten.

Leg bij overdracht zes dingen vast: de zone van bron, meting en rapport, de datum van de wijziging, de gebruikte vergelijkingsperiode, de uitkomst per beslisregel en wie de instellingen beheert. Zet bij oudere grafieken een aantekening dat ze mogelijk met een andere dagverdeling zijn opgebouwd.

Wil je eerst zien welke signalen je site publiek toont? Bekijk ze via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst niet hoe je tags, tijdzones of rapporten intern zijn ingesteld.