Een tijdje geleden heeft Google het landingspagina rapport weer toegevoegd aan GA4. Als je het al hebt gebruikt, heb je misschien iets raars opgemerkt..
Er is een (not set) dimensie in dit rapport.
De waarde (not set) kan ervoor zorgen dat je niet begrijpt waar jouw gebruikers vandaan komen. Het is niet altijd even duidelijk waardoor het probleem wordt veroorzaakt, maar laten we eens kijken naar de meest voorkomende.
De mogelijke oorzaken van (not set) landingspagina’s in GA4
Over het algemeen betekent (not set) dat het eerste event van de sessie geen paginaweergave was of dat je een sessie hebt met alleen gebeurtenissen en geen paginaweergaven.
Dit kun je verifiëren met behulp van de Explorations. Maak een segment met sessiebereik waarbij Landingspagina = (not set) en ga naar Users Explorer en controleer de sessies.
Maar hoe kan dit überhaupt gebeuren?
Er zijn meerdere scenario’s waarin dit kan gebeuren. Laten we ze eens bekijken, te beginnen met de meest voorkomende oorzaak, sessietime-outs.
Sessietime-out en (not set) landingpagina’s
Stel dat je een artikel op een website leest. Misschien Google je ondertussen wat, zet je een kop koffie of laat je je op een andere manier afleiden. Zodra je 30 minuten bereikt, verloopt jouw sessie.
Op dezelfde manier kan een gebruiker de site tegen middernacht bezoeken. Als de klok voorbij 00:00 uur tikt, is de sessie voorbij.
Als je vervolgens weer interactie hebt met het artikel door naar een andere pagina te scrollen of te klikken, wordt een “nieuwe” sessie gestart. En dat klikken of scrollen is dan de eerste gebeurtenis van de sessie.
Een andere oorzaak is een onjuiste instelling van tags, wat ertoe leidt dat events worden geactiveerd vóór gtm.js.
Onjuist geactiveerde events en (not set) landingspagina’s
Als een gebruiker bijvoorbeeld interactie heeft met de pagina voordat hij cookies accepteert, en vervolgens accepteert, wat leidt tot de eerste paginaweergave. Dan wordt er een andere (not set) landingspagina geregistreerd. je kunt de voorbeeldmodus gebruiken en de volgorde van de laadevents van de pagina controleren om te bepalen of dit het geval is.Code-implementatiefouten
De oude code op de pagina kan conflicteren met jouw nieuwe GTM-code, of als je een app hebt, kan de eigenschap die je in GA4 gebruikt zowel de app-gegevens als webgegevens bevatten. je kunt dit verifiëren door een secundaire dimensie van hostnaam aan jouw rapporten toe te voegen.
Hoe verminder je het aantal (not set) landingpagina’s?
- Verleng de sessietime-out als dit zinvol is voor jouw website. (Je kunt dit verlengen tot 7 uur en 55 minuten)
- Als je GA4 via GTM hebt ingesteld, zorg er dan voor dat er niets wordt geactiveerd vóór de gtm.js-gebeurtenis. Ik heb veel gevallen gehoord waarin een onjuist geïmplementeerde cookietoestemmingsbanner de boosdoener was. Controleer dat dus zeker.
- Maak jouw eigen rapport of verkenning van bestemmingspagina’s met de dimensie ‘landingpage + querystring’. Dit geeft je misschien wat meer inzicht dan het standaard rapport.
- Voor de meest analytische flexibiliteit kunt je deze opnieuw maken in BigQuery met behulp van een goed artikel van Johan van de Werken
De conclusie
Dat is het. Hopelijk is dit nuttig om jouw landingpage rapporten te verbeteren. Als je meer wilt weten over andere methoden voor datahygiëne, bekijk dan zeker ook enkele van onze andere artikelen. Veel succes!
