If you are seeing very large user counts on the session default channel report in GA4 in the last few days, you are not alone.  And it’s not only in the last few days that this has been an issue; it's a problem that has consistently affected the three days previous to the current day since around May 20, 2022.

"Unassigned" is the label that Google applies when there are no other channel rules that match the event data.  This is different from "(other)", which is used as an aggregated row due to cardinality limits. 

As of the writing of this blog post, the bug has affected GA4 reports under Acquisition, in the Traffic Acquisition Report, as well as the New Users chart on the User Acquisition report.

The bug results in the count for the “Unassigned” default channel grouping to be much higher than it actually is for the most recent 2-3 days.  After this, the numbers return to normal.

In our research, this bug is currently only affecting GA 360 accounts.  This bug has been reported and reportedly Google is working on a solution.

This issue can be seen in the reports area of the GA4 user interface, but it also impacts the Google Data Studio Connector:

And is seen when doing queries with the Google Analytics 4 Data API.  This means that any connectors in Data Studio, homemade scripts, or other third party tools that use this API, also show the incorrect data.

This bug does not affect the daily BigQuery export table content, so any reports based on BigQuery SQL Queries on this table will not show additional sessions.

The BigQuery export is an export of the raw event data, and seems unaffected by this bug.  The issue with the data appears to be happening when the data is being put into the reporting tables used by GA4.  The reason that the other three locations (GA4 Web UI,  Data Studio Connector and the Data API) are affected is because all three connect to these reporting tables. 

This is also why, when you have high cardinality dimensions and exceed the reporting row limits, all three locations are affected by the “(other)” problem that can make the basically unusable.

We hope that Google will resolve this issue quickly- however even if they do, the fundamental limitations of the web Reports, Data Studio connector, and Data API should convince you that taking advantage of the BigQuery Export is the long term best path forward for your data access.

In the web, if you're using Reports, there isn't much you can do other than to constrain your window to remove the past few days where the bug occurs.  

You can use the Explorer as it does not show the issue, but recreating Reports in Explorer is not easy. And while you can get the data if you can create the right configuration, you won't get the charts that are shown in the Reports section. 

If you're using the Data API, it is essential that you perform an incremental load on your data with a window of at least 4 days.  This way you will update the older data as it is reprocessed.  Those who are simply loading the last 1 day and appending it to their historic data tables are going to compound the problem and end-up with an unusable data set. 

If you're using Analytics Canvas Online, by default your refresh window is 5 days.  This means that Canvas will first remove the last 5 days of data from the table before loading them back in.  While the data in days T-1 to T-3 will still be incorrect, data from T-4 and T-5 will be corrected.  This not only addresses the immediate bug, but also accounts for data reprocessing that may occur in this window.