Dezelfde eventnaam heeft drie betekenissen

Een event meet volgens de uitleg over gebeurtenissen in Google Analytics een specifieke interactie, zoals een paginaweergave, een klik of een aankoop. De naam is dus slechts een label. Wat het label betekent, hangt af van de trigger die het verstuurt.

Drie typische oorzaken:

• Meerdere bouwers: een bureau zet 'lead' op de knop, een collega zet dezelfde naam op de bedankpagina.
• Meerdere tags of plekken: hardgecodeerde code en een tagbeheerder sturen allebei een event met dezelfde naam.
• Betekenisverschuiving: het formulier verandert, de trigger blijft, maar de definitie klopt niet meer.

Het gevolg is dubbeltelling, een niet te vergelijken reeks of een belangrijke gebeurtenis die iets anders meet dan je team denkt. Dat ontdek je meestal pas als twee mensen verschillende cijfers presenteren.

Maak een gedeeld document met één rij per eventnaam. Zonder rij bestaat de eventnaam niet officieel. Gebruik minstens deze kolommen:

1. Eventnaam exact zoals verstuurd, inclusief underscores.
2. Type: automatisch, verbeterde meting, aanbevolen of aangepast.
3. Trigger: de technische gebeurtenis, bijvoorbeeld 'succesvolle verzending van formulier X, niet het klikken op de knop'.
4. Definitie in gewone taal: één zin die ook een niet-technisch teamlid begrijpt.
5. Parameters: welke meegestuurd worden en met welke toegelaten waarden.
6. Eigenaar: één persoon die beslist, geen afdeling.
7. Gebruikt in: rapporten, doelgroepen, belangrijke gebeurtenissen.
8. Status en wijzigingsdatum: actief, vervangen of uitgefaseerd.

De kolom 'Gebruikt in' is vaak de nuttigste. Ze toont meteen wie last heeft als je een event aanpast.

Werk per verdachte eventnaam in deze volgorde:

1. Lijst alle bronnen. Zoek in de broncode en in je tagbeheerder naar de eventnaam. Noteer elke plek waar hij wordt verstuurd.
2. Test elke trigger afzonderlijk. De uitleg over gebeurtenissen noemt het Realtime-rapport, waar je per gebeurtenisnaam de laatste 30 minuten ziet, en DebugView, dat de gebeurtenissen van één gebruiker toont. Voor DebugView moet de foutopsporingsmodus aanstaan.
3. Vergelijk parameters. Drie bronnen sturen vaak drie verschillende parametersets mee. Dat verraadt de verschillende betekenissen.
4. Tel per handeling. Voer één handeling uit, bijvoorbeeld één formulier, en tel hoeveel events met dezelfde naam verschijnen.
5. Leg vast wat je ziet in de woordenboekrij, ook als de uitkomst onverwacht is.

Een browsertest toont wat jouw sessie verstuurt. Of alle gebruikers via dezelfde route gaan, moet je afzonderlijk nagaan.

Kies per eventnaam met deze matrix. Voor aanbevolen events controleer je de naam en parameters in de documentatie over het instellen van events, die vier categorieën onderscheidt. Aangepaste events kies je volgens de documentatie alleen als geen automatisch, verbeterd of aanbevolen event past.

Een nieuwe naam is meestal veiliger dan een bestaande naam een andere betekenis geven, want dan blijft de oude reeks eerlijk gelabeld.

Dit is een denkbeeldig invoervoorbeeld, zonder resultaten. Een kmo vindt in haar property het event 'lead' en vermoedt drie bronnen.

• Bron A: klik op de knop 'Verstuur' in het contactformulier.
• Bron B: laden van de bedankpagina.
• Bron C: een extra tag die 'lead' stuurt bij een telefoonlink.

Verwachte technische controles: stuur één formulier in en kijk in DebugView hoeveel keer 'lead' verschijnt. Verschijnt het twee keer, dan overlappen A en B. Open de parameters van elk event en noteer welke verschillen. Bekijk daarna in het woordenboek wie 'lead' gebruikt.

Mogelijke beslissing: B behouden onder een eigen duidelijke naam, of onder een aanbevolen naam zoals 'generate_lead' als je in de documentatie over aanbevolen events hebt gecontroleerd dat naam, parameters en trigger echt passen bij deze handeling. A hernoemen naar 'form_submit_click', C naar 'phone_click'. De eigenaar tekent de nieuwe definities af. Welke cijfers dit in jouw property oplevert, weet je pas na je eigen metingen.

Een wijziging is pas klaar als je ze hebt gecontroleerd en vastgelegd.

1. Test na publicatie opnieuw in Realtime en DebugView, op het toestel en de route die je klanten gebruiken.
2. Noteer de wijzigingsdatum in het woordenboek en als aantekening bij je rapporten, zodat niemand een reeks over de breuk heen vergelijkt zonder het te weten.
3. Werk afhankelijke items bij: doelgroepen, belangrijke gebeurtenissen en eigen rapporten die de oude naam gebruiken.
4. Behandel ecommerce apart. De documentatie over ecommercemeting adviseert onder meer valuta op eventniveau bij waardegegevens. Controleer daarom bij aankoopevents ook de parameters, niet alleen de naam.
5. Plan een nacontrole na enkele dagen met echte verkeersdata en vergelijk die met je verwachting.

Voor de overdracht volstaat het woordenboek plus een korte lijst van openstaande beslissingen. Wil je ook zien welke signalen je website publiek toont, bekijk dan Marketing Scan. Een publieke scan meet zichtbare signalen en bewijst geen volledige implementatie van je events.