Valutafout in ecommercegegevens vinden

Begin niet bij de code maar bij het verschil zelf. Kies een korte periode en een kleine groep bestellingen, bijvoorbeeld tien. Vergelijk per bestelling het totaal in je webshop met het bedrag dat je analytics toont. Noteer drie dingen: het verschil in bedrag, of het verschil bij alle bestellingen voorkomt of bij een deel, en of het deel een herkenbaar kenmerk heeft, zoals een kortingscode, een verzendmethode of een ander land.

Let op: analytics rapporteert niet altijd hetzelfde totaal als je boekhouding. Verzendkosten, btw en korting kunnen anders worden meegeteld. Beslis dus eerst welk bedrag jij als referentie neemt, en schrijf die definitie op. Zonder die definitie vergelijk je appels met peren.

Maak voor elke testbestelling een referentieblad met de gegevens uit het bestelsysteem, niet uit analytics. Neem op:

• het bestelnummer;
• de valuta van de bestelling;
• productprijzen, aantallen en korting per regel;
• verzend- en betaalkosten, en of btw is inbegrepen;
• het totaalbedrag dat de klant betaalde.

Het bestelnummer is belangrijk om een tweede reden. De Google Analytics-hulppagina over transactie-ID's legt uit dat een uniek transactie-ID per bestelling nodig is om dubbele aankopen te beperken en terugbetalingen goed te verwerken, dat een lege waarde of een hergebruikte ID problemen geeft, en dat deze deduplicatie alleen geldt voor gegevens uit webstreams, niet voor app-streams. Zo kan een verschil in totalen ook uit dubbele of samengevoegde aankopen komen en niet uit een valutafout. Controleer dit dus bij je afbakening.

Zet foutopsporing aan, want de ecommercedocumentatie van Google Analytics raadt dit aan om events live te zien. Waar je dit in jouw omgeving instelt, controleert de beheerder in de tool of tagbeheer, want schermen en opties kunnen wijzigen. Plaats daarna een testbestelling in een testomgeving of met een afgesproken testproduct en testbetaling, zodat er geen echte levering of omzetvervuiling ontstaat, en bekijk de gegevens van elk event in de keten.

Volgens dezelfde documentatie stel je currency op eventniveau in wanneer je een value meestuurt, en geldt dit ook als je de items buiten de ecommerce-array plaatst. Controleer daarom per event:

1. staat currency erbij en is het de bedoelde code;
2. is value een getal en geen tekst met valutateken of komma als decimaalteken;
3. komt value overeen met je referentie, volgens de definitie die je koos;
4. kloppen price en quantity per item, wetende dat quantity volgens de documentatie standaard 1 is als je niets meestuurt;
5. staat een unieke transactie-ID in het aankoopevent.

Doe dit voor minstens add_to_cart, begin van de checkout en aankoop. Een fout kan in één stap ontstaan en in een andere onzichtbaar blijven.

Gebruik deze tabel om je bevinding te koppelen aan de volgende controle. Het zijn werkhypotheses, geen vaststaande oorzaken.

Een fictief voorbeeld, alleen om de procedure te tonen. Een testbestelling bevat twee producten. Je referentieblad noteert: valuta EUR, product 1 met prijs 20,00 en aantal 1, product 2 met prijs 15,00 en aantal 2, korting 5,00, verzending niet inbegrepen in het gekozen totaal.

Verwachte technische controles: currency staat op EUR in elk event, items bevatten de juiste price en quantity, value volgt jouw vastgelegde definitie en het aankoopevent bevat het bestelnummer als transactie-ID. Wijkt één punt af, dan zoek je alleen in de stap waar het afwijkt.

Na een herstel herhaal je dezelfde procedure:

1. Plaats een nieuwe testbestelling in een veilige testopzet, ook voor een ander land of een andere valuta als je shop die aanbiedt, met een uniek bestelnummer.
2. Vergelijk de eventgegevens met het referentieblad.
3. Kijk later in je rapporten of de nieuwe bestellingen overeenkomen met je bestelsysteem. Hoe snel gegevens zichtbaar zijn en hoe rapporten ze verwerken, controleer je in je eigen omgeving.
4. Noteer dat historische gegevens niet vanzelf wijzigen, zodat je periodes vergelijkt met die kennis.

Wil je ook zien welke publieke signalen je website uitstuurt? Bekijk ze via Marketing Scan. Een publieke scan ziet geen interne eventdata en bewijst dus niet dat je ecommercemeting klopt.