Accountaanmaak en actief gebruik apart rapporteren

Begin met woorden voor je met events begint. Maak voor je eigen bedrijf drie afzonderlijke definities en schrijf ze uit:

• Registratie: iemand maakt een account aan. Dit zegt iets over belangstelling, niet over gebruik.
• Eerste waarde: de eerste handeling waaruit blijkt dat de gebruiker iets nuttigs heeft gekregen. Bij een offertetool kan dat de eerste verzonden offerte zijn, bij een webshop de eerste bestelling, bij een kennisplatform het lezen van een eerste handleiding. Jij bepaalt dit voor jouw situatie.
• Terugkeer: dezelfde gebruiker voert na een zelfgekozen periode opnieuw een betekenisvolle handeling uit. Kies de periode op basis van de natuurlijke gebruiksfrequentie van je product, niet op basis van een algemene regel.

Het gevaar zit in het vermengen. Een rapport met enkel 'nieuwe accounts' laat een campagne die veel registraties zonder gebruik oplevert beter lijken dan een campagne met minder, maar actievere gebruikers.

Google Analytics meet interacties met events. Volgens de Analytics-hulppagina over events (Google Analytics-hulp: over gebeurtenissen) kun je met een event bijvoorbeeld meten dat iemand een pagina laadt, op een link klikt of een aankoop afrondt. De bron onderscheidt automatisch verzamelde events, events voor verbeterde meting, aanbevolen events en aangepaste events, en adviseert aangepaste events alleen te maken als geen van de andere bij je situatie past.

Voor registratie ligt dat een stuk eenvoudiger: de ontwikkelaarsdocumentatie (Google Analytics: gebeurtenissen instellen) vermeldt sign_up en login als voorbeelden van aanbevolen events. Gebruik die namen voor registratie en terugkeer-inloggen. Voor 'eerste waarde' heb je vaak een eigen event nodig, omdat dit sterk van je bedrijf afhangt. Als de eerste waarde een aankoop is, bestaan er aanbevolen e-commerce-events, beschreven op Google Analytics: e-commerce meten.

Houd je naamgeving consistent en documenteer elk event in een lijstje: naam, wanneer het afgaat, welke parameters het meegeeft en wie het beheert. Zonder dat lijstje weet over een jaar niemand meer wat 'first_use' precies betekent.

Doorloop deze checklist bij elk event dat in je rapport komt. Waar je dit in Analytics terugvindt, kan per accountversie verschillen; kijk na in je eigen beheeromgeving.

• Gaat het event maar één keer af per echte handeling, en niet ook bij het herladen van de bevestigingspagina?
• Staat het event na het laden van de Google-tag in je code? Controleer in je eigen omgeving of het event na de tag wordt afgevuurd en in Realtime verschijnt.
• Verschijnt het event in het Realtime-rapport met de juiste parameters nadat je het zelf hebt uitgelokt?
• Toont de DebugView-weergave bij een testgebruiker de volledige reeks events in de verwachte volgorde? De ontwikkelaarsdocumentatie meldt dat DebugView extra configuratie vraagt voordat je het kunt gebruiken.
• Kun je registratie en eerste-waardehandeling aan dezelfde gebruiker koppelen? Bepaal vooraf hoe je dit aanpakt en leg het vast. Gebruik daarvoor geen e-mailadres, naam of andere persoonsgegevens in eventparameters, URL's of gebruikers-ID; een event bewijst bovendien niet dat een account echt is aangemaakt, dus vergelijk de cijfers met je eigen systeem.
• Is de definitie van het event gedocumenteerd en door een tweede persoon gelezen?
• Is het event als key event gemarkeerd als het een succesactie voor je bedrijf meet? Controleer de benaming in je eigen omgeving.

Een lege rij in je rapport betekent niet altijd dat er niets gebeurt; het kan ook betekenen dat het event verkeerd staat. Test dus vóór je interpreteert.

Een fictief voorbeeld met uitsluitend illustratieve getallen, ter oefening van de redenering. Stel dat een bedrijf voor twee kanalen deze fictieve cijfers rapporteert over dezelfde periode:

Wie enkel naar registraties kijkt, kiest kanaal A. Reken je de verhoudingen uit, dan bereikt in A 20 van de 200 accounts (10 procent) de eerste waarde, in B 40 van de 80 (50 procent). Bij terugkeer is het 5 van de 20 in A tegenover 20 van de 40 in B. Die getallen zijn verzonnen en bewijzen niets over echte kanalen; ze tonen alleen hoe de ratio's werken.

De les is de rekenmethode: deel elke stap door de vorige, vergelijk telkens dezelfde groep over dezelfde periode en laat de absolute aantallen naast de verhoudingen staan. Let op kleine aantallen: bij heel weinig accounts zeggen verhoudingen weinig, en ze bewijzen geen oorzaak.

Er zijn twee manieren om dezelfde data te lezen, en ze beantwoorden een andere vraag. Kies bewust:

1. Totaaltelling per periode: hoeveel registraties, eerste-waardehandelingen en terugkeerders waren er in de maand? Handig voor een lopend overzicht, maar de groepen overlappen: een terugkeerder van deze maand kan zich vorige maand hebben geregistreerd.
2. Cohortbenadering: neem de accounts die zich in een bepaalde week registreerden en volg die groep. Hoeveel bereikten eerste waarde, hoeveel keerden terug? Dit beantwoordt de vraag of nieuwe accounts uiteindelijk actief worden.

Beslisregel: gebruik totaaltellingen voor capaciteit en dagelijkse opvolging, en cohorten wanneer je wilt weten of een wijziging aan je onboarding of campagne iets veranderde. Wijzig je tegelijk onboarding, prijs en campagne, dan kun je uit een cohortverschil geen oorzaak afleiden. Vergelijk daarom wat jij zelf kunt isoleren, en noem het geen bewijs maar een aanwijzing.

Bouw je rapport op in de volgorde van de gebruikersreis: registratie, eerste waarde, terugkeer. Zet de drie cijfers naast elkaar en toon telkens de verhouding met de vorige stap. Laat 'nieuwe accounts' nooit alleen in beeld staan.

Aangepaste events verschijnen volgens de Analytics-hulppagina niet in de meeste standaardrapporten, dus je hebt voor een zinvolle analyse waarschijnlijk een aangepast rapport of een verkenning nodig. Controleer in je eigen omgeving wat daarvoor beschikbaar is.

Maak een kort onderhoudsritueel: bij elke wijziging aan registratieformulier, onboarding of tagging voer je een testaccount uit, controleer je de events in Realtime en DebugView en noteer je de wijziging met datum. Zo kun je later een knik in je cijfers verklaren door een technische oorzaak in plaats van een marketingoorzaak. Wil je weten welke publieke signalen je website uitstraalt rond meting en registratie, bekijk dan Marketing Scan. Een publieke scan ziet wat van buitenaf zichtbaar is en kan niet bevestigen of je events juist zijn ingesteld; die controle blijft in je eigen Analytics-omgeving.