Omzet per campagne met annuleringscorrectie

Een aankoopgebeurtenis in je analytics registreert dat een klant een bestelling plaatste. Dat is niet hetzelfde als dat het geld binnen is. Er zitten minstens vier statussen tussen die je rapportage scheef kunnen trekken: bestellingen die nog op betaling wachten, bestellingen die geannuleerd worden, bestellingen die achteraf deels of volledig terugbetaald worden, en dubbel geregistreerde bestellingen.

Google beschrijft in zijn handleiding voor het meten van e-commerce dat je e-commerce-gebeurtenissen instelt om winkelgedrag en opbrengst per product te zien, en dat je de valuta op gebeurtenisniveau meegeeft wanneer je een waarde (omzet) verstuurt. De documentatie behandelt ook het meten van terugbetalingen, maar een terugbetaling in je ordersysteem verschijnt niet vanzelf in analytics: daarvoor moet je implementatie een aparte gebeurtenis versturen. Welke gebeurtenissen jouw website daadwerkelijk verstuurt, controleer je in je eigen implementatie.

Daaruit volgt een eenvoudig uitgangspunt voor deze gids: de analytics geeft je de aankoopkant, je eigen ordersysteem geeft de definitieve status. Voor beslissingen over campagnebudget heb je beide nodig.

Zonder vaste peildatum vergelijk je appels met peren. Een campagne van vorige week heeft nog veel open bestellingen, een campagne van drie maanden geleden bijna geen. Leg daarom vooraf vast wanneer een bestelling als afgerond geldt.

Stel je eigen definitie op in vier punten:

1. Peildatum van de rapportage: bijvoorbeeld de laatste dag van de maand waarover je rapporteert.
2. Wachttermijn: hoeveel dagen na de bestelling je nog annulering of retour verwacht. Dit hangt af van je eigen retourvoorwaarden en betaalmethodes, niet van een algemene regel.
3. Statuslijst: welke orderstatussen jouw systeem kent en welke daarvan 'definitief betaald' betekenen.
4. Behandeling van open bestellingen: rapporteer ze apart, niet als omzet.

Schrijf dit op en bewaar het bij je rapportage. Wie later de cijfers leest, kan dan zien op welke definitie ze rusten.

Om analytics en ordersysteem aan elkaar te koppelen heb je een gedeelde sleutel nodig. Dat is de transactie-ID. Google legt in zijn hulppagina over transactie-ID's uit dat je een unieke ID per transactie aan elke e-commercegebeurtenis toevoegt, bijvoorbeeld een bevestigingsnummer, zodat Google Analytics dubbele aankopen kan ontdubbelen en terugbetalingen correct kan verwerken. De pagina vermeldt ook dat deduplicatie via transactie-ID alleen werkt voor gegevens uit webstreams en niet voor app-streams.

Uit dezelfde bron halen we drie praktische waarschuwingen die je zelf moet controleren in je implementatie:

• Gebruik een dynamische waarde, geen vaste. Als dezelfde ID bij verschillende bestellingen wordt verstuurd, kan het aantal geregistreerde gebeurtenissen veel te laag uitvallen.
• Stuur geen lege tekenreeks als transactie-ID. Volgens de bron worden dan alle aankopen met een lege ID als één behandeld.
• Zet geen gegevens in de ID waarmee een klant te identificeren is.

Controleer in de broncode van je bevestigingspagina of de ID bij elke bestelling anders is. De hulppagina vermeldt zelf dat je een bestelling kunt activeren en de paginabron bekijken om te zien of de juiste waarde wordt ingevuld.

Dit is het hart van de procedure. Maak een tabel met je eigen orderstatussen en bepaal per status hoe die in de campagnerapportage telt. Onderstaand model is een startpunt; pas de statusnamen aan aan wat jouw winkelsysteem gebruikt.

Reken de omzet per campagne dan uit als: definitief betaalde bestellingen, min terugbetaalde bedragen, per campagnebron. Open en voorlopige bedragen toon je naast het totaal, niet erin. Zo ziet een lezer meteen hoeveel nog onzeker is.

Onderstaand voorbeeld bevat uitsluitend verzonnen invoer om de methode te laten zien. Het zegt niets over wat jouw campagnes zullen opleveren.

Invoer (fictief): een campagne heeft per peildatum 10 bestellingen in analytics, met elk 100 euro. Bruto aankoopwaarde in analytics: 1.000 euro. In het ordersysteem staan die 10 bestellingen als volgt:

• 6 bestellingen betaald en afgerond, buiten de wachttermijn: 600 euro.
• 1 bestelling betaald, binnen de wachttermijn: 100 euro.
• 1 bestelling wacht nog op betaling: 100 euro.
• 1 bestelling geannuleerd: 100 euro.
• 1 bestelling deels terugbetaald met 40 euro terugbetaald: 60 euro blijft over.

Berekening:

1. Bruto in analytics: 1.000 euro.
2. Definitieve omzet: 600 euro (afgerond) + 60 euro (restant na deeltelijke terugbetaling) = 660 euro.
3. Voorlopig: 100 euro (binnen wachttermijn).
4. Open: 100 euro (wacht op betaling).
5. Afgetrokken: 100 euro annulering + 40 euro terugbetaling = 140 euro.

Controle: 660 + 100 + 100 + 140 = 1.000 euro. Als de som niet klopt met het bruto bedrag, mist er een bestelling of staat er een dubbele in.

Voor je dit in een rapport gebruikt, test je de koppeling zelf. Neem een steekproef van bestellingen en volg ze van analytics tot ordersysteem:

1. Kies een aantal recente bestellingen met verschillende statussen, waaronder minstens één geannuleerde.
2. Zoek de transactie-ID van elke bestelling op in beide systemen.
3. Controleer dat bedrag en valuta overeenkomen, of leg het verschil vast (bijvoorbeeld leverkosten of btw die in het ene systeem wel en in het andere niet zitten).
4. Controleer of de som van de uitsplitsing gelijk is aan het bruto totaal, zoals in het voorbeeld hierboven.
5. Noteer de peildatum en de gekozen wachttermijn bij het rapport.

Grenzen: deze methode zegt niet welke campagne 'beter' is. Ze laat enkel zien welk deel van de gemelde omzet blijft staan. Toeschrijving van een bestelling aan een campagne hangt af van je meetinstellingen, en klanten kunnen langs meerdere kanalen binnenkomen. Of je analytics terugbetalingen ontvangt, hangt af van wat jouw implementatie verstuurt; controleer dat in je eigen gegevens. Wil je ook weten welke zichtbare meetsignalen je website publiek toont, bekijk dan je site via Marketing Scan. Die scan voert niet alle controles uit deze gids uit en kan niet zien wat er achter je bestelsysteem gebeurt.