Een event bevat e-mailadressen: herstel de meting

De Analytics-hulppagina over het vermijden van persoonlijk identificeerbare informatie (https://support.google.com/analytics/answer/6366371) stelt kort gezegd dat je geen gegevens naar Google mag sturen die als PII herkenbaar zijn, en noemt e-mailadressen uitdrukkelijk. De pagina wijst ook op typische lekplekken: pagina-URL's en paginatitels, door gebruikers ingevoerde tekst in zoekvakken en formulieren, aangepaste dimensies, campagneparameters en zoektermen.

De bron zegt niet waar het e-mailadres in jouw site vandaan komt. Dat moet je zelf uitzoeken. Ze zegt ook niet of jouw situatie juridisch problematisch is; daarvoor verwijst ze zelf naar een jurist bij twijfel. Hou die twee werelden gescheiden: jij onderzoekt de techniek, iemand anders beoordeelt de privacykant.

Begin met een korte vaststelling, zonder de gegevens elders te kopiëren.

1. Noteer in welk rapport of welke weergave je het adres zag en welke eventnaam erbij hoort.
2. Noteer in welke parameter of dimensie het stond (bijvoorbeeld paginapad, paginatitel, zoekterm of een eigen parameter).
3. Noteer een datumbereik waarin je het zag, zonder zelf een begindatum te veronderstellen. Dat bereik is een vaststelling, geen conclusie.
4. Maak geen schermafbeeldingen of exports met de adressen zelf. Beschrijf liever het patroon, zoals 'tekst met een apenstaartje'.

Zo heeft de persoon die de privacybeoordeling doet een bruikbaar dossier, zonder dat je de gegevens verder verspreidt.

Een adres komt zelden uit het niets. Gebruik onderstaande matrix om per type plaats te zoeken.

Kijk daarna naar de eventdocumentatie (https://developers.google.com/analytics/devguides/collection/ga4/events): een event bestaat uit een naam en optionele parameters, en je kunt die zelf via gtag.js of Tag Manager meegeven. Een waarde in zo'n parameter komt meestal uit jullie eigen code of configuratie, maar kan ook uit een URL, paginatitel of een tag van een derde partij komen. Controleer dat per geval.

Weet je al dat een parameter of tag adressen verstuurt, pauzeer of verwijder die dan meteen, nog voor je alle andere bronnen hebt geïnventariseerd. Beslis daarna per bron, in deze volgorde:

• Is de parameter nodig voor een rapportage? Zo niet, verwijder hem uit het event of de tag.
• Is er wel een doel, maar is het adres zelf overbodig? Stuur dan een neutrale waarde, zoals 'formulier ingediend', in plaats van de invoer.
• Zit het in de URL? Haal het adres uit de bevestigingslink en voorkom dat formulierinvoer in de URL terechtkomt. POST kan helpen voorkomen dat invoer als queryparameter verschijnt, maar is op zichzelf geen oplossing voor analytics-tags die het adres uit velden, pagina-inhoud of eigen parameters lezen. Controleer en verwijder ook die doorgifte.
• Kan je de bron niet meteen aanpassen? De hulppagina vermeldt een instelling voor het verbergen van gegevens in het beheerdersgedeelte, bedoeld om e-mailadressen en queryparameters zo goed mogelijk te verwijderen, voor webgegevensstreams. Ze spreekt van 'zo goed mogelijk', dus beschouw dit als een extra laag en niet als vervanging van de bronfix. De beheerder controleert in zijn eigen account waar deze instelling staat en welke rechten nodig zijn.

Houd de bekende lekkende tag of parameter uitgeschakeld terwijl je de vervanging in een testomgeving controleert. Activeer de herstelde meting pas opnieuw na die controle.

Een gepubliceerde fix is nog geen bewezen fix. Test eerst in een aparte testproperty of met analytics-netwerkverzoeken onderschept, zodat ook synthetische adressen niet in de productieproperty terechtkomen. Een voorbeeldmodus alleen garandeert dat niet. Controleer in drie lagen.

1. Verzoek bekijken: doorloop de flow met een duidelijk nep-adres (bijvoorbeeld een adres op een testdomein dat jij beheert) en bekijk in de netwerktab van je browser welke gegevens naar Analytics gaan.
2. Realtime of debugweergave: controleer of het eventbericht de parameter nog bevat. Waar die weergave precies staat, kan veranderen; de beheerder zoekt dit na in de eigen interface.
3. Latere rapportage: kijk nadien of nieuwe rijen met adressen blijven verschijnen. Verwacht niet dat reeds verzonden gegevens vanzelf verdwijnen. Of en hoe je die laat verwijderen, hoort bij de privacybeoordeling en de mogelijkheden van het account.

Controleer dat je testomgeving werkelijk de testproperty gebruikt of dat uitgaande analytics-verzoeken worden onderschept; een rapportfilter is geen vervanging voor die scheiding. Test minstens de pagina's uit je matrix, plus een tweede browser en een mobiel toestel, want tags kunnen verschillen per template.

Fictief voorbeeld, enkel als invoer: een bevestigingspagina na inschrijving heeft een pad met een queryparameter 'mail' die een waarde in e-mailvorm bevat (hier bewust niet voluit uitgeschreven). Verwachte technische controles: de adresbalk bij stap vier van de flow, de netwerkaanvraag naar Analytics, de tagconfiguratie voor parameters en de beheerdersinstelling voor het verbergen van queryparameters.

Geef dit door als een korte notitie met vijf regels: waar gezien, welke parameter, vermoedelijke bron, genomen of voorgestelde technische stap, openstaande vraag voor de privacyverantwoordelijke of jurist. Laat die laatste beslissen over melding, verwijdering en communicatie. Wil je zien welke publieke signalen je site zichtbaar maakt, bekijk ze dan via Marketing Scan. Die publieke scan toont alleen zichtbare signalen en controleert niet je volledige tagconfiguratie.