Terugbetaling ontbreekt in je omzetrapport

Een ontbrekende terugbetaling kan drie oorzaken hebben, en elk vraagt een andere oplossing. Mogelijk is er nooit een correctie verwerkt in je bestelsysteem. Mogelijk is ze wel verwerkt, maar wordt er geen meetgebeurtenis voor verstuurd. Of de gebeurtenis komt wel aan, maar je leest een getal in je rapport dat haar niet meetelt.

Begin daarom met een kleine steekproef van drie tot vijf terugbetalingen die je zeker kent. Noteer per geval het ordernummer, de datum van de bestelling, de datum van de terugbetaling, het bedrag en of het een volledige of gedeeltelijke terugbetaling was. Een terugbetaling in je betaalomgeving is op zich nog geen meetgebeurtenis. Vraag je ontwikkelaar of er iets wordt verstuurd en vanuit welke plek.

Maak drie eenvoudige lijsten en koppel ze op ordernummer.

1. Lijst A: bestellingen uit je webshop, met ordernummer, bedrag, valuta en datum.
2. Lijst B: betaalcorrecties uit je betaalomgeving, met verwijzing naar het ordernummer, bedrag en datum.
3. Lijst C: wat je analytics heeft ontvangen, met transactie-ID, soort gebeurtenis en waarde. Exporteer dit uit je rapportage of bekijk de gebeurtenissen één voor één.

Geef elke rij van lijst B één status: staat in C met hetzelfde ID, staat niet in C, staat in C met afwijkend bedrag, of staat in C onder een ander ID. Spreek vooraf af wat een bedrag omvat, bijvoorbeeld wel of geen btw en verzendkosten, anders vergelijk je appels met peren. Let ook op perioden: een terugbetaling van deze maand hoort bij een bestelling van vorige maand en kan daardoor in een ander rapportbereik vallen.

De Analytics-hulppagina over transactie-ID's (https://support.google.com/analytics/answer/12313109) legt uit dat je een transactie-ID aan elke e-commercegebeurtenis toevoegt om aankopen te dedupliceren en terugbetalingen op de juiste manier te verwerken. Het ID moet per bestelling uniek zijn, mag geen gegevens bevatten waarmee een klant te identificeren is en mag geen lege tekenreeks zijn. De pagina vermeldt ook dat deduplicatie alleen werkt voor webstreams, niet voor app-streams.

Controleer daarom drie dingen. Heeft de terugbetaling hetzelfde ID als de oorspronkelijke aankoop, en niet bijvoorbeeld een intern betalingsnummer? Is het ID dynamisch en verschilt het per bestelling? Wordt het niet leeg verstuurd bij een uitzonderingsgeval, zoals een betaling achteraf bevestigd? Een ID dat afwijkt, kan een correctie loskoppelen van de aankoop waar ze bij hoort.

De ontwikkelaarsdocumentatie voor ecommerce in GA4 (https://developers.google.com/analytics/devguides/collection/ga4/ecommerce) rekent aankopen en terugbetalingen tot de acties die je kunt meten, en raadt aan de valuta op gebeurtenisniveau mee te sturen bij een waarde. Elk item heeft minstens item_id of item_name nodig, en debugmodus helpt gebeurtenissen live te zien. Lees voor de exacte parameters van het refundevent de actuele documentatie, want die kan wijzigen.

Zet de debugmodus aan en voer een testbestelling met een testterugbetaling uit. Kijk dan na:

• Komt er een refundgebeurtenis binnen, en met welk transactie-ID?
• Staan waarde en valuta erbij, en kloppen ze met het gecorrigeerde bedrag?
• Bij een gedeeltelijke terugbetaling: worden de juiste items of bedragen meegestuurd?
• Wordt de gebeurtenis maar één keer verstuurd, ook bij het herladen van een pagina?

Vraag ook of de gebeurtenis vanuit de browser of vanuit de server komt. Een terugbetaling die een medewerker in de betaalomgeving doet, bereikt de browser van de klant niet.

Gebruik de uitkomst van je vergelijking om te kiezen welk woord bij je cijfer past.

Controleer in je eigen analyticsaccount welke metriek terugbetalingen verwerkt en onder welke naam. Die schermnamen kunnen wijzigen en staan niet in de gebruikte bronnen.

Fictief voorbeeld, enkel bedoeld om te rekenen. Er zijn vier bestellingen: 100, 60, 40 en 80 euro, samen 280 euro bruto. Op de eerste bestelling is 30 euro terugbetaald, de derde is volledig terugbetaald (40 euro). Verwachte netto omzet: 280 min 70 is 210 euro. Verwachte controles: in lijst C staan twee refundgebeurtenissen met het ID van de eerste en de derde bestelling en met waarden van 30 en 40. Toont je rapport 280, dan worden de correcties mogelijk niet meegeteld; controleer ook het datumbereik, filters en de gekozen metriek. Toont het een ander bedrag, ga dan terug naar ID, valuta en btw. De betaalomgeving blijft de bron voor wat daadwerkelijk is terugbetaald; een refundevent in analytics bewijst dat niet.

Herhaal de vergelijking na elke aanpassing met een nieuwe steekproef en noteer de periode. Bewaar de drie lijsten als bewijs voor wie het rapport later leest.

Je interne rapportage beoordeel je zelf in analytics en betaalomgeving. Wil je daarnaast zien welke publieke signalen je website uitstuurt, bekijk ze dan via Marketing Scan. Die scan meet geen binnenkomende refundgegevens en vervangt deze controle niet.