Unassigned and Broken Traffic and Session Reports in GA4 - Troubleshooting

Google Analytics 4 (GA4) as we know it today was originally known as “Firebase Analytics”, an app SDK-based tracking system that reliably stored data on a user's device. However, when GA4 was introduced (or Firebase Analytics rebranded into a digital analytics powerhouse, replacing the most commonly used web analytics system: Universal Analytics) to the web, it began to rely on cookies and local storage, which are less resilient and have reduced functionality due to privacy and tracking prevention measures, as well as ad blockers. This shift has created new challenges, particularly with data consistency.

The data model behind GA4, based on Firebase Analytics, remains the same, but the data collected from web interactions is less consistent. This inconsistency can lead to reporting issues, such as incorrect channel attribution (e.g., "unassigned" channel) or missing landing page data.

In this article we will help you identify this issue on a technical level. Later we will look into ideas and solutions to overcome those with your JENTIS Server-Side tag manager configuration.

Identifying Issues with your GA4 Configuration

To troubleshoot session issues in GA4, especially with a server-side configuration, follow these steps:

1. Check for Channel Consistency - Define a Way Forward

In GA4 the Acquisition Reports are a good starting point to identify if and what level of an issue is present. While it is common that 0-10% of your sessions reported might have “unassigned” as a channel value, this number must be assessed in light of your website and according management. From our experience it is a regular scenario to have at least a small degree (<10%) of sessions with “unassigned” channel, regardless of client- or server-side GA4 implementations. So the first step must be to define a threshold for your management to which degree an unidentified traffic (“unassigned”) can be acknowledged as expected “noise” in web traffic data and at what moment you see the foundation of your informed decision making harmed.

2. Dig deeper into possible GA4 Session Issues

Other than the most prevalent “unassigned” traffic other issues might also become visible that relate to the same root cause. The following issues we’ve seen reported frequently:

• landing page is “(not set)” when session can not be correctly assigned with a user and his events tracked

• GA4 reports many users with only one event in total of his journey (without ever making a session_start), which looks odd and disrupts metrics like average time on site and engagement

• bounce rate (or engagement rate on the other side) looks to be “off”

3. Get a clear picture of the issue - User Explorer Mode

Now that you know the issue quite well you can make a last step to see individual occurrances of session attribution issues. Navigate to the exploration mode of reports with GA4 and create a segment for users that describes the “problematic” sessions, ie. “sessions where channel contains unassigned” or “~ landingpage contains not set”.

With this segment of broken data artifacts you can identify individual users with the “User Explorer” method in the exploration mode of GA4. Inspecting this individual users journeys on your website will help you point the finger on the exact root cause. For example you might identify, that for this segment the users appear often with a certain event as the first in the session, but the “session_start” event is not making any appearance. Where you’d expect that the session starting event indication should be among the first events with GA4. While also the best practice is that page_view and/or the session_start are the leading events with each users session. Clicks and user_engagement events must occur after these both events have been identified.

Technical background - if you want to know how GA4 determines if an event is flagged as the “session start” look for these parameters in the network protocol parameters:

_ss if it equals 1 it indicates a session_start with that event stream (this is when you will see a session_start in the pageview event). To note: every first page_view of a session should be flagged _ss=1.

_ss if it equals 0 (which is the default), the pageview event won´t initiate any session_start, which could lead to discrepancies in GA4 data if not applied correctly.

Any subsequent event in a session should equal to 0, otherwise every single event/action would seem like a new session is started. All in all, to be able to confirm a true session_start for a pageview event, you need to make sure _ss equals 1. If _ss equals 0, no session_start is initiated.

With this fundamental investigations done you possibly now know better if and what issue you might be facing in your GA4. So let’s continue with possible resolutions to individual configuration issues.

Resolving Configuration and Data Processing Issues with GA4 Server-Side

In JENTIS you have two different methods to integrate GA4: client- and server-side. While on the client the Google Tag (GTAG) will execute with a user on the device and you’ll have only control over configuration parameters with GA4. The session and event tracking handling will be executed based on the gtag.js source code - which neither JENTIS nor you can strictly (technically) control. In this client-side scenario you must look for resolutions with Google directly, or possibly do detailed developer work with your individual website frontend design and implementations.

On the other hand, the server-side integration with JENTIS gives you have full control over each data point to be tracked. Here we have some guides prepared to help you implement GA4 in a consistent way that would improve your reporting when it comes to session related troubles.

1. Essential Mode Activated with GA4

JENTIS offers a privacy and data enhancing Essential Mode (fallback configuration that balances out privacy requirements with eligible analytics and intelligence insights); when this is configured with your JENTIS GA4 server-side setup then please make sure to check this guide for a detailed investigation: GA4 Essential Mode Configuration Issues and Troubleshooting

2. Order of GA4 events and tags

As already mentioned during the assessment of session-issues in GA4 you must know that GA4 requires a certain sequence of events to be tracked with a user to create meaningful reports. The general assumption and best practice is that page_view is generally the first event of a session. While session_start is reported in GA4 as an individual event, it is not actively tracked as such. Instead, each event can flag session_start=true as a parameter. This behavior can be challenging and create the mentioned inconsistencies with reports.

When analyzing the user-explorer method (see above) you might find that certain events trigger before a page_view, ie. a scroll or click event. In such cases you must look into your GA4 server-side tags and identify if those events might trigger too early. And apply according changes to make sure the page_view is always the first in line of the event sequence.

When it comes to this sequencing of events also make sure to check if there might be situations where a user only tracks an event, such as a click, but never a page_view. Which will also create inconsistent sessions with GA4.

3. Cross-Container and -Domain Tracking

In scenarios where you have multiple JENTIS Containers implemented and configured or your website visitors journey stretches across multiple domains or website-sections the session handling can become challenging. Let’s unwrap both topics.

In some cases it is beneficial to have either multiple GA4 instances on your website and JENTIS configuration, or you might have multiple containers to give structure to your implementation. Even though they are implemented technically on one domain.

When multiple GA4 instances are installed you must watch out that a session started in one instance should not mean that in the other instance it is amiss. All GA4 instances must indicate for their entity a start of a session. By default multiple GA4 configurations will not share their server-side storage. In that case you are safe, as the server-side computation of the “session start”-flag will happen for each tool correctly. However, if you select that two GA4 instances must share their storage (as it can be customized in a tools advanced settings) you might want to inspect for situations where a user might flag a session start in one instance but not in the other. Same is to be tested and analyzed in light of two JENTIS containers implemented, when a user switches from one container to another, the session should remain consistent (same as the client-id value for a user). As also when a client-id changes the session must follow and accordingly restart for a new client.

In cases of cross domain tracking you must watch out again for the “session start”-flag but this time in situations where a user navigates between domains. And possibly activates with different sessions in one or multiple GA4 instances.

Both scenarios are highly individual topics for a configuration and can not be further analyzed at this point. Please reach out to our helpdesk or your account manager contact, in case you need further assistance.

4. Foreign Data Streams

Another idea to investigate with your configuration might be to see if data possibly is ingested into your GA4 property that is not coming from JENTIS servers. Possibly in a case where the same GA4 measurement-ID is shared with a website that might be a blind spot. So even while your JENTIS configuration is all correctly set up you might see strange data because the origin of that data is from a source that was overlooked.

A simple way to identify this situation is by implementing a custom event property (custom dimension) that indicates it was submitted with JENTIS servers. Simply add this custom event property to all your tags and give it a static value “jentis” by the dimension name “source”. After publishing this change analyze your data and see if all 100% of events will report this value, or if maybe some blind spot was identified.

Conclusion

Troubleshooting GA4 session issues, especially with a server-side configuration, requires a systematic approach. By identifying data consistency issues, inspecting channel attribution, auditing server-side configuration, and reviewing privacy and tracking prevention measures, you can pinpoint the root causes of session problems. Implementing optimized data collection methods, enhancing server-side configuration, and using fallback mechanisms can help resolve these issues and improve the accuracy of your GA4 reporting.