Te veel unieke waarden in GA4: beperk cardinaliteit

Een rapport is bedoeld om te vergelijken. Je wil weten welk type zoekopdracht vaak voorkomt, niet dat 'gele lamp 40 cm' een keer werd ingetypt. Zodra bijna elke waarde uniek is, kan je niet meer groeperen, tellen of vergelijken. Daar komt bij dat je een lange staart aan rijen moet doorlezen om één patroon te vinden.

De typische oorzaken zijn:

• de volledige tekst uit een zoekveld of contactformulier als parameterwaarde;
• een e-mailadres, naam of telefoonnummer dat per ongeluk meegaat;
• een volledige URL met query-onderdelen of een tijdstempel als waarde;
• een eigen ID per bezoek of per formulierinzending als dimensie.

Het laatste type moet je niet categoriseren maar niet versturen, tenzij je er echt mee analyseert. Hoe GA4 zulke rapporten precies toont of samenvoegt, kan wijzigen. Controleer dat in je eigen property in plaats van het aan te nemen.

De GA4-documentatie over events beschrijft dat events bestaan uit een naam en optioneel een verzameling parameters, en dat je naast automatische en aanbevolen events ook zelf custom events definieert. Gebruik dat model als structuur voor je inventaris.

1. Maak een lijst van elk custom event dat op je site wordt verstuurd, met de naam en de parameters. Haal dit uit de code of uit je tagbeheer. De beheerder heeft hiervoor toegang tot de broncode of de tagtool nodig.
2. Open per parameter je rapportage en kijk hoeveel verschillende waarden zichtbaar zijn en hoe verdeeld ze zijn. Hoe je een parameter als dimensie beschikbaar maakt of bekijkt, controleer je in je eigen beheer, omdat schermen kunnen wijzigen.
3. Markeer parameters waarvan de meeste waarden maar één keer voorkomen.
4. Open enkele echte waarden en kijk of er persoonlijke gegevens in zitten. Zo ja, behandel dat eerst en apart.

Resultaat: een tabel met event, parameter, voorbeeldwaarden en een oordeel 'bruikbaar', 'te gedetailleerd' of 'niet versturen'.

Gebruik deze matrix om per parameter de keuze te maken.

Regel: een parameter heeft alleen waarde als je er een vraag mee beantwoordt. Formuleer die vraag vooraf, bijvoorbeeld 'Welke productgroepen zoeken bezoekers zonder resultaat?', en bepaal dan welke categorieën daarvoor nodig zijn.

Categoriseren betekent dat jij de omzetting beheert. Ontwerp daarom een eenvoudig schema:

• Beperkte lijst: houd het aantal categorieën hanteerbaar en voeg één categorie 'overig' toe voor wat nergens past.
• Mappingtabel: leg vast welke woorden of productgroepen bij welke categorie horen, bijvoorbeeld in een gedeeld document met datum en eigenaar.
• Vaste schrijfwijze: één taal, kleine letters, geen spaties wisselend met streepjes, zodat 'Verlichting' en 'verlichting' niet als twee waarden verschijnen.
• Aparte indicator voor resultaat: bijvoorbeeld een klasse voor 'geen resultaat', 'weinig' en 'veel', in plaats van het exacte aantal.

Controleer regelmatig hoeveel zoekopdrachten in 'overig' belanden. Wordt dat deel te groot, dan mist je schema categorieën. Pas het dan aan en noteer de wijzigingsdatum, zodat je later weet vanaf wanneer de rapporten niet meer vergelijkbaar zijn met ervoor.

Fictieve invoer: een webwinkel stuurt nu bij elke interne zoekopdracht een event met de volledige zoektekst. Bezoekers typen soms ook een e-mailadres in het zoekveld.

Gewenste aanpassing: het event bevat een categorieparameter en een resultaatklasse, en geen ruwe tekst. De syntaxis volgt de opbouw uit de events-documentatie: een event-opdracht, een eventnaam en een verzameling parameters, bijvoorbeeld een custom event 'zoekopdracht' met parameters zoals 'zoek_categorie' en 'resultaat_klasse'. Plaats de code onder het Google-tagfragment, want volgens diezelfde documentatie verwerkt Google geen events die erboven staan.

Verwachte technische controles:

1. Zoek op een gewoon productwoord: het event bevat de juiste categorie en geen ruwe tekst.
2. Zoek op iets dat op een e-mailadres lijkt: het event bevat 'overig' of geen waarde, en nergens in de gegevens verschijnt dat adres.
3. Zoek zonder resultaat: de resultaatklasse toont 'geen'.
4. Controleer ook de URL van de zoekresultatenpagina: bevat de zoekterm in een queryparameter persoonlijke invoer, dan hoort die niet in de verzamelde paginagegevens.

Test na elke aanpassing met enkele vaste zoekopdrachten en bekijk de binnenkomende events in een realtime- of debugweergave, indien beschikbaar in je property. Controleer later in je rapport of het aantal verschillende waarden per parameter gedaald is en of je oorspronkelijke vraag nu beantwoord wordt. Zo niet, pas het schema aan.

Let op de grenzen. Volgens de richtlijnen van Google over persoonlijk identificeerbare informatie mag je geen PII doorgeven, moet je door bezoekers ingevoerde PII uit zoekvakken en formuliervelden verwijderen voor verzending en mogen ook aangepaste dimensies en Site Search-dimensies geen PII bevatten. Dezelfde pagina noemt een instelling 'gegevens verbergen' in het gedeelte Beheerder, alleen voor webgegevensstreams, die e-mailadressen en ingevoerde queryparameters 'zo goed mogelijk' verwijdert. Dat is dus geen garantie: de beheerder controleert zelf of en hoe die bij jou beschikbaar is en test met voorbeelden of er niets doorkomt. Twijfel je of iets als PII geldt, vraag dan een jurist. Dit artikel is geen juridisch advies.

Wil je zien welke publieke signalen je website toont, bekijk ze via Marketing Scan. Een publieke scan ziet geen interne GA4-configuratie en vervangt je eigen controle van events en parameters niet.