Eventparameters verschijnen niet in je rapport

Een parameter doorloopt een keten. Eerst stuurt je website hem mee met de event. Daarna ontvangt Analytics de event. Tot slot verwerkt Analytics de gegevens en toont ze in dimensies en statistieken in rapporten. De uitleg van Google over gebeurtenissen beschrijft die volgorde en noemt twee hulpmiddelen om ontvangst te controleren: het Realtime-rapport en DebugView.

Belangrijk voor je diagnose: dezelfde bron stelt dat aangepaste gebeurtenissen niet in de meeste standaardrapporten voorkomen, en dat je voor zinvolle analyse beter aangepaste rapporten of verkenningen gebruikt. Een parameter die in een standaardrapport ontbreekt, bewijst dus niet dat hij niet is ontvangen. Werk daarom altijd van links naar rechts door de keten en stop pas bij de eerste laag die niet klopt.

De ontwikkelaarsdocumentatie over events toont de syntaxis: een gtag-aanroep met het commando event, de eventnaam en optioneel een verzameling parameters. Controleer in je code dit:

• De aanroep wordt uitgevoerd nadat de Google-tag is geladen. Controleer in de actuele documentatie welke volgorde vereist is en test of de event in Realtime of DebugView verschijnt.
• De parameternaam is exact gelijk in code en in je latere instellingen. Let op hoofdletters, spaties en spelling.
• De waarde is niet leeg of niet ingevuld op het moment van verzenden, bijvoorbeeld omdat een formulierveld nog niet gelezen is.
• Je Tag Manager-trigger of cookietoestemming laat de event daadwerkelijk lopen. Dat check je door de event in een testbrowser te activeren.

Bekijk daarna in de netwerktab van de ontwikkelaarstools of de aanvraag naar Google de parameter bevat. Wil je iets aanpassen, dan vraagt de documentatie dat je toegang tot de broncode hebt en minstens de rol Editor in het Analytics-account. Controleer dat vooraf.

Zet de foutopsporingsmodus aan, zoals ook de documentatie over ecommercemeting aanraadt om events live te zien en problemen op te sporen. Voer daarna de actie één keer uit en kijk:

1. In Realtime verschijnt de event in de kaart met het aantal gebeurtenissen per naam. Klik de event aan en bekijk de meegestuurde parameters.
2. In DebugView zie je de events van één testgebruiker in volgorde, wat handig is om te controleren of de parameters juist zijn ingesteld.
3. Staat de parameter hier, dan is verzending en ontvangst in orde. Het probleem zit bij registratie of rapport.
4. Staat de parameter hier niet, dan ligt het probleem bij de code, de trigger of de toestemming. Ga terug naar stap 1.

Bij ecommerce-events gelden extra grenzen. De documentatie noemt een maximum van 27 aangepaste parameters in de items-array en 200 elementen in die array, en vraagt om de valuta op eventniveau te zetten als je een waarde meestuurt. Controleer ook de limieten voor aangepaste dimensies en statistieken.

Waar je dit in je account instelt en hoe het scherm heet, controleer je als beheerder in je eigen property. Schermnamen kunnen wijzigen.

Dit voorbeeld bevat enkel invoer en verwachte controles, geen uitkomsten.

Invoer: een aangepaste event met de verzonnen naam offerte_verzonden en een parameter dienst_type met de waarden onderhoud of installatie. De tester activeert de event één keer met dienst_type gelijk aan onderhoud, met foutopsporing aan.

• De event staat in Realtime en in DebugView.
• In de eventdetails staat dienst_type met exact de waarde onderhoud, in dezelfde schrijfwijze als in de code.
• De eventaanroep wordt uitgevoerd nadat de Google-tag geladen is.
• De parameter is als aangepaste dimensie geregistreerd onder dezelfde naam, en de limiet is niet bereikt.
• De dimensie wordt gezocht in een verkenning of aangepast rapport, niet enkel in een standaardrapport.

Overdracht aan de beheerder: geef eventnaam, parameternaam, voorbeeldwaarde, testtijdstip, de laag waar het mis ging en wat je al hebt gecontroleerd.

Herhaal na elke wijziging de keten met één nieuwe testevent en noteer per laag ok of niet ok. Test daarna een nieuwe event; controleer in de actuele documentatie of eerder verzonden events meekomen na een wijziging, en ga daar niet standaard van uit. Controleer in je eigen property en in de documentatie na hoeveel tijd gegevens in rapporten beschikbaar zijn, en neem dat als werkafspraak, niet als vaste termijn. Ontvangst in Realtime bewijst enkel dat Analytics de event kreeg, niet dat een rapport hem al toont.

Grenzen: dit is een voorstel voor eigen controles op basis van de genoemde documentatie. Schermnamen, limieten en rapportgedrag kunnen veranderen en je account kan afwijkende instellingen hebben.

Wil je ook de zichtbare signalen van je website bekijken? Kijk via Marketing Scan. Die scan bekijkt publieke signalen, ziet je interne Analytics-configuratie niet en voert niet alle controles uit dit artikel uit.