Een meetfout terugvinden met één proefjourney

Een meting loopt via vier schakels: de actie in de browser, de verstuurde gebeurtenis, de verwerking door Google Analytics en het rapport. Een fout in een vroege schakel verschijnt later als een raadselachtig cijfer.

Volgens Google meet een gebeurtenis een specifieke interactie, zoals een paginaweergave, een klik of een aankoop. Er zijn automatisch verzamelde gebeurtenissen, gebeurtenissen voor verbeterde meting, aanbevolen gebeurtenissen en aangepaste gebeurtenissen. De laatste twee moet je zelf implementeren. Weet daarom eerst tot welke soort jouw verdachte gebeurtenis behoort, want dat bepaalt of je de fout in de instellingen of in je code zoekt.

Kies voor de proefjourney één enkele, goed afgebakende actie, bijvoorbeeld het versturen van een offerteformulier of het toevoegen van een product aan een winkelwagen. Eén actie per test houdt de uitkomst leesbaar.

De proefjourney is veilig als je er geen echte klantgegevens of omzet mee aanmaakt. Dat bereik je met een paar afspraken.

1. Gebruik een testactie die geen echte verplichting meebrengt. Voer een duidelijk herkenbare testwaarde in, zoals het woord TEST, en vermijd echte betalingsgegevens, namen, e-mailadressen of andere persoonsgegevens. Die mogen ook niet in eventparameters of URL's terechtkomen. Gebruik bij voorkeur een testomgeving en controleer dat de testactie niet dubbel wordt opgeslagen als je ze herhaalt.
2. Zet de foutopsporingsmodus aan. De Analytics-uitleg over gebeurtenissen vermeldt dat je in DebugView alle gebeurtenissen van één gebruiker ziet en dat je de foutopsporingsmodus moet inschakelen om dat rapport te gebruiken. De ecommerce-documentatie raadt eveneens aan debug mode in te schakelen om gebeurtenissen live te zien.
3. Noteer wat je doet. Schrijf tijdstip, apparaat en exacte handelingen op, zodat je later gebeurtenissen aan jouw testactie kunt koppelen.

Heb je een aparte testomgeving of testdataservice, dan is die geschikter dan je live property. Bestaat die niet, voer dan alleen een testactie uit die je achteraf als test kunt herkennen en uit je analyse kunt weren. Controleer in je beheeromgeving hoe je interne verkeer of testverkeer kunt uitsluiten; de exacte instelling kan wijzigen.

Voer deze zes stappen in volgorde uit en stop bij de eerste plek waar het misgaat.

1. Controleer of de tag laadt. Open je pagina en kijk in de netwerktab van je browser of er een request naar Google Analytics vertrekt. Geen request betekent dat de tag niet laadt of geblokkeerd wordt, bijvoorbeeld door een toestemmingsinstelling.
2. Voer de testactie uit. Doe alleen die ene handeling.
3. Zoek de gebeurtenis in het netwerkverkeer. Controleer de gebeurtenisnaam en de parameters, zoals waarde, valuta of items.
4. Kijk in DebugView. Verschijnt de gebeurtenis daar, dan is ze in debugmodus ontvangen. Dat bewijst nog niet dat de verwerking of het rapport klopt, en ook niet dat er een echte aanvraag of betaling heeft plaatsgevonden.
5. Controleer Realtime. De kaart met het aantal gebeurtenissen per gebeurtenisnaam toont de laatste 30 minuten en laat toe de parameters van een gebeurtenis te bekijken.
6. Kijk pas daarna in je gewone rapporten. Rapporten en verkenningen hebben hun eigen verwerking, dus een gebeurtenis die in Realtime staat, hoeft nog niet meteen overal zichtbaar te zijn. Hoe snel dat gebeurt, hangt af van het rapport; plan daarom een nacontrole in plaats van een vaste tijd aan te nemen.

Gebruik deze tabel om je bevinding te vertalen naar een volgende controle.

De ontwikkelaarsgids voor gebeurtenissen gaat ervan uit dat de Google-tag op je pagina staat en dat je gtag() aanroept via JavaScript. Controleer daarom ook of de volgorde van tag en eventcode in jouw implementatie klopt en of de gtag-functie beschikbaar is op het moment van de aanroep.

Stel: een fictieve webshop merkt dat de omzet in het rapport veel lager lijkt dan in het kassasysteem. Het team kiest één proefjourney: een testproduct toevoegen en een testbestelling doorlopen zonder echte betaling.

Invoer: één testproduct met een herkenbare naam, één doorlopen bestelstroom, debug mode aan.

Verwachte technische controles:

• De aankoopgebeurtenis verschijnt in DebugView.
• De parameters bevatten een waarde en een valuta. De ecommerce-documentatie raadt aan de valuta op gebeurtenisniveau mee te sturen wanneer je waarde (omzet) doorgeeft.
• De artikelenlijst bevat per product minstens een item-ID of een itemnaam; prijs en aantal zijn optionele parameters en het aantal staat standaard op 1 als je niets invult.

Blijkt dat de gebeurtenis wel aankomt maar zonder valuta, dan weet het team dat de oorzaak in de code ligt, niet in het rapport. Dit voorbeeld bevat geen cijfers over herstel; je controleert alleen of de juiste velden aanwezig zijn.

Wil je daarna een breder beeld van de publieke signalen van je website, bekijk ze dan via Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst niet dat je volledige meetimplementatie correct is.

Pas één ding per keer aan en herhaal daarna dezelfde proefjourney. Verander je meerdere zaken tegelijk, dan weet je niet welke wijziging het verschil maakte.

Leg na elke test vast: de datum, de handelingen, wat je zag in het netwerkverkeer, in DebugView en in Realtime, en wat je hebt aangepast. Dat document wordt je referentie bij de volgende afwijking, en een collega of een extern bureau kan het meteen gebruiken.

Een geslaagde proefjourney bewijst dat die ene keten nu werkt onder de geteste omstandigheden. Ze zegt niets over andere browsers, andere toestemmingskeuzes of andere paden naar dezelfde gebeurtenis. Herhaal de test daarom na elke grotere aanpassing van je site of tag en op minstens een tweede apparaat. Accountinstellingen, rechten en schermnamen in Google Analytics kunnen wijzigen, dus controleer in je eigen beheeromgeving waar je die opties vindt.