GA4 "Unassigned" en "(not set)" verkeer na de overstap naar server-side

Een week na de overstap naar server-side tagging opent iemand het rapport Verkeersacquisitie en vindt bovenaan een nieuw kanaal: Unassigned. Ernaast: sessies met als bron (not set). De overstap krijgt de schuld, en soms terecht. Vaker is de oorzaak een van vijf dingen, waarvan vier niets te maken hebben met waar je container draait. Zo houd je ze uit elkaar.

Wat de twee labels betekenen

Unassigned is een kanaalgroep. GA4 kent de bron en het medium van de sessie, maar geen van beide past op de regels van een standaardkanaal: utm_medium=newsletter, utm_medium=banner of utm_source=chatgpt.com zonder medium komen hier allemaal terecht. (not set) is anders: GA4 kent de waarde helemaal niet. Voor de sessiebron betekent het dat GA4 het event dat de sessie opent nooit zag, en dus niets heeft om de rest aan toe te schrijven.

Wacht eerst vier dagen

GA4 schrijft sessies in fasen toe en verwerkt de meest recente dagen opnieuw. In een rapport dat gisteren eindigt, is een deel van de laatste dagen nog Unassigned en verhuist later naar het juiste kanaal. Op de properties die wij controleren zit bijna elke Unassigned-sessie in de laatste vier dagen. Precies daarom leest de Measurebase-audit kanaalrapporten met een venster dat vier dagen geleden eindigt. Zet, voordat je iets gaat debuggen, de periode zo dat hij vier dagen geleden eindigt en kijk opnieuw. Krimpt Unassigned tot een paar procent, dan heb je geen probleem.

Oorzaak 1 · Je eigen UTM-waarden

De standaardkanaalregels herkennen alleen een vaste lijst mediums: cpc, ppc, paid, email, social, referral, affiliate, display, video en nog een paar. Al het andere is Unassigned, hoe logisch het er in de campagnebouwer ook uitzag. Bekijk de dimensie Sessiebron / medium onder de rij Unassigned: zie je je eigen mediums, hernoem ze dan in toekomstige links of voeg een aangepaste kanaalgroep toe die ze koppelt. Server-side tagging raakt UTM-waarden niet aan, dus deze oorzaak is ouder dan de overstap.

Oorzaak 2 · Twee trackingpaden voor één bezoeker

Deze is wél de schuld van de overstap. Sturen sommige GA4-tags naar je servercontainer en andere nog rechtstreeks naar Google, of staat de oude Tag Manager-snippet nog naast de nieuwe op de pagina, dan is de sessie van een bezoeker over twee paden verdeeld. GA4 kan via het ene pad een aankoop ontvangen voor een sessie waarvan de eerste paginaweergave via het andere binnenkwam, met andere cookies of client-ID's, en de aankoop belandt in een sessie die het nooit zag beginnen: bron (not set), kanaal Unassigned. Hetzelfde gebeurt als een adblocker de browserhit tegenhoudt terwijl een server-side kopie van het event wel aankomt.

Oplossing: elke Google-tag in de webcontainer krijgt dezelfde server_container_url, de oude snippet gaat weg, en het Enhanced script brengt de paginaweergaven langs blockers zodat het eerste event van een sessie via hetzelfde pad binnenkomt als de rest. De audit meldt het aandeel Google-hits dat je servercontainer passeert en welke tag ze stuurt; de gids over hits die je servercontainer passeren loopt de oplossing door.

Oorzaak 3 · Server-to-server events zonder sessie

Een aankoop die vanuit de backend van je shop, een webhook of het Measurement Protocol wordt gestuurd, komt zonder de context van de browser binnen. Draagt hij niet de client_id, de huidige session_id en een engagement-vlag van de bezoeker, dan kan GA4 hem niet in de sessie plaatsen waar de bezoeker echt was, en verschijnt hij met bron (not set). Aankopen zijn de events waar mensen het meest naar kijken, dus een handvol hiervan valt op.

Oplossing: door de server gestuurde events moeten de identifiers van de browsersessie hergebruiken. Onze Shopify-app doet dit voor de orderdoorgifte: ze voegt de identiteit van de browser samen met de server-side aankoop voordat die vertrekt, zodat de aankoop bij de sessie hoort die hem opleverde. Sla voor je eigen server-to-server events client_id en session_id bij de bestelling op en stuur ze mee.

Oorzaak 4 · De referrer kwam nooit aan

De sessiebron van een ongelabeld bezoek komt van de referrer. Drie dingen laten die verdwijnen: een Referrer-Policy van no-referrer op de verwijzende site of je eigen site, in-app-browsers die hem strippen, en single-page apps die hun paginaweergaven pas sturen nadat de router de URL al heeft gewijzigd, zodat page_referrer je eigen site is. Een transformatie in de servercontainer die page_referrer of page_location doet hetzelfde. Een ontbrekende referrer wordt meestal Direct, maar een referrer die naar je eigen domein wijst wordt een zelfverwijzing of, samen met een verloren sessiestart, (not set).

Oplossing: houd page_location en page_referrer op elk event (de Measurebase-import stript ze nooit), zet je eigen domeinen op de lijst met ongewenste verwijzingen in de GA4-gegevensstream, en stuur in een single-page app de paginaweergave voordat de route wijzigt of geef de vorige URL zelf door als page_referrer zelf door.

Oorzaak 5 · Toestemming

Met Consent Mode sturen bezoekers die weigeren cookieloze pings. GA4 vult de gaten alleen met gedragsmodellering als de property de drempels haalt; tot die tijd ontbreken die sessies in plaats van Unassigned te zijn, maar sessies die over een toestemmingskeuze heen lopen kunnen hun begin kwijtraken. Een bezoeker die landt, weigert, rondkijkt en dan op de checkoutpagina accepteert, begint halverwege een nieuwe identiteit: de aankoop heeft een sessie, de sessie heeft geen bron. De toestemmingstrend in je Measurebase-domeinstatistieken laat zien hoeveel hits binnenkomen met granted, denied of zonder toestemmingsstatus, en dus hoeveel van je verkeer in deze grijze zone leeft. De gids over Consent Mode v2 server-side behandelt de opzet.

Zo ontdek je welke jij hebt

1. Verkeersacquisitie, periode eindigend vier dagen geleden, primaire dimensie Standaardkanaalgroep van sessie. Noteer het aandeel Unassigned.
2. Voeg Sessiebron / medium toe als secundaire dimensie. Je eigen mediumnamen betekenen oorzaak 1.
3. Schakel over naar Sessiebron en zoek naar (not set). Open dan een verkenning met eventnaam tegenover sessiebron: is (not set) vooral aankopen of leadevents, verdenk dan oorzaak 2 en 3; is het over alle events verspreid, verdenk dan 2 of 5.
4. Open in Measurebase de requestlogs van het domein tijdens een testbezoek: de paginaweergave en de aankoop horen allebei bij je servercontainer binnen te komen, met hetzelfde client-ID, via één pad. De bevindingen van de audit over omzeilen en dubbel meten vertellen het je als dat niet zo is.
5. Vergelijk het aandeel Unassigned voor de weken vóór en na je overstapdatum. Een sprong op die datum wijst naar oorzaak 2; een vlakke lijn zegt dat de overstap onschuldig is.

Wat Measurebase voor je controleert

De nachtelijke tracking-audit meldt Google-hits die je servercontainer passeren, een tweede container of oude snippet op de pagina, tags die zonder de gedeelde server-URL sturen en events die vóór toestemming afgaan. Met de GA4-property gekoppeld leest hij de kanaalrapporten van de property met het venster van vier dagen en vergelijkt hij de hits die hij zag met wat GA4 vastlegde, waarbij alleen toegestane, menselijke, geslaagde hits tellen, omdat GA4 niets toont voor geweigerde pings. De requestlogs tonen elk event met zijn toestemmingsstatus, dus een gesplitst pad of een ontbrekende sessiestart is per bezoek zichtbaar.

Veelgestelde vragen

Herstelt het historische Unassigned-verkeer zichzelf?

Alleen de meest recente dagen worden opnieuw verwerkt. Oudere sessies houden de toewijzing die ze kregen; de oorzaak oplossen verandert wat je vanaf nu ziet.

Is Unassigned hetzelfde als Direct?

Nee. Direct betekent dat GA4 helemaal geen bron zag en aannam dat de bezoeker het adres intypte. Unassigned betekent dat het een bron en medium zag die geen enkele kanaalregel accepteert.

Veroorzaakt server-side tagging op zichzelf Unassigned-verkeer?

Nee. Als elke Google-hit via één pad gaat en door de server gestuurde events de identifiers van de browser dragen, ziet GA4 precies wat het eerder zag, vanaf een ander adres. De problemen komen van twee paden tegelijk, of van events sturen waar de browser nooit van wist.