Een dalende sessieteller na consentwijziging

Een sessie ontstaat in Google Analytics uit gemeten gebeurtenissen. Volgens de documentatie over automatisch verzamelde gebeurtenissen horen first_visit, session_start en user_engagement bij wat standaard verzameld wordt zodra de tag draait (gebeurtenissen instellen in Analytics). Wordt de tag niet geladen of niets verstuurd, dan bestaat de sessie in je rapport niet, ook al heeft de bezoeker je site wel gebruikt.

Je sessieteller is dus het product van twee dingen: werkelijk gebruik (verkeer, campagnes, seizoen, bezoekers) en meetdekking (het aandeel van dat gebruik dat je tag effectief registreert). Een consentwijziging raakt vooral de tweede factor. Hoe jouw implementatie omgaat met bezoekers die weigeren, staat niet in de gebruikte bronnen. Dat hangt af van je consenttool, je tagbeheer en je instellingen. Je beheerder moet dat dus in die omgeving nagaan.

Zonder exacte tijdlijn blijft elke analyse giswerk. Maak een korte lijst met wat er wanneer veranderde, en let op dat banner, tagregels en code vaak niet op hetzelfde moment live gaan.

1. Noteer de datum en het uur waarop de nieuwe bannerversie live ging, en op welke domeinen of landversies.
2. Noteer elke andere release in dezelfde week: nieuwe thema, tagwijziging, campagnestart, migratie.
3. Vraag na of de standaardstatus van de keuzes veranderde (voorgeselecteerd, afgewezen, nog geen keuze).
4. Zet een notitie of annotatie in je rapportage, op de plek waar jullie team dat bijhoudt.
5. Kies twee vergelijkbare periodes van gelijke lengte, met dezelfde weekdagen, voor en na de datum.

Vergelijk geen week met vakantie of actie met een gewone week. Dat is een eigen verstoring, los van consent.

Om dekking te schatten heb je een referentie nodig die niet van de consentkeuze afhangt. Denk aan serverlogs, het aantal bestellingen in je shopsysteem, formulierinzendingen of afspraken in je agenda. Let op: een referentie met een eigen definitie meet nooit exact hetzelfde als een sessie. Gebruik hem dus als richtlijn voor verandering, niet als absolute waarheid.

Fictief rekenvoorbeeld, enkel als invoer: stel dat je referentiebron in periode A 2.000 bezoeken telt en Analytics 1.400 sessies. In periode B telt de referentie 2.000 bezoeken en Analytics 1.200 sessies. Je rekent per periode: Analytics gedeeld door referentie. Dat geeft 0,70 en 0,60. Blijft de referentie gelijk terwijl Analytics daalt, dan is lagere dekking een mogelijke verklaring, naast bijvoorbeeld een tagfout of andere wijzigingen in de meting. Daalt ook de referentie, dan is minstens een deel echt gebruik. De getallen hier zijn verzonnen om de rekenstap te tonen en zeggen niets over wat jij zult zien.

Gebruik je webshop, vergelijk dan ook het aantal aankopen in je shopsysteem met het aantal aankoopgebeurtenissen in Analytics. Dat is een scherpe controle op dekking van de belangrijkste actie.

Een daling kan ook een technische oorzaak hebben die niets met toestemming te maken heeft. De bronnen noemen twee controlepunten. Het Realtime-rapport toont de gebeurtenissen van de afgelopen 30 minuten, en DebugView toont alle gebeurtenissen van één gebruiker, en vraagt volgens de ontwikkelaarsdocumentatie extra configuratie (zoals foutopsporingsmodus) voor je het kunt gebruiken (uitleg over gebeurtenissen). Test beide met een eigen sessie in elk consentscenario: alles accepteren, alles weigeren, nog niets gekozen.

Controleer ook de plaatsing. Controleer of de gtag-aanroepen pas na het laden van het Google-tagfragment staan, want de gebruikte bronnen beschrijven die volgorde niet. Na een thema- of bannerwijziging kan de volgorde van scripts verschoven zijn, dus test dat in je eigen omgeving.

Gebruik je e-commerce, controleer dan of de aankoopgebeurtenis nog de juiste valuta en artikelgegevens meestuurt, zoals beschreven in de documentatie over e-commerce meten. Een stille fout daar kan omzetcijfers vertekenen zonder dat de sessieteller verandert.

Vul de tabel per kanaal of landversie in. Een gemiddelde over de hele site verbergt vaak waar het misloopt.

Geef de analyse door in een vast formaat, zodat een collega of leverancier niet opnieuw hoeft te beginnen. Zet erin: datum en versie van de wijziging, de twee vergeleken periodes, de dekkingsratio per periode, de testresultaten per consentscenario, en wat nog onzeker is. Schrijf onzekerheden letterlijk op. Je kunt bijvoorbeeld niet uitsluiten dat een deel van de daling aan seizoen ligt.

Herhaal de dekkingsratio na elke bannerwijziging, en ook na elke grotere release. Een tijdsvenster waarna alles stabiel is, kun je niet vooraf beloven. Beoordeel dus na elke meting of nieuwe data nog bij een andere periode horen.

Wil je zien welke signalen je site publiek toont, bekijk dan je eigen website via Marketing Scan. Een publieke scan ziet alleen zichtbare signalen en bewijst niet hoe je meting intern is ingericht, dus de testen hierboven blijven nodig.