Een trackingwijziging vastleggen in een meetlogboek

Een gebeurtenis meet volgens Google een specifieke interactie op je website of in je app, zoals een paginaweergave, een klik of een aankoop. Elke wijziging aan die meting verandert dus wat je cijfers betekenen. Gaat een formulier opeens een andere gebeurtenisnaam sturen, dan lijkt de oude gebeurtenis in een rapport te verdwijnen en verschijnt er een nieuwe. Je ziet een knik, maar het is een naamswijziging en geen gedragswijziging.

Een logboek verandert de vraag van wat is er gebeurd? naar wat hebben we gewijzigd op deze datum?. Dat werkt alleen als de notitie op het moment van de wijziging gemaakt wordt. Achteraf reconstrueren uit mailtjes en tagmanagerhistoriek is traag en onbetrouwbaar.

Let op de grens: een logboek verklaart de technische kant van een trendbreuk. Het zegt niets over seizoen, campagnes of prijsaanpassingen. Combineer het dus met je marketingagenda en trek geen conclusie uit één bron.

Houd het logboek klein genoeg om bij te houden. Eén regel per wijziging, met deze velden:

1. Datum en tijdstip van publicatie, niet van de aanvraag.
2. Eigenaar: wie voerde de wijziging door en wie keurde ze goed.
3. Wat veranderde: gebeurtenisnaam, parameters, tag, trigger of datastream.
4. Oude definitie: de vorige naam en parameters, woordelijk overgenomen.
5. Nieuwe definitie: dezelfde velden na de wijziging.
6. Reden: een zin over waarom, bijvoorbeeld een nieuwe formulierplugin.
7. Validatie: waar je controleerde (Realtime, DebugView), door wie en met welk resultaat.
8. Verwachte impact op rapporten: bijvoorbeeld dat de oude gebeurtenis stopt en een nieuwe start.

Het veld oude definitie is het belangrijkste. Zonder die tekst kan niemand later zien of twee periodes vergelijkbaar zijn. Bewaar het logboek op een plek met versiegeschiedenis en een vaste eigenaar, zodat het bij personeelswissels niet verdwijnt.

Een logboekregel zonder validatie is een intentie. Volgens de Google Analytics-uitleg over gebeurtenissen toont de kaart voor het aantal gebeurtenissen per naam in het Realtime-rapport elke geactiveerde gebeurtenis van de afgelopen 30 minuten, inclusief de parameters die meegestuurd zijn. Het rapport DebugView toont alle gebeurtenissen van één gebruiker en vraagt dat de foutopsporingsmodus aanstaat (uitleg over gebeurtenissen).

Werk zo:

1. Zet de foutopsporingsmodus aan op je testbrowser.
2. Voer de interactie uit die de wijziging raakt, bijvoorbeeld het formulier verzenden.
3. Controleer of de gebeurtenis met de verwachte naam verschijnt, en of de verwachte parameters meekomen.
4. Controleer ook wat niet meer mag verschijnen, zoals de oude naam.
5. Noteer in het logboek het resultaat en wie testte.

Een zichtbare gebeurtenis bewijst alleen dat Analytics hem ontving. Het bewijst niet dat een aanvraag of betaling echt is afgehandeld. Gebruik een veilige testomgeving of duidelijk herkenbare testgegevens zonder persoonsgegevens, en controleer in je eigen systeem of een testverzending geen echte aanvraag aanmaakt.

Waar je de debugmodus en de rapporten vindt, hangt af van je accountinstellingen en rechten. Controleer dat in je eigen Analytics-omgeving en schrijf de weg ernaartoe in het logboek, zodat een collega de test kan herhalen.

Niet elke kleine ingreep hoeft een regel, maar twijfel is een reden om te loggen. Gebruik deze matrix.

Google raadt aan aangepaste gebeurtenissen alleen te maken als geen automatische, verbeterde of aanbevolen gebeurtenis bij je situatie past. Noteer in het logboek dus ook waarom je voor een aangepaste gebeurtenis koos, anders blijft die keuze onzichtbaar voor je opvolger.

Bij een webshop zijn wijzigingen vaak groter, omdat meerdere gebeurtenissen samenhangen. Volgens de Google-ontwikkelaarsdocumentatie over ecommerce kun je gebeurtenissen instellen voor onder meer artikelweergave, winkelwagen, checkout en aankoop, en bevat een items-array de producten (ecommercemeting). Elk item heeft minstens item_id of item_name nodig, en Google adviseert de valuta op gebeurtenisniveau te zetten wanneer je een waarde meestuurt.

Log bij een shopwijziging dus extra:

• welke ecommercegebeurtenissen de wijziging raakt;
• of item_id nog hetzelfde artikelnummer gebruikt als vroeger;
• of valuta en waarde nog op dezelfde manier meegestuurd worden;
• welke testaankoop of testactie je deed om dit te valideren.

Wijzigt het type id dat je als item_id stuurt, dan zijn producten voor en na de wijziging mogelijk niet meer koppelbaar. Zo'n breuk wil je in het logboek zien staan voordat iemand een productrapport over de datum heen vergelijkt.

Een fictief scenario, uitsluitend invoer en verwachte controles. Een kmo vervangt een contactformulierplugin. De oude plugin stuurde een gebeurtenis met de naam formulier_verzonden, de nieuwe stuurt contact_submit. De beheerder maakt deze logboekregel:

1. Datum: de dag van publicatie van de nieuwe plugin.
2. Eigenaar: de webbeheerder, goedgekeurd door de marketingverantwoordelijke.
3. Oude definitie: formulier_verzonden, zonder parameters.
4. Nieuwe definitie: contact_submit, met een parameter voor het formuliertype.
5. Verwachting: formulier_verzonden stopt, contact_submit start; het rapport toont een naamswissel en geen gedragswijziging.
6. Validatie: testverzending met foutopsporingsmodus aan, met fictieve testgegevens zonder persoonsgegevens en bij voorkeur in een testomgeving; in DebugView verschijnt contact_submit met de parameter, en formulier_verzonden verschijnt niet meer. Dit bewijst de meting, niet dat de aanvraag in je mailbox of CRM aankwam; controleer dat apart.
7. Opvolging: de belangrijke gebeurtenis en bestaande aangepaste rapporten krijgen de nieuwe naam.

Een opvolger die later een daling bij formulier_verzonden ziet, leest de regel en weet dat dit een omschakeling is. Wil je ook de zichtbare signalen van je website bekijken, dan kan dat via Marketing Scan. Die publieke scan meet zichtbare signalen en voert de controles uit dit artikel niet voor je uit.