Welke webshopgebeurtenissen zijn nuttig om te meten?

Begin met een klein aantal geaggregeerde gebeurtenissen, zoals productweergave, toevoegen aan winkelmand, starten van een testcheckout en een zichtbare fout.

Mag ik e-mailadressen naar analytics sturen?

Nee. Houd namen, adressen, e-mailadressen, bestelnummers, betaalinformatie en vrije invoer buiten analyticsgebeurtenissen.

Waarom moet ik toestemming meenemen?

Meten moet aansluiten op je eigen privacy- en consentinrichting. Laat scripts niet al gegevens versturen voordat de gekozen grondslag is vastgelegd.

Kan ik omzet meten met deze route?

Deze route richt zich op een veilig meetplan, niet op financiële rapportage. Laat financiële en fiscale verwerking door de bevoegde omgeving beoordelen.

Hoe weet ik of een event werkt?

Test één gebeurtenis met een veilige testactie en controleer dat alleen de allowlisted eventnaam en geen klantinhoud wordt doorgestuurd.

Webshop-analytics inrichten zonder klantdata: meetplan (2026)

Webshop-analytics richt je veilig in met een klein meetplan dat alleen gebeurtenissen bevat die een concrete vraag beantwoorden. Gebruik geen klant-, betaal- of inloggegevens en houd namen, e-mailadressen, adressen, bestelnummers, zoektermen en vrije tekst volledig buiten de meting.

Een goed begin is dus niet: alle beschikbare velden verzamelen. Begin met de vraag welke beslissing je na een meting wilt nemen, welke gebeurtenis daarvoor nodig is en hoe je die met een fictief product kunt testen. Deze route behandelt de technische inrichting op hoofdlijnen en vervangt geen privacy- of juridische beoordeling voor jouw webshop.

Stappenplan

1. Kies één vraag per gebeurtenis

Schrijf eerst drie tot vijf vragen op. Bijvoorbeeld: wordt een productpagina bekeken, wordt de gekozen variant toegevoegd aan de winkelmand en begint een bezoeker aan de checkout? Een foutgebeurtenis kan nuttig zijn als die alleen het paginatype en een vooraf gekozen foutcode bevat. De letterlijke fouttekst is ongeschikt, omdat daarin invoer of andere herleidbare inhoud kan belanden.

Google beschrijft een gebeurtenis als een specifieke interactie of gebeurtenis, zoals een paginaweergave, klik of aankoop, in de Analytics-documentatie. Dat betekent niet dat elk mogelijk detail nodig is. Gebruik per vraag de kleinst mogelijke gebeurtenis en noteer vooraf wat je met de uitkomst doet.

| Vraag | Veilige gebeurtenis | Toegestane context | Niet meesturen | | --- | --- | --- | --- | | Wordt een product bekeken? | view_product | paginatype, testvariant | titel met vrije invoer, klant-ID | | Komt een product in de winkelmand? | add_to_cart | testcategorie, hoeveelheid als getal | e-mailadres, sessie-inhoud | | Start de checkout? | begin_checkout | apparaatklasse, consentstatus | adres, bestelnummer, betaaldata | | Verschijnt een bekende fout? | checkout_error | vaste foutcode, stapnaam | letterlijke melding of formulierinhoud |

De namen in deze tabel zijn voorbeelden voor een eigen meetplan. Controleer de aanbevolen gebeurtenissen van je gekozen platform voordat je namen vastlegt, zodat je geen twee namen voor dezelfde handeling gebruikt.

2. Maak een dataminimale eventlijst

Leg per gebeurtenis de eigenaar, het doel, de trigger, toegestane parameters en bewaartermijn vast. Voeg ook een expliciete kolom toe met verboden velden. Zo is bij een thema- of tagwijziging meteen zichtbaar wat nooit doorgestuurd mag worden. Gebruik vaste waarden zoals productpagina of checkout, geen tekst die een bezoeker zelf heeft ingevoerd.

Neem consent als aparte technische voorwaarde op. De Google-tagrichtlijn voor consent mode beschrijft dat de standaardstatus moet zijn ingesteld voordat meetcommando's gegevens verzenden en dat de status na een keuze kan worden bijgewerkt. Welke keuze en grondslag voor jouw situatie passend zijn, bepaal je buiten deze technische checklist met de juiste deskundigheid.

Controleer ook indirecte gegevens. Een URL kan bijvoorbeeld een e-mailadres, zoekterm of intern orderkenmerk bevatten. Stuur daarom liever een vast paginatype dan de volledige URL en controleer queryparameters voordat je paginavigatie meet.

3. Maak een test die niemand hoeft te herleiden

Gebruik een herkenbaar fictief product zonder klantgegevens. Noteer vooraf de gebeurtenis die je verwacht, de toegestane velden en de uitkomst die juist is. Doorloop vervolgens precies één handeling. Voor de klantreis gebruik je het plan voor checkout testen; voor een verandering in laadtijd gebruik je snelheid controleren.

Controleer de gebeurtenis in een realtime- of debugweergave die bij je meetplatform hoort. Kijk niet alleen of de eventnaam verschijnt. Open ook de parameters en controleer dat er geen naam, adres, e-mailadres, bestelinformatie, betaalinformatie, vrije tekst of onverwachte URL in staat. Maak voor bewijs een korte notitie met tijdstip, testactie, eventnaam en resultaat. Een export van de volledige sessie is niet nodig.

4. Test consent en foutpaden afzonderlijk

Doorloop de test eerst zonder keuze, daarna met de relevante testkeuze en ten slotte na een gewijzigde keuze, voor zover je eigen consentinrichting dat ondersteunt. Verwacht niet automatisch hetzelfde gedrag in iedere toestand. Noteer per toestand welke tags wel of niet mogen werken en controleer het netwerkverkeer of de debugweergave met iemand die de inrichting kent.

Test ook een gecontroleerde fout, bijvoorbeeld een ontbrekend verplicht veld met fictieve invoer. De analyticsgebeurtenis mag alleen de vaste foutcategorie bevatten. Een schermopname, formulierwaarde of volledige technische payload kan meer gegevens bevatten dan je bedoelt en hoort niet in een algemeen hulpverzoek.

5. Scheid analyse van operationele systemen

Een analyticsplatform is geen orderadministratie, klantenbestand of boekhouding. Gebruik een geaggregeerd signaal om te zien waar een route mogelijk aandacht nodig heeft en onderzoek het operationele probleem vervolgens in het bevoegde systeem. Stuur geen orderregels of financiële details naar analytics om rapporten gemakkelijker te maken.

Loopt er een datastroom naar meerdere systemen, behandel die apart met het veilige testplan voor webshopkoppelingen. Leg vast welk systeem eigenaar is, welke gegevens het minimaal nodig heeft en hoe een mislukte overdracht zichtbaar wordt. Analytics mag geen stille omweg worden om toegangsregels van een ander systeem te passeren.

6. Maak onderhoud en verwijdering onderdeel van het plan

Geef iedere gebeurtenis een eigenaar en een controlemoment. Controleer na een nieuw thema, een checkoutwijziging of een nieuwe app of de trigger nog maar één keer afgaat en dezelfde minimale velden bevat. Verwijder gebeurtenissen die geen besluit ondersteunen. Een ongebruikte eventnaam blijft anders technische ruis en kan ongemerkt oude parameters blijven verzenden.

Houd een eenvoudig wijzigingslog bij: datum, reden, gewijzigde gebeurtenis, tester en terugvalstap. Zo kun je bij dubbele metingen of ontbrekende signalen terugvinden wat er veranderde zonder productiegegevens te delen.

Acceptatiecontrole

Een basismeetplan is pas klaar wanneer je onderstaande punten met fictieve gegevens hebt gecontroleerd:

elke gebeurtenis beantwoordt één beschreven vraag;
parameters komen uit een vooraf goedgekeurde lijst;
vrije tekst, volledige URL's en klant- of orderkenmerken ontbreken;
consenttoestanden zijn afzonderlijk getest;
een gebeurtenis gaat per bedoelde actie één keer af;
foutgebeurtenissen bevatten alleen een vaste code en stapnaam;
de eigenaar en verwijderroute zijn vastgelegd;
de checkout en productpagina blijven na de tagwijziging normaal werken.

Veelgemaakte fouten

Een volledige bestelpayload als gebeurtenis versturen. Voor een basismeetplan is een vaste gebeurtenis met minimale context genoeg.
Meten voordat de consentstatus technisch is ingesteld. Maak de volgorde van standaardstatus, bezoekerskeuze en update expliciet.
Iedere klik meten. Zonder concrete vraag ontstaat ruis en groeit de gegevensverzameling ongemerkt.
Vrije fouttekst opnemen. Daarin kunnen formulierwaarden of andere herleidbare gegevens staan.
Alleen controleren of een eventnaam verschijnt. Inspecteer ook parameters, aantal triggers en onverwachte netwerkverzoeken.
Analytics en boekhouddata vermengen. Houd financiële en operationele verwerking in de bevoegde systemen.
Een fout in productie testen met een echte klant. Gebruik een fictief product en een afgebakende testactie.

Officiële bronnen

Laatste controle

De gelinkte Google-documentatie over gebeurtenissen en consent mode is op 31 juli 2026 inhoudelijk opnieuw gecontroleerd. Platformdocumentatie kan wijzigen, dus vergelijk bij een latere technische aanpassing opnieuw de actuele instructies en je eigen privacybesluit.

Laatst bijgewerkt: 31 juli 2026.

Hulp nodig?

Wil je weten welke gebeurtenissen voor jouw webshop echt nodig zijn en hoe je die zonder klantdata test? stel je vraag via WhatsApp.