Uitleg – [Opgelost] Unassigned traffic en not set source/medium in GA4 na server-side implementatie

Unassigned & not set verkeer in GA4 kan een verwarrend probleem zijn voor veel website/webshop-eigenaren en marketeers. Het is belangrijk om te begrijpen waarom dit gebeurt en hoe je dit aan kan pakken, zodat je (weer) kan werken met nauwkeurige gegevens.

In dit artikel onderzoeken we de oorzaken van unassigned en not set verkeer en bieden we je praktische oplossingen. Aan het eind weet je hoe je ervoor kunt zorgen dat je verkeer de juiste attributie heeft. Not set helemaal laten verdwijnen gaat helaas niet lukken, daarvoor dient Google nog wat aanpassingen door te voeren. Maar het minimaliseren is wel iets wat we kunnen doen.

Snel naar

Wat is (het verschil tussen) unassigned en not set verkeer?

Unassigned en not set verkeer vind je terug in Google Analytics rapporten, met name in de rapporten verkeersaquisitie en gebruikersaquitistie.

“Unassigned traffic” verwijst naar sessies en gebeurtenissen (events) die niet kunnen worden toegewezen aan een default channel group in GA4. “Not set” vind je daarentegen terug onder source/medium.

Unassigned traffic GA4 oplossen

GA4 bepaalt de source van de sessies aan de hand van de aanwezigheid van UTM-parameters in de URL aan het begin van de gebruikerssessie. Als deze er niet zijn, wordt de referrer gecheckt om de source van het verkeer naar de website te bepalen. Mocht de referrer parameter ook leeg zijn, dan wordt het verkeer gecategoriseerd als “Direct” traffic. Een grote toename van direct traffic kan betekenen dat er iets misgaat met de UTM parameters in de URL’s of met de referrer parameters.

Verkeerd gebruik van de UTM parameters

Als je gebruik maakt van UTM parameters in de URL’s, zorg er dan voor dat je niet zomaar iets zelfbedachts gebruikt. Voor de utm_source en de utm_medium dien je namelijk gebruik te maken van de standaardwaarden zoals GA4 die heeft gedefinieerd. Meer daarover kun je hier vinden.

Voorbeeld van die standaardwaarden zal je vast herkennen, denk aan:

Direct: Bezoekers komen via een opgeslagen link of hebben de website-URL ingevuld.
Organic search: Bezoekers op je site of app terecht via klikken op links in organische zoekresultaten.
Paid Social: Bezoekers komen via advertenties die op social media staan, zoals Meta of LinkedIn.

Als je niet genoeg hebt aan de standaardwaarden bij source en medium of simpelweg graag meer onderscheid wil maken, dien je de custom channel groups in GA4 toe te voegen, zodat GA4 snapt wat er gaande is.

Dit doe je als volgt:

Zorg dat GA4 open staat.
Ga naar Admin, vervolgens klik je Channel groups open.
Druk op het menu dat op de regel van de “Default Channel Group” staat. Klik op Copy to create new. Dit zal wat tijd besparen met het opzetten van je custom channel group.
Geef binnen het Create new channel group scherm een logische groepsnaam.
Klik op Create channel en voeg een logische naam en channel conditions toe. Klik vervolgens op opslaan. Zorg dat de channel conditions matchen met de naamgeving in je UTM parameters.
Druk op opslaan.
Om de oplossing te valideren, kun je de UTM parameters achter een url simuleren. Zet ook het GA4 realtime rapport open en monitor de parameters source en medium. Bezoek vervolgens de URL incl. UTM parameters en kijk of deze juist registreert wordt door GA4.

Krijg je het unassigned verkeer niet verminderd? Lees dan verder, want ook je not set waardes kunnen ermee te maken hebben. Not set verkeer wordt namelijk opgenomen de “Unassigned default channel group”.

Not set source/medium oplossen

De not set volledig laten verdwijnen zal niet lukken, maar we kunnen er wel alles aan doen om het zo min mogelijk te maken. We wachten allemaal nog op verbeteringen van Google om bepaalde zaken te veranderen, maar helaas moeten we op dit moment de verwachtingen aanscherpen.

Uitleg visual verhouding not set source/medium

Zie je veel not set waardes terug bij source/medium? Probeer dan de volgende oplossingen:

Zorg dat de Google tag (gtag) trigger op “Initialization – all pages” staat (web container)

Door ervoor te zorgen dat de Google Tag op “Initialization – all pages” staat, wordt deze eerder afgevuurd dan andere GA4 gebeurtenissen/event tags in de container. Daardoor kan GA4 de events daarna vervolgens netjes plaatsen en linken aan de juiste source/medium.

Waar het om gaat is dat er geen enkele GA4 event tag dient af te vuren voordat de Google tag configuratie tag op de pagina is afgevuurd. De volgorde hiervan kun je in de preview van je web container terug zien.

Een of meerdere GA4 gebeurtenissen/event tags vuren eerder af dan de google tag (web container)

Deze oplossing lijkt veel op de oplossing van hierboven, maar gaat iets verder dan alleen de trigger van de configuratie tag. Want hoewel die goed kan staan, zou het ook kunnen dat de configuratie erna nog een keer wordt afgevuurd door een andere trigger, zoals de consent update trigger.

Zie je een GA4 event eerder afgevuurd worden dan de GA4 configuratie? Zorg er dan voor dat het event later wordt afgevuurd. Zo kun je bijvoorbeeld werken met trigger groups binnen GTM. Dit is situatie afhankelijk, maar om toch even een voorbeeld te geven:

Stel het “view_item_list” event wordt eerder afgevuurd dan de Google tag, omdat de Google tag pas afgevuurd wordt op de consent update. Hierdoor kan het event zorgen voor een not set bij source/medium, want die parameters zijn (nog) niet meegekomen via de Google tag. Je zou dan een trigger group aan kunnen maken die je aan het event hangt. In die trigger group hang je dan zowel de trigger voor het view_item_list event als de trigger voor die consent_update. Op die manier moeten beide triggers afgevuurd zijn om het event af te vuren.

We raden je aan nauwkeurig naar de volgorde van de events en afgevuurde tags te kijken in de voorbeeldmodus van Google Tag Manager om bovenstaande oplossing toe te passen en te testen.

Ontbrekende session_start gebeurtenis/event

Het kan zijn dat je soms een session_start event mist. De gebeurtenis session_start is belangrijk, want de GA4 dimensies (bijvoorbeeld session source/medium) die de bron van het verkeer weergeven halen deze waarden uit dit event. Het zou kunnen dat je een setup hebt ingesteld waarbij dit event is uitgesloten. Zorg ervoor dat deze wel meegenomen worden naar GA4 vanuit je server-side container. Dit kun je controleren door het event te zien terug te komen previewmodus in je webcontainer, waarna je ook checkt of je het in de previewmodus van sGTM ziet terugkomen. Of je opent de debugview in GA4, waar je een session_start dient terug te zien.

De google tag (gtag) wordt op meerdere plekken geïnitialiseerd

Het kan voorkomen dat sommige GA4 events van de server-side GTM container (sGTM) komen, terwijl anderen direct naar Google Analytics worden gestuurd. Als het goed is initialiseer je in GTM netjes de gtag met een server_container_url parameter. Het kan echter zijn dat deze instelling overschreven word, omdat er ergens anders in de websitecode, in een plugin of met een integratie nog een Google tag wordt geïnitialiseerd.

Indien de verbinding tussen de GTM en sGTM container niet altijd hetzelfde is, kunnen er not set waardes ontstaan. De server-side tracking setup (sGTM) maakt namelijk gebruik van een “FPID” cookie, terwijl de client–side tracking (web GTM) gebruik maakt van de “_ga” cookie. Bij verschillende gtag’s kan GA4 ze echter niet meer altijd linken aan elkaar, omdat hij verschillende gebruikers kan zien, terwijl het eigenlijk dezelfde gebruiker is.

Hoe controleer je of dit aan de hand is?

Ga naar je website waarop het probleem zich voordoet.
Open de inspecteer tool in je browser (rechtermuisknop > inspect).
Ga naar het network tabblad en vink preserve log aan.
Zoek je measurement ID in GA4 op (die vind je terug onder admin > data streams). Voer de ID in de zoekbalk bij het network tab in.
Controleer bij iedere regel onder het kopje Headers de parameter request URL. Check of de verzoeken netjes naar de URL van je server container gaan en niet naar google-analytics.com.

Gaan er een (of meerdere) URLs naar Google analytics in plaats van je server container URL? Dan zit er waarschijnlijk ergens in je website of app nog een extra gtag script. Zorg ervoor dat deze uit de code gehaald worden. Dit kan bijvoorbeeld door bepaalde integraties of plugins te deactiveren, indien ze op die manier in je code komen, of door het door een developer te laten verwijderen.

Voorbeeld van een gtag code (zo zien ze er meestal om en nabij uit):

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=TAG_ID"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() { dataLayer.push(arguments); }
  gtag('js', new Date());
  gtag('config', 'JE MEASUREMENT ID');
</script>

Het zou perfect zijn als je slechts een enkele GA4 configuratie tag in je GTM container gebruikt.
Pas de “Additional consent checks” aan indien je Google consent mode V2 gebruikt (web container)

Deze oplossing is alleen van toepassing als je ook Google consent mode v2 gebruikt in je web container. Controleer in GTM of de Google tags de specifieke instelling “No additional consent required” hebben. Deze hebben, door ingebouwde consent checks, namelijk ook geen extra consent nodig. Dit kan de not set source/medium binnen GTM verminderen.

Let wel op: Dit geldt alleen voor tags met built-in consent checks. Laat alle andere niet Google tags hetzelfde.

Het Measurement protocol is niet correct geïmplementeerd

Indien je het measurement protocol gebruikt om events naar GA4 te sturen, controleer dan of de client_ID en de session_ID in het juiste format worden verzonden, evenals het uitlezen van de juiste cookies om die waardes op te halen. Als een event/gebeurtenis via het MP naar het verleden wordt gestuurd (tot 72 uur), controleer dan of de parameter timestamp_micros is opgenomen en de juiste waarde bevat.

De parameter session_id moet een waarde bevatten van een sessie die al is gevolgd door GA4 aan de client-side. Als de session_id die binnen measurement-protocol gebruikt wordt niet overeenkomt met de session_id die al bij GA4 bekend is, wordt de source/medium not set.

Hoe kom je aan de correcte client_id en session_id voor het measurement protocol (mp)?

“FPID” cookie wordt gebruikt voor server-side tracking om vast te stellen wat de client_id is.

Een voorbeeld van zo’n FPID User ID cookie is als volgt:

"FPID2.4.pde01hlXAv0WDRteUjaaNZ5L98OPiuDV80n24P%2BV04%3G.12P6854201"

Je hebt voor het measurement protocol (MP) echter alleen het deel na de tweede punt (FPID2.4.) nodig. Een voorbeeld van een FPID user ID cookie voor MP gebruik:

"pde01hlXAv0WDRteUjaaNZ5L98OPiuDV80n24P%2BV04%3G.12P6854201"

De “_ga” cookie wordt gebruikt om de session_id vast te stellen. Achter de “_ga” vind je je Measurement ID terug. Een voorbeeld van een sessie cookie:

"GS1.1.1717672462.3.1.1253857282.0.0.233767386"

Je hebt alleen het deel achter de tweede punt (GS1.1.) nodig tot aan de punt die erna volgt (.3.1.1253857282.0.0.233767386). Voorbeeld van het format voor MP gebruik:

"1717672462"

Vervolgstappen

Wat kan je doen na het volgen van alle stappen?

Vergeet niet dat het soms tot 48 uur kan duren voordat je GA4 data weer goed staat. Er zit namelijk een vertraging van 24 tot 48 uur op de dataverwerking in GA4. Wachten loont hier dus.
Het kan zijn dat je net na livegang even een korte piek ziet in not set source/medium. Dit heeft te maken met caching van de code op apparaten van bezoekers, waardoor ook de trackingcode tijdelijk verouderd kan zijn. En er zijn sessies die al gestart zijn en die hebben dan ook al een session_id gekregen, waardoor GA4 de sessies tijdelijk niet juist kan toewijzen. Ook hier loont wachten soms dus.

FAQ

Als een verzoek/request naar region1.analytics.google.com gaat, gaat het dan ook direct naar GA4?
Ja, het gaat dan niet naar je server_container_url. Kijk of je ergens meerdere gtags initialiseert.
Kan ik de setting “Javascript Managed” in de client gebruiken?
Als je in de client instellingen van de Google Analytics 4 in sGTM de “Cookies and client identification” op “Javascript Managed” zet, lijkt het opgelost. Helaas verlies je dan echter wat kracht van server-side tracking, waarbij je gebruik maakt van cookies die een langere levensduur hebben (Server Managed). Met Javascript Managed zullen je cookies minder lang geldig zijn, wat de betrouwbaarheid van je data omlaag haalt. Al je events zouden naar je server container moeten gaan.

Bronnen

Analytics Mania heeft een zeer uitgebreide blog geschreven over allerlei not set problemen in GA4:
[Solved] How to remove not set in Google Analytics 4?
Optimize Smart heeft een uitgebreide blog over Unassigned traffic:
What is unassigned traffic in GA4 and how to fix it – Optimize Smart

Verhoog de effectiviteit van jouw campagnesBekijk Savvy Track