Aankoop twee keer gemeten: controleer transaction_id

Een purchase-event is een melding die je pagina naar Google Analytics stuurt. Een transactie is een bestelling in je shop. Idealiter komt per bestelling precies één event aan. In de praktijk kan een event meerdere keren vuren: bij een paginaherlaad, wanneer de klant via de terugknop of een link in de bevestigingsmail op de bedankpagina terugkomt, of wanneer twee tags hetzelfde event versturen. Dat laatste kan gebeuren als de meetcode zowel in de pagina als in een tagbeheerder staat.

Je onderzoekt dus twee getallen: het aantal ruwe purchase-events en het aantal unieke transaction_id's. Zijn ze gelijk, dan stuurt je site per bestelling één event. Zijn er meer events dan ids, dan wordt een bestelling meermaals verstuurd. Lege of identieke ids zijn een apart probleem.

De hulppagina van Google Analytics over transactie-ID's legt kort uit hoe je dubbele gebeurtenissen beperkt. De kernpunten die je voor je controle nodig hebt: de id moet uniek zijn per bestelling, bijvoorbeeld een bevestigingsnummer. Dezelfde id mag niet voor verschillende gebruikers dienen, en hij mag geen gegevens bevatten waarmee een klant te identificeren is. De waarde moet dynamisch zijn, zodat elke bestelling een andere krijgt. Een lege tekenreeks is uitdrukkelijk af te raden, omdat aankopen met een lege id samen worden gededupliceerd. De pagina vermeldt ook dat deze deduplicatie alleen werkt voor webstreams en niet voor app-streams.

Omdat Google Analytics aankopen met dezelfde transactie-ID dedupliceert, kunnen dubbele events met dezelfde id in rapporten verdwijnen, terwijl ze in de ruwe gegevens zichtbaar blijven. Of en hoe een afwijking in jouw property zichtbaar is, hangt af van je opzet. Controleer dat dus zelf in de ruwe gegevens, niet enkel in samenvattende rapporten.

Doe deze test samen met de beheerder van je webshop, met een testbestelling die je achteraf als test herkent. Gebruik geen echte klantbestelling. De ontwikkelaarsdocumentatie over e-commerce raadt aan om debugmodus in te schakelen, zodat je events live kunt volgen en problemen kunt opsporen. Waar je die modus vindt, hangt af van je opzet; vraag het na bij je beheerder.

1. Zet debugmodus aan en open de weergave met binnenkomende events.
2. Plaats een testbestelling tot en met de bedankpagina.
3. Noteer het aantal purchase-events en de transaction_id van dat event.
4. Controleer of de id een echte waarde is, geen lege tekst of een zichtbare sjabloonplaats. Bij een id die direct in de paginacode staat, kun je de paginabron bekijken. Bij een tagbeheerder of datalaag controleer je de waarde in de debugweergave of de previewmodus van de tagbeheerder.
5. Herlaad de bedankpagina één keer en noteer opnieuw wat er binnenkomt.
6. Open de bedankpagina nog eens via de link in je bevestigingsmail en noteer opnieuw.
7. Leg je notities naast de bestellijst in je shop: één bestelling, hoeveel events, welke ids.

Onderstaande gegevens zijn verzonnen en dienen alleen om de methode te tonen. Stel dat je debugweergave na een testsessie zes purchase-events toont met deze ids: ORD-1001, ORD-1001, ORD-1002, (leeg), (leeg), ORD-1003. Je bestellijst bevat drie testbestellingen: ORD-1001, ORD-1002 en ORD-1003.

• Ruwe purchase-events: 6.
• Unieke, niet-lege ids: 3 (ORD-1001, ORD-1002, ORD-1003).
• Events met lege id: 2.
• Events met dubbel id: 1 extra voor ORD-1001.

Verwachte technische controles: bij ORD-1001 test je herlaad en dubbele tags. Voor de lege ids onderzoek je waarom de dynamische waarde ontbreekt en welke pagina dat event verstuurt. Na een herstel verwacht je dat elke testbestelling precies één event met een eigen, gevulde id oplevert, en dat ruwe events en unieke ids gelijk zijn. Hoe je rapport daarop reageert, controleer je pas in je eigen property.

Herhaal na elke aanpassing de volledige procedure met een nieuwe testbestelling, inclusief herlaad en de link uit de bevestigingsmail. Vergelijk daarna ruwe events, unieke ids en bestellijst opnieuw. Controleer ook of terugbetalingen dezelfde id gebruiken als de oorspronkelijke bestelling, want de officiële uitleg koppelt de id aan het verwerken van terugbetalingen. Noteer wie de wijziging deed en welke versie van de code actief is, zodat een latere afwijking sneller te herleiden is.

Let op de grenzen: deze test toont of events dubbel vuren, niet of omzet, btw of valuta in je rapport volledig kloppen. Vergelijk bedragen daarom steekproefsgewijs met je shop. Wil je ook de publieke signalen van je site bekijken? Dat kan via Marketing Scan. Een publieke scan ziet geen interne meetconfiguratie en vervangt deze controle in je eigen analytics niet.