Ontwikkel- en intern verkeer uit GA4 filteren

Je opent GA4 en er staan 200 sessies op een URL die in productie niet bestaat. Of je bouncerate zakt elke maandag omdat het marketingteam zit te testen. Of er komt een gestaag straaltje verkeer vanaf localhost.

Rampzalig is het niet, maar laat je het staan dan blaast het je pageviews op, vertekent het je engagement-cijfers en vervuilt het elke doelgroep die je voor remarketing bouwt.

De term wordt losjes gebruikt. In de praktijk zijn het vier dingen:

• Staging. De testversie van je site, vaak op staging.jouwdomein.nl of dev.jouwdomein.nl, waar wijzigingen worden nagelopen voordat ze live gaan.
• Lokale ontwikkeling. De site op de laptop van een developer, op localhost, 127.0.0.1 of iets als mijnshop.local.
• Eigen mensen op de live site. Je team dat vanuit kantoor of thuis rondkijkt, of een campagne controleert.
• Geautomatiseerd testen. Cypress, Playwright, Lighthouse of uptime-monitors die volgens schema pagina's opvragen.

Laadt een van deze GA4 met hetzelfde measurement ID als productie, dan komen die events in dezelfde property als het gedrag van echte klanten.

Niet alles hoeft opgelost. Het hangt af van volume en bedoeling.

Wel filteren:

• Een staging-omgeving waar dagelijks getest wordt, al gauw tientallen tot honderden sessies per week en geen daarvan klantgedrag
• Een team van meer dan een man of vijf dat de live site regelmatig gebruikt voor support, content of campagnechecks
• Geautomatiseerde tests die bij elke deployment meerdere keren langskomen
• Een ontwikkelomgeving die purchase-events met testdata afvuurt, want dat blaast je omzet zichtbaar op

Niet de moeite:

• De incidentele sessie vanaf een laptop van een developer. Een handjevol per maand valt weg in de ruis.
• Eenmalige audits of debugsessies waarvan je de invloed toch al kent
• Sites onder ruwweg 1000 sessies per maand, waar het prima is om te fixen maar zelden dringend

Kort samengevat: filter staging altijd, want dat is de grootste bron, filter je kantoor-IP als je een echt kantoor hebt, en ga niet achter elke losse sessie aan.

De schoonste oplossing voegt niets toe aan GA4 of GTM. Kunnen je developers de container op staging weglaten, of een aparte staging-container laden, dan valt er niets te filteren.

De gebruikelijke opzet: productie laadt je echte container, staging laadt niets of een aparte container die naar een staging-property wijst.

Vraag je developers het GTM-snippet in een omgevingscheck te zetten, zodat het alleen wordt uitgeserveerd als de omgeving productie is. In de meeste stacks is dat één regel, en het haalt het probleem bij de bron weg.

Kun je niet voorkomen dat GTM op staging laadt, dan ligt de volgende oplossing in GTM zelf. Maak een Page View-trigger, Some Page Views, met de conditie Page Hostname matches RegEx:

(staging|dev|test|localhost|127\.0\.0\.1)

Hang die als blokkerende uitzondering aan elke GA4-tag, of aan de Google-tag zelf als die de ouder van allemaal is. Matcht de hostname, dan gaat er niets af en bereikt er niets GA4.

Dit gebruikt alleen ingebouwde GTM-functies. Geen Custom JavaScript, geen extra variabelen, en komt er een nieuwe staging-URL bij, dan pas je één regex aan.

GA4 heeft eigen filters die verkeer uitsluiten voordat het in je rapporten landt. Handig als tweede linie voor gevallen waar je zelf niet bij kunt, zoals een hardcoded measurement ID dat iemand vergeten is te verwijderen.

Intern verkeer. Leg je kantoor- of VPN-reeksen vast onder Beheer, Gegevensstromen, je stream, Tag-instellingen configureren, Intern verkeer definiëren. Zet daarna het ingebouwde filter Intern verkeer op Actief onder Beheer, Gegevensinstellingen, Gegevensfilters.

Ontwikkelverkeer. GA4 heeft een kant-en-klaar filter voor events die binnenkomen met debug_mode=true. Zet dat op Actief als je DebugView-events niet in je rapporten wilt.

Twee kanttekeningen: datafilters werken alleen vooruit, dus ze schonen nooit je historie op, en ze gelden voor de hele property zonder uitzondering per stream. Gebruik ze om restjes op te vangen, niet als je hoofdverdediging.

1. Vraag je developer of GTM op staging laadt. Zo ja, vraag om een omgevingscheck.
2. Zet in de tussentijd de hostname-uitzondering in GTM als snelle winst.
3. Zet de filters voor intern verkeer en ontwikkelverkeer in GA4 aan om op te vangen wat er doorheen komt.

Drie oplossingen, geen ervan vraagt Custom JavaScript, en ze stapelen: de eerste haalt het probleem weg, de tweede dekt de rest af, de derde vangt op wat overblijft.