Het kan soms een nachtmerrie zijn om accurate Google Analytics 4 gegevens te krijgen. Vooral als je een groot bedrijf bent met veel werknemers die aan je website werken of een klein bedrijf dat net begint met het genereren van verkeer. Een van de statistieken die je gegevens het meest vertekenen is verkeerd gefilterd intern verkeer. Dit type verkeer wordt vaak geregistreerd als meer betrokken, meer terugkerend en met een langere kijktijd dan een gemiddelde gebruiker. Van ontwikkelaars, testers, beheerders, enz. wordt verwacht dat ze zich veel bezighouden met je website tijdens het ontwikkelen en testen van verschillende aspecten. Hieronder volgt een korte lijst met risico's of symptomen waarmee je te maken kunt krijgen als je intern verkeer niet filtert.

• Onnauwkeurige betrokkenheidsmeting
• Onjuiste conversietracking
• Onnauwkeurige analyse van de verkooptrechter
• Onjuiste identificatie van het verbeteringsgebied
• Ineffectieve A/B-tests
• Enz.

In dit artikel bespreken we de drie beste methoden om intern verkeer uit te sluiten in Google Analytics 4. Als je deze toepast, zullen je Analytics 4-rapportagegegevens aanzienlijk verbeteren.

Intern verkeer uitsluiten met Google Tag Manager

In dit artikel gaan we ervan uit dat je bekend bent met Google Tag Manager (GTM) en dat je het gebruikt om Google Analytics 4 (GA4) op je website te implementeren. Als je GTM niet gebruikt, is alleen het eerste deel van dit artikel op jou van toepassing. Hoe dan ook, je kunt nog steeds de strategieën in dit artikel leren en ze gebruiken om verkeer te filteren door in de broncode te duiken. Daarnaast raad ik je ten zeerste aan om Analytics te implementeren met GTM op je website, omdat het veel voordelen biedt, maar dat is een ander artikel voor een andere keer!

Voordat we beginnen - Als je niet technisch onderlegd bent en graag iemand hebt die je analysegegevens opschoont en een aantal eersteklas rapporten maakt, neem dan contact met ons op! We bieden verschillende diensten aan, plan een gratis kennismakingsgesprek in.

1. Hoe verkeer van interne IP-adressen filteren

Het eerste en eenvoudigste onderdeel van het opschonen van je analysegegevens is het uitfilteren van je interne IP-adressen. Dit is waarschijnlijk de minst technische en meest impactvolle filter die iedereen zou moeten toepassen. Of je nu een bedrijf hebt met veel werknemers of een freelancer bent die thuis zit, je wilt waarschijnlijk niet dat Analytics rekening houdt met verkeer dat afkomstig is van het netwerk van je bedrijf.

Stap 1. Definieer uw interne IP-adressen

Ten eerste moet je je IP-adres kennen of de reeks IP-adressen die als “intern” worden beschouwd.

Als je maar één IP hebt, raad ik aan zoeken op Google “wat is mijn IP” om te bepalen welk IP-adres je hebt. Houd rekening met eventuele VPN- of proxyservices die actief zijn en die je IP-adres kunnen beïnvloeden.

Als je deel uitmaakt van een grotere organisatie met meerdere IP-adressen, reeksen of VPN's, raad ik je aan om contact op te nemen met de IT-afdeling van je bedrijf.

Wanneer je je IP-adres hebt bepaald, ben je klaar om dit te configureren in Google Analytics, dus laten we daar beginnen. Open in je Analytics-dashboard de gewenste eigenschap en klik op “Gegevensstromen”. Open de relevante gegevensstroom.

Zoek vervolgens naar “Meer tagging-instellingen” en klik op “Intern verkeer definiëren”. Maak een nieuw item.

Definieer het IP-adres of de IP-adressen die je als “intern” wilt beschouwen. De IP's die je hier definieert zullen uiteindelijk worden uitgefilterd en niet worden beschouwd als websiteverkeer door Google Analytics. U kunt meerdere regels, bereiken, enz. toevoegen, afhankelijk van uw situatie.

Zorg ervoor dat je op aanmaken klikt. Nadat je intern verkeer hebt gedefinieerd, ben je klaar om naar de volgende stap te gaan.

Stap 2. Test uw interne IP-filter

Nu je intern verkeer gedefinieerd is, moeten we het eruit filteren. Ga hiervoor naar je eigenschap en zoek naar “Gegevensinstellingen”. Klik daar op “Gegevensfilters”.

Standaard zou je al een filter genaamd “Intern verkeer” moeten hebben in de status Testen. Als dit niet het geval is, maak dan een nieuwe filter zoals in de onderstaande schermafbeelding.

Dat is het! Je kunt nu beginnen met het testen van je filter. We zullen het testen van filters niet behandelen in dit artikel, maar het is zo eenvoudig als wat intern verkeer naar GA4 sturen, een vergelijking toevoegen en de filter voor intern verkeer uitsluiten. Als je ziet dat het interne verkeer wordt uitgefilterd in deze nieuwe vergelijking, kun je aan de slag!

Stap 3. Pas uw filter toe

De laatste stap is het toepassen van een filter en genieten van veel schonere Google Analytics-gegevens! Vervolgens zullen we zien hoe we onze gegevens nog beter kunnen opschonen, maar daarvoor heb je Google Tag Manager nodig.

2. Hoe te voorkomen dat filters de debugmodus blokkeren in Google Analytics

Door standaard je interne IP-adressen uit te filteren zoals je in stap 1 hebt gedaan, kun je geen sessie-informatie meer bekijken in de “DebugView” van Google Analytics. Dit kan zeer waardevol zijn om snel bepaalde gebeurtenissen te testen, ook al kan de DebugView zelf behoorlijk buggy zijn. Ik weet het, het is nogal ironisch!

Stap 1. Maak een ontwikkelfilter in GA4

Ga net als in het eerste deel naar je eigendom en zoek naar “Gegevensinstellingen”. Klik daar op “Gegevensfilters” en maak een nieuwe filter voor ontwikkelaarsverkeer volgens de specificaties in de schermafbeelding hieronder.

Klik nu gewoon op “Create”. Vervolgens gaan we een manier maken om “DebugView” toe te staan, zelfs als je op een intern IP zit.

Stap 2. Maak een opzoektabel om het juiste type verkeer naar Google Analytics te sturen

De strategie hier is om de variabele traffic_type naar Google Analytics te sturen en deze te vullen met een lege waarde (als we niet actief aan het debuggen zijn) of met een andere waarde dan “intern”. “developer” is de waarde die we in deze tutorial zullen gebruiken. Het resultaat is: als we de debugmodus in Google Tag Manager gebruiken, kunnen we onze sessie nog steeds zien in de DebugView van Google Analytics. Ongeacht of we ons op intern gedefinieerde IP-adressen bevinden of niet.

Laten we eerst een nieuwe variabele maken die zal worden gebruikt om traffic_type bij te houden wanneer we de ontwikkelaarsmodus niet gebruiken, door een variabele te maken die wordt gevuld met {{undefined}}.

Vervolgens moeten we onze opzoektabel variabele dat ons beslissingsblok zal zijn over welke waarde we naar onze traffic_type variabele moeten sturen. Het is belangrijk om onze {{Undefined}} variabele, omdat dit niet hetzelfde is als deze staat gewoon leeg laten.

Nu we de opzoektabelvariabele hebben gemaakt, hoeven we deze alleen nog maar te gebruiken als de waarde voor onze traffic_type parameter op de configuratietag van je Google Analytics 4 in Google Tag Manager. Stel deze in zoals in de onderstaande schermafbeelding.

Het resultaat is dat Google Analytics 4 je verkeer in de ontwikkelaarsmodus niet langer als intern ziet (bijvoorbeeld wanneer je de voorbeeldmodus van GTM gebruikt).

Stap 3. Test de debugmodus en pas uw filters toe

We zullen hier niet veel tijd besteden aan testen, omdat we deze stap snel gedeeltelijk zullen omzeilen door door te gaan naar de laatste stap. Als je zeker wilt weten dat alles werkt zoals verwacht, kun je het volgende doen: als je op een intern IP-adres bent en GTM in de voorbeeldmodus gebruikt, moet je nog steeds de debug-weergave van GA kunnen gebruiken en moeten er events doorkomen.

Werkt alles? Laten we verder gaan met de laatste stap: en waarschijnlijk de meest interessante stap voor wanneer uw werknemers onderweg toegang hebben tot uw website.

3. Hoe filter je verkeer van specifieke ingelogde gebruikers (bijv. beheerders)?

Deze laatste stap is soms net zo belangrijk, zo niet belangrijker, dan het eerste deel. Een combinatie van beide is bijzonder krachtig. Hoe relevant deze stap voor jou is, hangt af van hoe je werkt. Bekijk je de website mobiel als je onderweg bent? Heb je een IP-adres dat vaak verandert? Werken je werknemers op afstand? Als het antwoord ja is, is dit laatste onderdeel handig, zo niet cruciaal voor jou!

Helaas hebben we op dit moment nog geen geavanceerde filtering in Google Analytics 4. Tot die tijd is de methode die ik hieronder beschrijf de beste manier om ingelogde gebruikers uit te sluiten van je Google Analytics 4-gegevens. Tot die tijd is de methode die ik hieronder beschrijf de beste manier om ingelogde gebruikers uit te sluiten van je Google Analytics 4-gegevens. Voor dit onderdeel heb je ook Google Tag Manager nodig, je kunt er niet omheen, tenzij je zelf aan de slag wilt met vrij complexe codering op je website. Of je nu klaar bent om je handen vuil te maken of niet, blijf lezen want we zullen de strategie achter onze GTM setup uitleggen.

Stap 1. Gebruik een identificatiecode voor uw ingelogde gebruikers

In deze tutorial gebruiken we een geweldige plugin voor het implementeren van Google Tag Manager op je website. Het heet Google Tag Manager voor WordPress door Thomas Geiger. Hiermee kunnen we snel en eenvoudig een identifier implementeren in de Data Layer. Als je deze plugin niet gebruikt, zul je een andere manier moeten vinden om een identifier in je Data Layer te pushen wanneer een gebruiker (of alleen bepaalde gebruikers) zijn ingelogd. De strategie die we volgen is, dat als we detecteren dat iemand de website bezoekt in een beheerdersrol, we de gegevens uitsluiten van Google Analytics. Dit betekent dat je niet langer beperkt bent tot intern gedefinieerd IP-verkeer.

Het enige voorbehoud - als u een beheerder bent maar niet bent ingelogd op de website op het apparaat waarop u surft, worden uw gegevens nog steeds doorgestuurd naar Google Analytics als u zich niet op het interne netwerk bevindt. De sleutel hier is om werknemers bewust te maken en hen te vragen om in te loggen op uw website voordat ze deze bezoeken.

Hieronder zie je de configuratie die we hebben ingesteld in de Google Tag Manager voor WordPress plugin om onze gebruikers te identificeren.

Onze gegevenslaag bevat nu de ingelogde status (niet gebruikt in deze tutorial) en de gebruikersrol als de gebruiker is ingelogd. We hebben deze laatste identifier gebruikt om te zien of een “administrator” gebruiker is ingelogd.

Je kunt eenvoudig controleren welke gebruikersrol GTM4WP verzendt door de voorbeeldmodus in GTM te gebruiken en op het tabblad Gegevenslaag te klikken. “Beheerder” in ons geval.

Stap 2. Maak twee extra opzoektabellen in GTM om het verkeerstype naar Google Analytics te sturen

Nu we onze identifier kennen, is het tijd om 2 extra opzoektabelvariabelen te maken. We willen het werk dat we in het tweede deel van deze tutorial hebben gedaan niet kwijtraken, dus hebben we het volgende nodig:

• Een opzoektabel om debugverkeer te identificeren (gedaan in deel 2)
• Een opzoektabel om beheerders te identificeren
• Een opzoektabel om debugverkeer voorwaardelijk toe te staan, ongeacht de gebruiker en als er geen debugmodus actief is, om te controleren of er een beheerder is aangemeld.

Maak de laatste twee opzoektabellen volgens de onderstaande twee schermafbeeldingen.

Maak daarna de uiteindelijke opzoektabelvariabele.

De laatste instelling die overblijft, is het veranderen van de manier waarop we de verkeerstype op de GA4 configuratietag. Ga terug naar je configuratietag en verander verkeerstype om de nieuwe opzoektabelvariabele weer te geven.

Dat zou het moeten zijn! Als je goed hebt opgelet (vooral op de spelling van de naam van je gebruikersrol, hoofdlettergebruik is belangrijk!) zou je klaar moeten zijn.

Stap 3. Test in debugmodus om te controleren of het verkeer correct wordt geïdentificeerd

Om er zeker van te zijn dat alle instellingen correct zijn, moeten we een aantal tests uitvoeren. Als u Chrome gebruikt, kunt u het beste de Google Analytics Debugger om al je testgegevens naar de Debug-weergave te pushen. Je kunt ook de ingebouwde netwerkinspectietool van je browser gebruiken. ctrl+shift+i in Chrome, Firefox of Edge en blader vervolgens naar “Netwerk”.

Herlaad je website en filter op “analytics.google”. Je zou een entry moeten zien die het verkeerstype onder de header tab als “tt” weergeeft (zie hieronder).

Als je tests eindigen met dezelfde verkeerstypen als verwacht (zie onderstaande lijst), ben je klaar om je nieuwe GTM-container te publiceren!

1. Intern IP, uitgelogd, maakt geen gebruik van GTM Preview-modus: wordt weergegeven als intern verkeer
2. Intern IP, uitgelogd, met GTM Preview-modus: wordt weergegeven als ontwikkelaarsverkeer
3. Intern IP, ingelogd, maakt geen gebruik van GTM Previewmodus: wordt weergegeven als intern verkeer
4. Intern IP, ingelogd, met GTM Preview-modus: wordt weergegeven als ontwikkelaarsverkeer
5. Extern IP, uitgelogd, maakt geen gebruik van GTM Preview-modus: verkeerstype is niet ingesteld, en dus niet gefilterd
6. Extern IP, uitgelogd, met GTM Preview-modus: wordt weergegeven als ontwikkelaarsverkeer
7. Extern IP, ingelogd, maakt geen gebruik van GTM Previewmodus: wordt weergegeven als intern verkeer
8. Extern IP, ingelogd, met GTM Preview-modus: wordt weergegeven als ontwikkelaarsverkeer

4. Conclusie

Dat is het! Je hebt nu een schone lei om te beginnen met het verzamelen van Google Analytics-gegevens. Het lijkt misschien ingewikkeld, maar ik verzeker je dat het gedoe de moeite waard is. Hieronder een overzicht van de voordelen.

• Nauwkeurige betrokkenheidsmeting
• Conversies bijhouden
• Nauwkeurige analyse van de verkooptrechter
• Nauwkeurige identificatie van verbeteringsgebieden
• Effectief A/B-testen
• Enz.

Kortom, alle belangrijke gegevens zijn veel nauwkeuriger en je bent klaar om je bedrijf te laten groeien!

Vind je het leuk wat je net hebt gelezen? Misschien was deze blog niet helemaal van toepassing op jouw probleem en heb je hulp van ons nodig? Neem contact met ons op en we kijken graag hoe we je verder kunnen helpen!