Home › Blog › Google Analytics 4 › Hoe filter ik intern verkeer in Google Analytics 4

Hoe filter ik intern verkeer in Google Analytics 4

Een vertaling van het artikel How to exclude internal traffic in GA4 van Analytics mania.

Als je Google Analytics 4 implementeert, dan worden je eigen interacties/gebeurtenissen automatisch gemeten. Des te meer medewerkers je bedrijf heeft, des te groter het probleem. Elk bezoek/gebeurtenis dat wordt uitgevoerd door een collega beïnvloed jouw data. Gelukkig, kan dit worden opgelost door intern verkeer uit te sluiten in Google Analytics 4.

Echter zijn er wel een paar aandachtspunten. Als je jezelf uitsluit, dan ben je niet in staat om jouw interacties terug te zien in de DebugView (tijdens het testen met GTM). Althans dat is de ervaring. Dat is onhandig.

Als je meerdere mensen wilt uitsluiten, dan is het uitsluiten op basis van IP-adres mogelijk niet de beste oplossing. In dit artikel wil ik je laten zien hoe je intern verkeer uitsluit in Google Analytics 4 en tevens de bovengenoemde twee problemen aanpakt.

Desondanks zal ik de oplossing op basis van IP-adres ook meenemen.

 

BELANGRIJK: Wat vreemde zaken. Een vertraging?

Tijdens het schrijven van dit artikel, deed ik meerdere experimenten met filters in Google Analytics 4 om te begrijpen hoe ze werken (want niet elke scenario is duidelijk uitgelegd in de documentatie van Google).

Ik stuitte op de vreemde zaken op het moment dat ik verschillende resultaten ontving bij hetzelfde experiment. Ik heb het experiment namelijk meerdere keren uitgevoerd. Frustrerend, dus moest ik dieper graven. Uiteindelijk kwam ik tot de conclusie dat er enige vertraging is tussen het bewerken/wijzigen van het filter en wat je ziet in de DebugView.

Een voorbeeld, zelfs 10 minuten nadat ik de filter voor het intern verkeer had uitgeschakeld, zag ik mijn interacties/gebeurtenissen in de DebugView (totdat ik mijn IP-adres had aangepast).

Dit artikel is dus het resultaat van verschillende experimenten en ik hoop dat ik dat goed heb gedaan. Als je iets verkeerds opmerkt, laat het me dan weten.

Er is altijd een kans dat er gewoon iets niet goed werkte in Google Analytics 4 op dat moment en wellicht in de toekomst (op het moment dat je dit leest), is dit opgelost.

 

Het probleem met het filter voor intern verkeer in Google Analytics 4

Als je ooit geprobeerd hebt om inter verkeer uit te sluiten in Google Analytics 4, dan heb je waarschijnlijk al wat pagina’s gevonden over hoe je deze filter gebruikt. Je gaat naar Beheer → Gegevensstreams → X Gegevensstream → Meer instellingen voor taggen → Intern verkeer definiëren en voeg dan je IP-adres toe.

Daarna ga je naar Beheer → Gegevensinstellingen → Gegevensfilters → Intern verkeer en zet deze op actief.

Klaar! Je hebt het intern verkeer uitgesloten op basis van IP adressen. Maar er is een addertje onder het gras.

Wat als je jouw inter verkeer (inclusief je eigen verkeer) wilt uitsluiten, maar wanneer je de GA/GTM configuratie debugt, je eigen wel wilt terugzien in de DebugView van Google Analytics 4? Met de huidige configuratie is dat niet mogelijk. Je zal geen interacties/gebeurtenissen van jezelf terug zien in de DebugView. Tenminste, dat is wat ik heb ervaren.

Een optie is om een aparte GA4-property aan te maken om te testen. Als je in de voorbeeldmodus bent, dan kan je een Lookup-tabel variabele dat de juiste property activeert. Als je in de voorbeeldmodus bent, dan stuur je data naar de Test property. Als je niet aan het debuggen bent, dan stroomt de data naar de ‘echte’ property.

Er is nog een optie die ik met je ga delen. Het gaat om één (live) GA4-property. Als je niet debugt, worden jouw gegevens uitgesloten. Maar als je aan het debuggen bent (met de voorbeeldmodus van Google Tag Manager), dan zijn jouw gegevens zichtbaar in de DebugView (maar niet in de standaardrapporten). Zo vervuil je niet jouw gegevens.

 

Hoe werkt de filter intern verkeer

Eén laatste ding voordat we daadwerkelijk duiken in de technische configuratie.

Als je het intern verkeer definieert (bij ‘Meer instellingen voor taggen’ van een gegevensstream), Google Analytics 4 trackingcode (geactiveerd op jouw website) voegt een een parameter tt=internal toe bij elke verzoek. Deze parameter staat voor ‘Traffic type’ a.k.a. traffic_type.

De standaard filter voor intern verkeer (die kan gevonden worden bij Beheer → Gegevensinstellingen → Gegevensfilters) is voorgeconfigureerd om alle hits uit te sluiten dat de parameter traffic_type=internal bevat (tt=internal). En dit wordt uitgevoerd op het moment dat de filter is geactiveerd.

 

Methode 1 uitsluiten van intern verkeer via IP adres

Laten we beginnen met de klassieker. Dit zou kunnen werken als er niet veel mensen betrokken zijn bij het runnen van een bedrijf en je hun hits eenvoudig kan uitsluiten op basis van hun IP-adres. Deze methode werkt niet goed als je veel verschillende IP-adressen moet invoeren of als sommige IP-adressen niet statisch zijn (lees: regelmatig wisselt).

 

Stap 1 – Definieer jouw interne IP adres

In Google Analytics 4 ga je naar Beheer → Gegevensstreams en selecteer jouw stream. Klik vervolgens op ‘Meer instellingen voor taggen’.

En selecteer ‘Intern verkeer definiëren’. Hier kan je nieuwe intern verkeer regels maken. Als je werkt met meerdere IP’s, kan je voor ieder IP afzonderlijke regels maken. Ik hoop echt dat reguliere expressies (Regex) in de toekomst worden ondersteund.

Om het makkelijk te maken, kan je altijd ‘internal’ invoeren in het waardeveld traffic_type. Dan is het voldoende om slechts één filter voor intern verkeer te hebben in de gegevensinstellingen van jouw Analytics property.

Als je niet weet wat jouw IP-adres is, klik dan op de link aan de rechterkant.

 

Stap 2 – Maak een ontwikkelaar filter in Google Analytics 4

Je vraagt je misschien af wat het verschil is tussen een ontwikkelaarsfilter en een intern verkeersfilter in GA4. Beiden sluiten gegevens uit de reguliere rapportages in GA4 uit (door verschillende parameters te controleren).

Het ontwikkelaarsfilter controleert de parameters debug_mode of debug_event terwijl het interne verkeersfilter zoekt naar traffic_type.

Maar het belangrijkste verschil hier is dat u het ontwikkelaarsverkeer kunt zien in de DebugView van Google Analytics 4 terwijl het interne verkeer nergens wordt weergegeven. En als jouw hits naar Google Analytics zowel debug_mode als traffic_type=internal bevatten, krijgt de interne verkeersparameter een hogere prioriteit en kan je jouw hits niet zien in de DebugView.

Dus wat kunnen we hier doen? Dat beantwoord ik in het volgende hoofdstuk. Maar laten we eerst een ontwikkelaarsfilter maken (omdat het niet standaard is ingesteld). Ga in Google Analytics 4 naar Beheer > Gegevensinstellingen > Gegevensfilters > Filter maken. Selecteer ‘Ontwikkelaarsverkeer’. Voer de volgende instellingen in:

Je kan een naam invullen bij ‘Naam van gegevensfilter’. Zet deze filter voor nu op ‘Testen’. Maak de filter aan.

 

Stap 3 – Maak een lookup-tabel in Google Tag Manager om de traffic_type parameter te overschrijven

This is where the magic will happen. In de vorige hoofdstukken, heb ik aangegeven dat GA4 automatisch de parameter tt=interal (traffic_type) toevoegt aan alle hits als deze komt van een intern IP-adres.

Wat we gaan doen is het volgende. We maken een Lookup-tabel variabele aan dat de waarde van de parameter manipuleert. Als de voorbeeldmodus van Google Tag Manager actief is, dan veranderen we de waarde van ‘tt’ naar ‘developer’ (of iets anders). Maar als de voorbeeldmodus niet actief is, dan wordt de parameter niet aangepast.

Maak eerst een ongedefinieerde variabele. In GTM, ga naar Variabelen → Nieuw →  Undefined (onder het kopje Pagina variabelen).

Mocht deze optie er niet tussen staan, kies dan voor een Aangepaste JavaScript-macro. En schrijf het onderstaande stukje code in het tekstblok.

Nu gaan we de ingebouwde variabele ‘Debug Mode’ activeren. Ga naar Variabelen → Configureren en vink de checkbox aan bij ‘Debug Mode’.

Als laatste maken we een Lookup-tabel aan met de volgende instellingen. Variabelen → Nieuw → Lookup-tabel.

Hier gebruiken we de Debug Mode-variabele als invoer. Als de GTM voorbeeldmodus is ingeschakeld, retourneert deze variabele ‘true’, daarom retourneert de Lookup-tabel variabele het woord “developer”. Als de GTM voorbeeldmodus niet wordt gebruikt, retourneert de Debug Mode-variabele ‘false’, daaraan koppelen we de ‘undefined’ variabelen.

Dit is niet hetzelfde als gewoon “undefined” in het veld invoeren. In JavaScript is “undefined” tussen aanhalingstekens een tekenreeks (tekst). Maar ongedefinieerd betekent geen waarde. Als je alleen het woord undefined invoert in de opzoektabel, is dat een tekenreeks.

Sla de variabele op.

Ga ten slotte naar jouw Google Analytics 4-configuratietag en voer de volgende parameter in: traffic_type. En de waarde ervan zou de opzoektabel moeten zijn die je zojuist hebt gemaakt.

 

Stap 4 – Test de filters

Nu is het tijd om te testen. Activeer de voorbeeldmodus van Google Tag Manager. En ga naar jouw website (vanzelfsprekend, vanaf het IP-adres dat geconfigureerd is als intern verkeer in jouw Gegevensstream. Ga naar de DebugView van Google Analytics 4.

Allereerst, zou je hits moeten zien afkomstig van jouw apparaat. Klik op een willekeurige gebeurtenis in de gebeurtenissen stream en controleer the parameter traffic_type. De waarde moet ‘developer’ zijn.

In dezelfde gebeurtenis zou je ook de ‘Debug Mode’ parameter moeten zien.

Onthoud: beide filters (developer en internal) zijn nog niet actief. Deze zijn nog in de test-modus. Dit houdt in dat data nog zichtbaar is in de GA rapporten. Wanneer de filters in test-modus staan, wordt een extra dimensie toegevoegd genaamd ‘Testa data filter name. Je kan het gebruiken als secundaire dimensie (of in Analysis Hub) om te controleren hoeveel van de gegevens zouden zijn uitgesloten als de filters actief waren.

 

Stap 5 – Activeer beide filters

De laatste stap is het activeren van beide filters. Hiervoor ga je naar Beheer → Gegegevensinstellingen → Gegevensfilters en zet beide filters op Filterstatus ‘Actief’. Het is ook mogelijk om dit vanuit de lijst te doen (zie afbeelding).

Test het nog één keer.

1. Bezoek de website vanaf het IP-adres dat is gedefinieerd als ‘Intern verkeer’
2. Laat de voorbeeldmodus van Google Tag Manager inactief
3. Blader door jouw website (om zo enkele gebeurtenissen naar GA4 te sturen)
4. Controleer de DebugView. Je zou jouw apparaat niet moeten kunnen vinden. Er zouden ook geen nieuwe gebeurtenissen zichtbaar moeten zijn.
5. Activeer nu de voorbeeldmodus van GTM. Klik nog een keer door jouw website.
6. Controleer de DebugView. Je zou nu wel weer gebeurtenissen moeten zien verschijnen vanaf jouw apparaat.

 

Methode 2 – Uitsluiten intern verkeer middels de datalayer

Bij een andere methode zijn geen IP-adressen betrokken. Misschien is het voor de ontwikkelaars mogelijk om op de één of andere manier te identificeren dat de bezoeker/gebruiker die jouw website bezoekt een interne gebruiker is? Wellicht met behulp van een User ID, of misschien iets anders.

 

Stap 1 – De interne data in de datalayer plaatsen

Als het mogelijk is, moet je de ontwikkelaars vragen om de parameter user_type (of traffic_type, of wat dan ook) naar de datalayer te pushen. Zodat kan worden vastgesteld dat de bezoeker hoort bij jouw organisatie. Als een bezoeker bij jouw organisatie hoort, moet de waarde van de parameter ‘internal’ zijn. Als de bezoeker niet tot jouw organisatie hoort, dan moet er niets gepusht worden.

Hier is een voorbeeld van een dataLayer.push-code die de ontwikkelaar kan gebruiken.

<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    'event': 'traffic_type',
    'traffic_type': 'internal'
  });
</script>

Event sleutel is niet noodzakelijk (wel aanbevolen). Het is belangrijk dat deze code is geactiveerd voordat de GTM container snippet is geladen.

Maak vervolgens een Data Layer Variabele met de volgende instellingen”

 

Stap 2 – Maak een ontwikkelaars filter in GA4

GA in GA4 naar Beheer → Gegevensinstellingen → Gegevensfilters → Filter maken. Kies Ontwikkelaarsverkeer. En gebruik de volgende instellingen.

Zet de filter op ‘Testen’ (voor nu). En maak de filter aan.

 

Stap 3 – Maak een Lookup-tabel in GTM om de traffic_type parameter te overschrijven

GA naar Variabelen → Nieuw → Lookup-tabel en stel het volgende in:

Hier gebruiken we de Debug Mode-variabele als invoer. Als de voorbeeldmodus van GTM is ingeschakeld, retourneert deze variabele “true”, daarom retourneert de Lookup-tabel variabele het woord “developer”. Als de GTM voorbeeldmodus niet wordt gebruikt, retourneert de Debug Mode-variabele false, daarom retourneren we de waarde van de dataLayer variabele die je in de eerste stap hebt gemaakt.

Als de gegevenslaag de sleutel traffic_type bevat, wordt de waarde ervan naar GA verzonden. Als de sleutel niet bestaat, wordt deze ingesteld op “undefined” (wat betekent dat GA4 de sleutel traffic_type helemaal niet zal verzenden).

Sla de variabele op.

Ga ten slotte naar jouw Google Analytics 4-configuratietag en voer de volgende parameter in: traffic_type. En de waarde ervan zou de Lookup-tabel moeten zijn die je zojuist hebt gemaakt.

Volg hetzelfde proces als eerder omschreven in dit artikel.

 

Stap 5 – Activeer beide filters

De laatste stap is om beide filters te activeren. Ga naar Beheer (in GA4) → Gegevensinstellingen → Gegevensfilters en zet beide filters (intern verkeer en ontwikkelaarsverkeer) op actief. Het is ook mogelijk om dit vanuit de lijst te doen (zie afbeelding).

En test alles zoals we bij methode 1 al heb beschreven.

 

Methode 3 – Intern verkeer uitsluiten op basis van cookie

Een andere mogelijke manier om intern verkeer uit te sluiten in Google Analytics 4, is door een cookie te gebruiken. Je vertelt alle medewerkers om een bepaalde unieke URL te bezoeken, vervolgens plaats je een cookie met GTM en gebruik je de waarde ervan in de Lookup-tabel-variabele.

 

Stap 1 – Plaats een cookie voor interne gebruikers

Houd er echter rekening mee dat deze, net als elke andere methode die in dit artikel wordt genoemd, zijn gebreken heeft. Als de meeste medewerkers Safari gebruiken (of browsen met iOS), zal Intelligent Tracking Prevention de levensduur van een cookie beperken en zullen jouw werknemers die unieke link vaak opnieuw moeten bezoeken.

Laten we zeggen dat de URL van jouw website www.jouwbedrijf.nl is. Dan kan je jouw medewerkers vertellen om de volgende URL te bezoeken: www.jouwbedrijf.nl?internal_user=true

Ga vervolgens naar Google Tag Manager en maak een aangepaste HTML-tag, plak de volgende code erin:

<script>
 
 var cookieName = "gtm_internal_user"; // Name of your cookie
 var cookieValue = "internal"; // Value of your cookie
 var expirationTime = 31104000; // One year in seconds
 expirationTime = expirationTime * 1000; // Converts expirationtime to milliseconds
 var date = new Date(); 
 var dateTimeNow = date.getTime(); 

 date.setTime(dateTimeNow + expirationTime); // Sets expiration time (Time now + one month)
 var date = date.toUTCString(); // Converts milliseconds to UTC time string
 document.cookie = cookieName+"="+cookieValue+"; SameSite=None; Secure; expires="+date+"; path=/; domain=." + location.hostname.replace(/^www\./i, ""); // Sets cookie for all subdomains

</script>

Stel deze tag in om te worden geactiveerd bij een paginaweergave-trigger wanneer de pagina-URL internal_user=true bevat.

 

Stap 2 – Cookie variabele

GA naar Google Tag Manager Variabelen → Directe Cookie en stel de volgende instellingen in.

Bewaar de variabelen.

 

Stap 3 – Maak een ontwikkelaarsfilter in GA4

Creëer een ontwikkelaarsfilter in GA4, zoals ik eerder heb uitgelegd.

Hier gebruiken we de Debug Mode-variabele als invoer. Als de voorbeeldmodus van GTM is ingeschakeld, retourneert deze variabele “true”, daarom retourneert de Lookup-tabel variabele het woord “developer”.
Als de voorbeeldmodus van GTM niet wordt gebruikt, retourneert de Debug Mode-variabele “false”, daarom retourneren we de waarde van de Direct Cookie-variabele die je in de eerste stap hebt gemaakt. Als de cookie bestaat, wordt de waarde ervan naar Google Analytics gestuurd. Als de cookie niet bestaat, wordt deze ingesteld op “undefined” (wat betekent dat GA4 de sleutel traffic_type helemaal niet zal verzenden).

Sla de variabele op.

Ga ten slotte naar jouw Google Analytics 4-configuratietag en voer de volgende parameter in: traffic_type. En de waarde ervan zou de opzoektabel moeten zijn die je zojuist hebt gemaakt. Zie ook onderstaande afbeelding.

 

Stap 4 – Test de filters

Volg hetzelfde proces als ik eerder heb beschreven.

 

Stap 5 – Activeer beide filters

De laatste stap is om beide filters te activeren. Ga naar Beheer (in GA4) → Gegevensinstellingen → Gegevensfilters en zet beide filters (intern verkeer en ontwikkelaarsverkeer) op actief. Het is ook mogelijk om dit vanuit de lijst te doen (zie afbeelding).

 

Wachten op krachtigere filters in Google Analytics 4

Op het moment van schrijven van dit artikel lopen GA4-filters nog steeds ver achter op die van Universal Analytics. Hopelijk hebben we in de toekomst krachtigere opties om het interne verkeer uit te sluiten (bijvoorbeeld op basis van een aangepaste dimensie).

Stuur interne gegevens naar een aparte GA4 property
Dit is optioneel, maar als je wilt, kan je de interne gegevens naar een aparte property sturen (in plaats van te spelen met de parameter traffic_type zoals we hierboven hebben gedaan). Ik ga dit niet stap voor stap uitleggen. In plaats daarvan zal ik het met een algemeen overzicht uitleggen en jou de ruimte geven om hiermee te spelen.

In principe kan je een Lookup-tabel variabele maken die de juiste GA4 measurment ID kiest op basis van een variabele die het intern verkeer kenmerkt. Laten we dus zeggen dat je een cookie-variabele hebt ‘Cookie – intern verkeer’ en de waarde ervan is “true” als de bezoeker een medewerker is.

Ga in dat geval naar Google Tag Manager, kies voor Variabelen > Nieuw > Lookup-tabel en voer de volgende instellingen in:

Als de waarde van de cookie variabele gelijk is aan “true”, wordt het Measurement ID van de Test property geretourneerd (je moet hier trouwens een aparte GA4 property voor aanmaken). In alle andere gevallen retourneert de variabele het Measurement ID van jouw “normale” property.

De laatste stap is om deze Lookup-tabel in jouw GA4-configuratietag in te voegen.

 

Laatste woorden: Intern verkeer uitsluiten in Google Analytics 4

Het belangrijkste voordeel van het uitsluiten van het intern verkeer zoals ik dat doe is dat het zichtbaar blijft in de DebugView zolang als de GTM voorbeeldmodus ingeschakeld is. Op die manier kan je je eigen inkomende hits debuggen zonder handmatige aanpassingen te doen.

Houd in gedachte dat geen van de gegeven oplossingen perfect zijn:

1. Filters die gebaseerd zijn op IP-adres zullen niet werken als medewerkers een dynamische IP adres hebben.
2. De op dataLayer.push gebaseerde filtering, vereist wat hulp van een ontwikkelaar. Daarbij kan er enkele medewerkers worden gemist die anoniem browsen en nergens zijn ingelogd. Hierdoor kan de ontwikkelaar deze medewerkers niet identificeren.
3. De op Cookie gebaseerde oplossing is, logischerwijs, gebaseerd op cookies. Cookies kunnen niet worden gedeeld op meerdere apparaten van dezelfde bezoeker. Cookies kunnen worden verwijderd. Cookies verlopen eerder vanwege ITP op iOS of Safari. Het is dus mogelijk dat medewerkers regelmatig die unieke URL (die de cookie instelt) opnieuw moeten bezoeken.

Ik hoop echt dat mijn experimenten met filters correct waren en dat als je je interne verkeer inderdaad uitsluit, het niet wordt weergegeven in de foutopsporingsweergave (totdat je de wijzigingen aanbrengt met de Lookup-tabel). Als ik het daarentegen bij het verkeerde eind heb, laat het me dan weten en ik zal de gids dienovereenkomstig bijwerken.

Met toestemming van Julius Fedorovicius (auteur) is dit een vertaling van het artikel How to exclude internal traffic in Google Analytics 4 – Analytics mania.