If you noticed a sudden spike in direct or unassigned traffic between May 22nd and the end of June, you’re not alone. This issue has been discussed in GA4 Facebook groups as well as in the Google community.
While I don’t have an official source for this, I believe Google made changes to how they process GA4 data.
The good news is, the fix is typically quite simple.
Config is not the first tag on the page
Sometimes, other events, like view_item_list or view_item, are triggered before the page_view tag.
And, interestingly enough, you might have the GA4 config as the first tag, but event tags might still fire faster than the config. For example, if you have something like this:
gtag('config', ...)
gtag('view_item_list', ...)
In the Chrome network tab, you’ll see that view_item_list fires first.
In the Chrome network tab, you’ll see that view_item_list fires first.
You can try disabling these tags to test if they are causing the issue. Later, you could ask your developer to delay the tag slightly, perhaps by using a setTimeout function.
I’ve also encountered cases where an element visibility trigger fires before the GA4 tag.
This isn’t a new problem. Google has always recommended ensuring that nothing fires before the config tag fully loads, as mentioned in the article Tagging Best Practices to Avoid Unassigned, (not set), and Direct Traffic Issues. This issue is more prominent if you’re using Server-Side GTM.
User ID on the website
Another issue is often related to the user ID. If your reporting identity is set to “Blended” and the user ID is established during the visit, the conversion will be attributed to the “(not set)” source. You’ll need to switch to “Device-based” reporting identity or remove the user ID.
GA3 script still on the website
If you auto-migrated the GA3 script to GA4, this may also be causing the problem.
If you’ve tried these solutions and are still experiencing the issue, feel free to contact us.
