Het komt veel vaker voor dan je denkt dat een gebruiker je website opent vanuit een app op zijn telefoon.
En het komt ook veel vaker voor dan je denkt dat dit verkeer wordt gerapporteerd als direct in Google Analytics.
Met andere woorden: het belandt in die zwarte doos die direct verkeer heet.
Afhankelijk van het project kan het om een aanzienlijk volume gaan, want we hebben het over zulke grote apps als:
- Gmail.
- De navigatiebalk van Android (let hierop, want die wordt vaak niet meegenomen).
- Sociale netwerken.
- Telegram en WhatsApp.
- Slack en vergelijkbare apps.
Als een belangrijk deel van je publiek uit een van deze kanalen komt, is wat ik je ga vertellen interessant voor je.
Waarom dit gebeurt
De reden dat deze gevallen als direct verkeer worden toegewezen, is: deze sessies hebben geen HTTP-referrer.
Los van de technische details gaat het in feite om gebruikers die niet van een andere webpagina komen, maar uit een app.
Met andere woorden: ze hebben in een app op hun telefoon op een link geklikt die hen naar je website heeft gebracht.
Bovendien bekijken ze je website meestal in de interne browser die vrijwel al deze apps ingebouwd hebben, niet in de eigen browser van de telefoon (Chrome, Safari, enz.).
Zoals gezegd komt dit gedrag vaker voor dan we denken, vooral als we via een van deze kanalen een groot publiek hebben (e-mail, Telegram, Instagram…).
Het is dus interessant om dit verkeer te bekijken en te kunnen analyseren.
Zo bekijk je webverkeer uit apps in GA4
Makkelijker dan je denkt. Het zijn maar drie stappen:
Stap 1: een leeg verkenningsrapport maken
Ga daarvoor in de linkerkolom naar “Verkennen” en selecteer “Leeg rapport”:
Stap 2: statistieken en dimensies toevoegen
We beginnen met het importeren van deze dimensies:
- Pagina-referrer-URL.
- Sessiebron/-medium.
- Landingspagina.
Vervolgens importeren we de volgende statistieken:
- Sessies.
- Totaal aantal gebruikers.
- Actieve gebruikers (optioneel).
In het veld “Rijen” plaatsen we de dimensie Pagina-referrer-URL.
In het veld “Waarden” plaatsen we de sessies, , totaal aantal gebruikers, of actieve gebruikers, afhankelijk van wat we willen analyseren.
Stap 3: het verkeer filteren dat ons interesseert
En nu komt de magie van de truc.
We filteren het verkeer waarvan de verwijzende URL “-app:” bevat, als volgt:
Resultaat
Hier is het:
Belangrijk: voor alle duidelijkheid, mocht ik dat eerder niet duidelijk genoeg hebben gezegd: dit verkeer is NIET van jouw app, maar van je website en komt via links in andere apps, oké?
Volgende stappen
Nu we al het verkeer hebben gevonden dat apps naar ons sturen, kunnen we wat dieper graven, en daar gaat het uiteindelijk om.
Nu je weet hoe je kunt filteren, pas je het rapport aan aan wat je echt nodig hebt. Ik stel twee uitbreidingen voor.
Sessiebron en -medium toevoegen
Het eerste wat je kunt doen is de dimensie aan het rapport toevoegen: Sessiebron en -medium:
Zo zie je dat een deel van het appverkeer niet direct is.
Hoe komt dat?
Omdat we het probleem hebben opgelost: we hebben de links getagd en de bijbehorende UTM-parameters toegevoegd. Verderop kom ik hierop terug.
De landingspagina toevoegen
Een andere dimensie die ik je aanraad aan het rapport toe te voegen is Landingspagina. Zo kom je nog wat meer te weten en krijg je meer context.
Laten we bijvoorbeeld dit bekijken:
Hier vertelt de “gm” aan het einde van de referrer-URL me dat de app Gmail is.
En de landing is de inlogpagina van mijn website.
Met deze informatie dacht ik eerst dat de link niet getagd was —wat, zoals ik hierboven zei, de manier is om dit te voorkomen—, maar dat is niet zo. De link in de e-mail IS getagd.
Waarom zet GA4 dit dan onder direct verkeer?
Vanwege een veelvoorkomend probleem: de URL van mijn website die ik in de link heb gezet (correct getagd), blijkt een redirect te hebben wanneer de gebruiker die opent.
Een redirect die ervoor zorgt dat de UTM-parameters verloren gaan waardoor GA4 de bron, het medium en de campagne niet correct kan toewijzen.
Het is mijn fout, niet die van GA4. Om dit op te lossen kan ik een van deze twee routes volgen:
- De link in de e-mail vervangen door de uiteindelijke URL waar de gebruiker na de redirect terechtkomt en die URL taggen. Het eenvoudigst, maar niet altijd mogelijk.
- De redirect zo instellen dat hij de UTM-parameters bewaart en toepast op de uiteindelijke pagina. Technisch iets ingewikkelder, maar het werkt altijd.
Dit probleem met redirects komt vaak voor. En het raakt zowel analytics als betaalde campagnes, bijvoorbeeld via de GCLID-parameter.
Uitzondering
Als je naar de afbeeldingen kijkt, is je misschien iets opgevallen: alle apps draaien op Android.
Ik begrijp de reden niet helemaal —ik vermoed dat het een eigenschap is van Safari in-app die Analytics blokkeert — maar met deze methode kun je alleen verkeer zien van het mobiele besturingssysteem van Google.
Gelukkig is het in Spanje veruit dominant, dus je hebt veel meer gegevens dan je mist.
Oplossing voor direct appverkeer: zo voorkom je het
Zoals ik al een paar keer heb genoemd, voorkom je dit door UTM-parameters te gebruiken. Daarvoor hoef je alleen de Google URL Builder te openen en de juiste parameters toe te voegen.
En dat is alles? Als ik dit altijd doe, krijg ik dan geen direct websiteverkeer uit apps meer?
Helaas moet ik je teleurstellen.
De reden is dat jij de links beheert die je zelf publiceert, maar niet de links die andere mensen delen. En hoe meer mensen je website delen, hoe beter, maar omdat zij niet naar de Google URL Builder gaan om die links te taggen, zul je ALTIJD direct verkeer uit apps houden.
Daarom is het belangrijk om te weten hoe je dit in de tool kunt bekijken.
Afsluiting
Dit is een vrij onbekende truc waarmee je diep in één segment van je verkeer kunt duiken en die vooral voor bepaalde projecten erg relevant kan zijn.
Nu kun je een verklaring vinden voor sommige verkeerspieken die je niet begreep. En je kunt ook nog een paar andere dingen oplossen, zoals redirects.
Allemaal heel eenvoudig, zoals de meeste GA4-trucs die ik tot nu toe heb gepubliceerd.
Als je van analytics en Google Analytics houdt, denk ik dat het de moeite waard is om ze eens te bekijken.
En als je problemen hebt met de analytics van je project en denkt dat je hulp nodig hebt, laten we praten.
Geef een reactie