Waar komen die (not set) landingspagina's in GA4 vandaan?

Google heeft het landingspaginarapport teruggebracht in GA4, en als je het openslaat valt meteen iets op: een flinke berg (not set).

In de kern betekent die waarde dat het eerste event van de sessie geen pageview was. Of dat er een sessie is met alleen events en helemaal geen pageviews.

Je controleert dat in Explorations: maak een segment op sessieniveau met landingspagina = (not set), ga naar de Users Explorer en bekijk die sessies stuk voor stuk.

Stel je leest een artikel. Je zoekt ondertussen iets op, zet koffie, wordt afgeleid. Na 30 minuten inactiviteit verloopt je sessie. Hetzelfde gebeurt als de klok middernacht passeert.

Ga je daarna weer scrollen of klikken, dan start er een nieuwe sessie. En dat scrollen of klikken is dan het eerste event. Geen pageview dus, en dus (not set).

De tweede oorzaak is volgorde. Vuurt er een event vóór gtm.js, dan mist GA4 de pageview als startpunt van de sessie.

Een verkeerd geïmplementeerde cookiebanner is hierbij veruit de grootste boosdoener. Die vuurt vaak een event voordat de container geladen is.

Ook oude code op de pagina kan botsen met je GTM-implementatie. En heb je een app, dan kan dezelfde property zowel app- als webdata bevatten. Voeg hostnaam als secundaire dimensie toe aan je rapport om dat uit te sluiten.

• Verleng de sessietime-out als dat past bij je site. Je kunt tot 7 uur en 55 minuten.
• Draai je GA4 via GTM, zorg dan dat er niets afvuurt vóór het gtm.js-event. Begin bij je consentbanner.
• Bouw je eigen landingspaginarapport met de dimensie landingpage + query string. Dat geeft vaak meer inzicht dan het standaardrapport.
• Wil je alle analytische vrijheid, bouw het dan opnieuw op in BigQuery.