You create a custom exploration and add your important metrics and dimensions, then you run your report.
The orange triangle at the top of the page hits you as you scroll down the report. Your data has been thresholded; some rows are missing, so your total user count does not equal the number of users in the rows below.
This is a huge annoyance to data analysts and marketers using Google Analytics to report on specific campaigns.
Google Analytics 4 is built around a privacy-centric model.
When user counts drop below a certain minimum number of users for a particular report or segment, the system automatically thresholds the data. This prevents anyone from being able to break out user-level behavior of individuals based on granular signals.
This is not an error; it is built into the system.
While understanding how thresholding works might help you figure out how to fix it, it does not provide you the immediate answer you need for your business.
You want to see your data and be able to identify what campaigns generated those ten conversions last week, regardless of how low the volume of users was.
The following diagnostic process will help you bypass the user interface limitations imposed by your report thresholding.
It will protect the accuracy of your reporting, and maintain the integrity of your critical business insight, without being negatively impacted by a system-wide privacy filtration.
Quick diagnostic process
Before you make any changes to your core administrative settings, teams need to follow the diagnostic process to identify why your report is hiding the rows.
Avoid jumping directly to the commonly used workarounds, which may break your attribution model or render your Google Ads remarketing lists unusable.
1. Determine your report setup
Identify the exact dimensions that you are querying. Are you querying information related to age, gender, and user interests?
Data that is being aggregated is also being reduced to a narrow segment of users, creating a higher density which will trigger thresholds based on the total user count for the date range specified in your current query.
An example would be a three-day date range that has a lot of users within your query parameters will trigger the filter, while the same query with a 30-day date range will not trigger it.
To identify if you are using the wrong Identity in your Report, navigate to the Admin Panel. More than likely the Property in your account is set to Blended or Observed.
The various ways in which a blended or observed identity is created means that the more identifiers that are used, the higher the chances of obscuring data in low traffic queries.
Understanding the thresholding process for GA4 data
Stop viewing the thresholding issue as an indicator code.
The thresholding system was developed by Google as a Privacy Safeguard.
There is no single mathematical threshold listed by Google for triggering the filter. However, it is generally accepted within the industry that the threshold sits somewhere between 30-50 users across all segments of either type of report or groups of dimensions.
Privacy tradeoffs
Upon the introduction of GA4 and subsequent integration with Google Signals/Multi-Device Identity Spaces, a clear theme emerged regarding the need for Google to ensure compliance with national and international Privacy Laws.
This forces Google to have very strict rules on the extent to which users may cross-reference dimensions (Example: City, Type of Device, Age Group) to identify that a visitor is one and the same.
As a result, if the cross-section of data becomes too small, the reporting user interface will not capture that row of data for reporting.
The metric count that is displayed in the column header still reflects the correct value, but its individual parts are hidden.
When do thresholds apply?
You will receive this type of warning for most low-traffic reports.
If you have a high-traffic site and you only view top-level channel groupings over a 90-day timeframe, the orange triangle will not usually appear.
However, the orange triangle will appear if you're analysing a micro-conversion on a low-traffic niche landing page over a 7-day timeframe.
What is the 2024 Identity update you might have missed?
Early in 2024, there was a dramatic change to how Google Analytics views identity.
This caused many tutorials from previous years to become out-of-date.
How Google signals changed
In the past, the solution for thresholding issues was to disable Google Signals.
For many, Google Signals were an integral part of how Google Analytics would de-duplicate users in reports. If Signals were enabled, then thresholding was almost always present in reports that had a limited amount of data.
This is no longer true.
In early 2024, Google changed the way that Google Analytics would calculate users' identities and how users were de-duplicated in standard reports or Custom Reports.
However, Google Signals are still used for the demographic reporting and audience-building features of Google Ads. Out-of-date tutorials will continue to suggest that you disable Signals.
Disabling Google Signals will not guarantee a fix for your standard traffic acquisition reports, but it will break the ability to retarget those users.
How to fix Google Analytics 4 data thresholding: Step-by-step guide
There is no way to shut off the privacy filters with just a click. After that, make any of the other listed changes.
Step 1: Change reporting identity from blended to device-based
The #1 UI-level Fix for Missing Data.
The most effective UI-level fix for missing data in GA4 is to use a Device-Based reporting identity.
GA4 uses a Blended reporting identity by default, which is a mixture of User ID, Google Signals, Device ID, and other methods of data model creation.
Because Blended reporting uses highly sensitive user stitching methods, this triggers the privacy filter on GA4, causing much of the data that would normally be available for display to be filtered out of the reports.
By changing from a Blended reporting identity to a Device-Based reporting identity, you remove the advanced user-stitching entirely.
The Device-Based reporting identity is generated only by using the client ID from a user's cookie.
Because you no longer have sensitive user stitching data being used, Google's privacy filter is greatly reduced, exposing virtually all previously hidden rows of data to you instantly.
To do this, go into Admin – Data Display – Reporting Identity – Device-Based.
If you do not see the Device-Based option immediately, click "Show All" in the lower right-hand corner. Select Device-Based and save it.
This change is non-destructive, meaning it does not affect the data you have already collected. You can switch between the two reporting identities as many times as you want.
Step 2: Increase your analysis period
Sometimes, to be able to continue attributing cross-device, you need to continue to have the Blended identity enabled.
If you cannot change to the Device-Based reporting identity, your next step is to continue to increase the volume of data in your query.
You can do this by expanding your date range.
If you had a date range of 7 days, change it to 28 days. If your date range was originally 30 days, change it to 90 days.
When you expand the date range, when there are enough users in your specific micro-segment, the count of users will ultimately exceed the hidden minimum (which is approximately 50 users).
Once the segment clears the hurdle, the row reappears.
This is the least technically invasive workaround for teams that just need a general directional read on performance.
Step 3: Evaluate demographic and user dimensions
Certain dimensions carry a higher privacy risk than others. Age, Gender, Interests and sometime granular Search Queries are heavily guarded.
If your Custom Exploration includes an Age dimension but your core objective is simply to see which landing pages drove the most form fills, you are artificially triggering the threshold.
Duplicate the Exploration and strip out the demographic dimensions. Run the report again.
The data will usually populate immediately.
Only include sensitive user-level dimensions when they are the primary focus of the analysis.
Step 4: Rely on BigQuery export for raw data
Stop fighting the user interface.
If your business relies on precise, down-to-the-row accuracy for low-volume events, the GA4 user interface will eventually fail you. Use BigQuery to circumvent the limitations of GA4.
When you link Google Analytics 4 to BigQuery, Google exports the raw, un-aggregated event data directly into your data warehouse.
There are no UI-level thresholds imposed by BigQuery.
When three users trigger a very specific custom event from a very specific source, then BigQuery provides three rows of data.
One limitation of BigQuery is that it does not receive Google Signals data. You will not receive the age or gender data in the raw export.
For pure performance marketing, lead generation and precise event counting, BigQuery delivers the complete data set for this information that is not available through the normal UI.
Understanding typical report types and edge cases
The situation is very contextual.
The manner in which data is hidden will vary based on the different surfaces within the platform you are using to perform your query.
Standard reports vs. custom explorations
Standard reports (for example, Traffic Acquisition or Events) will work off of pre-aggregated tables. If you have a good amount of traffic on your site, they will generally be more resilient to Thresholding.
Custom Explorations are unique in that they will be processed at the time of the execution of your query.
You are creating unique combinations of dimensions and metrics for your report, and therefore, the Explorations will be much more affected by the Privacy Filter.
Additionally, the Explorations will respect your retention settings (in most cases, this will be capped at 14 months).
It is common for analysts to confuse retention limits with thresholding.
Therefore, if you see data that is older than 14 months disappear from a Custom Exploration but still shows in a Standard Report, then you are experiencing a retention limitation rather than a threshold limitation.
Small volume B2B sites
A very small B2B SaaS site that receives approximately 200 visitors per day will typically be in a constant state of thresholding.
For those sites, the Blended reporting identity will be contrary to the daily analysis of all reports. This means that any Custom Report created will likely come heavily redacted.
As such, it would be best for B2B teams to utilize Device-Based Reporting Identity for all day-to-day tactical reporting and only use Blended models for quarterly Attribution Reviews.
Understanding the dilemma of E-commerce attribution
The greatest challenge facing e-commerce teams is the need for accurate tracking across devices to establish how mobile browsing leads to desktop purchases.
This requires a blended identity.
However, e-commerce also needs immediate and accurate reporting on long-tail product SKUs that may sell only a few times a week.
Long-tail SKU reports will be inaccurate if you view that report via a blended identity.
E-commerce must establish a dual workflow.
They use the User Interface for broad trend analysis and Looker Studio dashboards or other Omni Analytics alternatives connected directly to BigQuery for accurate SKU level transactional reporting.
Final evaluations: Don’t fight the user interface
Data thresholding will always be part of modern web analytics.
Therefore, the days of completely transparent, and consequently, accurate user-level tracking in native web interfaces is a thing of the past.
Don’t try to permanently disable the privacy features, as this tends to create broken ad linkages and deteriorate attribution.
Use a flexible workflow; toggle your reporting identity when you need to see tactical low-volume row data. Remove any unnecessary demographic dimensions from your custom explorations.
If your organization requires absolute precision then you would need to transition your primary reporting completely out of the GA4 interface.
Instead, point your Business Intelligence (BI) tools to BigQuery instead. The GA4 interface serves as a trend analysis tool; BigQuery serves as the actual database; treat them accordingly.
Commonly asked questions
Is it possible to fix historical data from Google Signals by disabling Google Signals?
No, only data collected from the time the change is made onward.
The data from previous date ranges would not be altered or disclosed based on their thresholding processes and as of the 2024 update disabling Google Signals will not serve as the main fix for standard reporting issues.
Does changing the reporting identity have a permanent effect on my data?
No, the Reporting Identity is simply a display setting.
You could be switching between Blended, Observed and Device-Based numerous times a day without affecting the manner in which your data is being collected, stored or processed in the background.
Do events exported to BigQuery from GA4 are completely free of thresholding?
Yes, the BigQuery export provides raw event-level data without the use of the UI privacy filters.
However, Google excludes any sensitive proprietary data from these exports entirely; therefore, Google Signals-derived demographic or interest categories will not be available in BigQuery and will not trigger thresholding.
Can I manually lower the threshold limit in GA4?
No, the mathematical limits that will generate obfuscated data are strictly system-defined by Google.
Administrators cannot modify the sensitivity of the threshold filter, they can only mitigate the effects of the threshold filter by changing the dimensions they query or the identity model applied to the view.