Hi everyone
After enabling server-side tracking with Stape almost 50% of my traffic comes from “Unassigned”. I tried everything. Can you please help me figure it out? I feel like I tried everything at this point
Hi everyone
After enabling server-side tracking with Stape almost 50% of my traffic comes from “Unassigned”. I tried everything. Can you please help me figure it out? I feel like I tried everything at this point
Hello,
Here’s a good article on assigned traffic: [Solved] How to Fix Unassigned in Google Analytics 4 (2023)
If the problem showed-up after you switched to s2s - you need to look into faults with configuration, a lot of times there are leftovers (inline for example) or a conflicting config that makes some events go directly to analytics omitting the server container - I would look if that’s the case.
Best of luck,
Dan
Hi Dan
I noticed that changing the GA4 Client’s Cookies and Client Identification from Server Managed to JavaScript Managed worked with the Unassigned Traffic - but why is that? I have a custom DNS called ss.mywebsite.com.
Also, what is the difference between having only “Default GA4 paths” checked and this one, with everything checked?
The last one seems to give me more data, but also more Unassighed Traffic.
So in short… what is the best setup for the GA4 Client in Server-Side GTM?
I wouldn’t recommend using these features unless you know what it’s for.
With Unassigned traffic you may be helped by using JS managed cookies, but you lose some of the point of going to server side + it indicates that the reason for the unassigned traffic is due to problems in your tags setup. For example, this can often be the case if you have an event that fires before the configuration and thus goes through the analytics instead of the server container.
I would recommend to run a preview of your containers and check that all events always go through the server container.
Hi @tue,
I have been having the same problem since my ss setup. What I’ve discovered so far is that it’s due to an event firing before session_start event. GA4 fetches important information like source, medium, campaign etc. when session_start event is triggered. However, if any event (usually user_engagement) fires before that, GA4 directly puts that session’s source/medium as (not set). So please make sure that no event is sent to GA4 before the Google Tag on GTM fires successfully.
On the client side… with stape and custom loader … only click on the first point (ga4 standard paths) or do we need the other points too?
Hi @Ihsan_Mercan,
Is there any known way to make sGTM wait for session_start to fire user_engagement?
Hi @Manuel-D,
Not that I know, unfortunately.
For anyone coming here like me and struggling with Unassigned Traffic – I tried another SST service and the Unassigned problem stopped immediately. Setup was 1:1.
This seems to be a problem with Stape and at least certain configurations. In this case, WP + Cookiebot in manual blocking mode.
All installations were identical: Stape, Web and competitor x. Only Stape produced the Unassigned traffic, which consisted from cross-network (not present in GA4 getting data from Stape but present in others installations) and extra traffic (1/3 of assigned traffic).
Hope this helps both Stape addressing the issue and fellow users not to spend hours troubleshooting issue that is not on their end.
Unassigned traffic is a typical problem with implementation issues. You can find quite a few articles and videos on this topic on the Internet.
We also have a good one: Unassigned and not set traffic source in GA4 - Stape
When GA4 works in server-side format, it works as a proxy, the request is not changed in any way on the server, but simply redirected further to GA (unless you have configured some data changes in the tag on the server or, for example, enabled Anonimyzer power-up). So even in theory this problem has nothing to do with what server you use for hosting sGTM.
I can bet that you switched the Server managed cookies setting in GA4 client to JS managed cookies and that solved your problem. It solved the problem, but you also gave up some of the advantage of using server side tracking.
And as soon as you switch it back to the default server managed - your problem will come back because it’s an implementation problem (some of the tags you have in some cases work directly because of which it uses _ga cookie instead of FPID as client id in GA4).