Solution: As mentioned, the fix is very simple, go to Admin > Data display > Channel groups and add the uncategorised source, medium or campaign rules in the correct channel

GA4 Config Tag Firing Issues

After making sure your custom channel settings are correct, the second possible cause is the firing order of your GA4 config tag. If traffic source values are missing when a session starts, that visit could be grouped into "Unassigned". We observed three scenarios:

1)       There are event tags firing before GA4 config tag fires. Sometimes these events are not triggered from Google Tag Manager, they are fired from a third-party platform such as an A/B testing tool.

2)       Measurement protocol or similar technologies send event data to GA4 without having all of the fields such as traffic source, session ID or client ID, in all of the hits.

3)       The GA4 config tag does not fire on time and other events fired before Config tag fired.

To investigate GA4 Config firing issue, you can observe the events firing order in the network requests on each page. Double check the tracking ID is correct. 

You can also order the events in a session in BigQuery to observe the events order for each session. I wrote a very simple query here for you to view this table in BigQuery. You can use the output to investigate the event orders GA4 received for each session: 

SELECT

  TIMESTAMP_MICROS(event_timestamp) AS timestamp,

  CONCAT(user_pseudo_id, '/', (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id')) AS session_id, 

  event_name,

  collected_traffic_source.manual_source AS hit_source,

  collected_traffic_source.manual_medium AS hit_medium,

  collected_traffic_source.manual_campaign_name AS hit_campaign_name,

  collected_traffic_source.gclid AS hit_gclid,

  session_traffic_source_last_click.manual_campaign.source AS session_source,

  session_traffic_source_last_click.manual_campaign.medium AS session_medium,

  session_traffic_source_last_click.manual_campaign.campaign_name AS session_manual_campaign,

  ROW_NUMBER() OVER (PARTITION BY user_pseudo_id, (SELECT value.int_value FROM UNNEST(event_params) WHERE key = 'ga_session_id') ORDER BY event_timestamp) AS event_order

 FROM `YOUR_DATA_SET.events_*`

 WHERE _TABLE_SUFFIX BETWEEN '20240717' AND '20240817'

Your output would look something like this: 

Solutions:

1.       In your Google Tag Manager container, make sure the GA4 Configuration tag fires before any other tags on every page.

2.       Depending on your set up, you may need to implement tag sequencing to prevent misfires if necessary.

3.       You can choose to fire a page_view event within GA4 config tag, or using dataLayer to trigger page_view event separately. Either way you need to test and make sure the page_view event should fire after the GA4 config tag is able to fire successfully.

4.       Review any events that are sent outside of GTM and make sure these do not get sent before your GA4 config tag and page_view event.

5.       If you are using measurement protocol, make sure client ID and session ID are passed on correctly to preserve the same session context. If these sessions are designed to be separate from web sessions, make sure a custom dimension is implemented so that you can exclude these sessions easily in GA4.

Consent Status Updates Too Slowly

A less obvious but impactful cause stems from Consent Mode settings. If consent updates are delayed, GA4 may not receive the updated consent status in time for a very short session. This delay can result in unassigned traffic because GA4 treats these sessions as unconsented and therefore may not assign a traffic source properly.

Solution:

If you’re using Google Tag Manager with the Consent Mode template, ensure you configure ‘Wait for Update’ setting in the default tag. This ensures that tags wait for the updated consent status before firing, reducing the likelihood of unassigned traffic caused by sessions being classified as unconsented.

If you are hardcoding consent defaults on your site, you can use the wait_for_update field to set a delay in milliseconds. This allows sufficient time for the consent status to be updated before tags execute. Here's an example of how to implement this using gtag:

gtag('consent', 'default', {

 'ad_storage': 'denied',

 'ad_user_data': 'denied',

 'ad_personalization': 'denied',

 'analytics_storage': 'denied' ,

 'wait_for_update': 1000

});

Multiple Google Tags Are Implemented on the Same Page

When multiple GA4 config tags are implemented on the same page, and both config tags has ‘send_page_view’ set to ‘true’, the second config tag won’t fire its 'page_view' event, which leads to ‘Unassigned’ traffic.

Similarly, if server side tracking is set up to forward event hits from GA4 client, an extra GA4 config tag outside of the server side set up will cause ‘Unassigned’ traffic too.

If you cannot find the unwanted config tag in GTM, check if it is possible that a gtag is being hardcoded on the website.

Solutions:

1.       Review the setup to identify any duplicated GA4 config tags. Remove the unwanted tag either from GTM or from the website, to ensure only the intended GA4 config tag is triggered. 

2.       If you intend to set up multiple GA4 config tags to send data to different data streams, on client side GTM, you should fire a standalone page view tag that references the correct GA4 config tag. You can set up tag sequencing to make sure GA4 config tags always fire before any other events fire for each set of GA4 tracking.

3.       If you intend to send data to different data streams, and you have server side tracking set up. In server side GTM container, you can set up the measurement ID look up for each event tag to reference, but make sure there are no extra hardcoded gtags on the website.

Bonus tip:

If you are not sure whether you have an unwanted GA4 config tag firing, you can pass on the intended tag’s tag name as one of the custom dimensions and then check the network requests. All of the enhanced measurement events triggered by the config tag should contain this custom dimension from the intended tag. If such events do not contain this custom dimension, it indicates another GA4 config tag is triggering these events.

Here is an example of how you can set this up:

If server side tracking is set up, check the ‘Headers’ of the network request and make sure there is no duplicated events sending requests to both your own server side domain and the Google domain.

Using BigQuery to Process Unassigned Traffic

Even with a clean implementation, GA4’s automated processing can sometimes misclassify traffic, leaving it in the Unassigned category. BigQuery provides an advanced solution to correct these misclassifications and fine-tune your channel groupings.

In BigQuery, you can access source/medium and other traffic source fields at different levels:

Hit Level: all fields under the collected_traffic_source - collected only when a hit presents these values.

Session Level: all fields under session_traffic_source_last_click.manual_campaign - backfilled for all hits within the same session when a set of last click traffic source values are available for a hit.

Cross-Channel Level: all fields under session_traffic_source_last_click.cross_channel_campaign – similar to the ‘manual campaign’ fields. Only available from mid-October 2024, corrected some of the mis-attributed medium values in the ‘manual campaign’ fields. Therefore more reliable to use.

To ensure no traffic source data is overlooked:

1. Cross-Check All Levels: Compare values across hit, session, and cross-channel levels to identify inconsistencies or unbucketed traffic.
2. Custom Rules: Write subqueries to bucket traffic based on your custom logic. This allows you to reassign unclassified traffic to the correct channels, overriding potential errors from GA4’s processing.

By implementing this advanced processing in BigQuery, you can improve the accuracy of your channel groupings, minimizing the Unassigned category and gaining deeper insights into your traffic sources.

One thing to notice here, however, is that unconsented traffic does not contain traffic source information in BigQuery. But in GA4 UI, if you are using 'blended' reporting identity, GA4 models the traffic allocation, therefore the data in GA4 UI and the data you processed in BigQuery become incomparable.

Conclusion

While some unassigned traffic is unavoidable, its volume can be significantly reduced by addressing the common causes we’ve outlined and implementing advanced fixes using BigQuery. By tackling these issues, you can ensure more accurate attribution and deeper insights into your traffic sources.

Don’t let Unassigned traffic skew your data—take action today to refine your implementation and elevate your data analysis with the powerful tools at your disposal. As always, Hookflash is here if you need a hand!