Four mechanisms silently remove or alter data before you see it. Three publish exact thresholds. The one that hides the most publishes no number at all.
Four separate mechanisms change what you see before you see it. Three of them publish exact numbers. The fourth, the one that silently removes entire rows from your reports, publishes none at all and cannot be turned off.
None of this is hidden. It is all documented, on pages most people never open because the report looked fine.
This page collects the thresholds in one place, says which are adjustable, and explains what each one does to a B2B account specifically.
Thresholding: the one with no number
The mechanism that removes the most data is the only one without a published figure.
What it does, verbatim. Data thresholds are applied to prevent anyone viewing a report or exploration from inferring the identity or sensitive information of individual users based on demographics, interests, or other signals present in the data.
Whether you can change it. No. The documentation states that data thresholds are system defined and that you cannot adjust them.
When it fires. When a report or exploration includes demographic data, or audiences defined by demographics, or a search term dimension with too few users.
How you know. A data quality icon appears, stating that thresholding has been applied to one or more cards and that data will only display when it meets the minimum aggregation thresholds.
The threshold itself. Not published. The documentation refers to minimum aggregation thresholds and to having enough total users, and never gives a number.
Why that matters more in B2B than anywhere else. B2B audiences are small. A campaign reaching 400 people in a narrow industry is exactly the shape of data this mechanism suppresses, so the accounts most likely to lose rows are the ones least able to spare them.
The practical workaround. Widen the date range, remove demographic dimensions from the report, and avoid demographic audiences in any report you need complete. You are not defeating the threshold; you are staying above it.
Cardinality and the (other) row
The second mechanism aggregates rather than removes, which is harder to notice.
The definition, verbatim. The number of values assigned to a dimension is its cardinality.
The guidance figure. Any dimension with more than 500 values should be considered a high-cardinality dimension, as it will significantly increase the cardinality of all the tables storing that dimension.
And the caveat the vendor attaches. The 500 values per dimension is not a limit, but a guidance.
What the (other) row is, verbatim. A row that appears in a report, exploration or API response when the number of rows in a table exceeds the table’s row limit. The product surfaces only the most common dimension values and condenses less common values under it.
Where this bites in practice. Page path on a content-heavy site. Any custom dimension carrying a session identifier, a query string, a product code or a user identifier. Campaign names, if your naming convention includes dates or unique identifiers.
The consequence people miss. The (other) row is not a small residual. On a high-cardinality dimension it can hold most of your traffic, and any percentage you calculate from the visible rows is computed against a denominator that excludes it.
The fix. Reduce cardinality at collection time. Strip query strings, group page paths, and never put a unique identifier in a dimension you intend to report on.
The one that removes rows entirely is the one with no published threshold, and it cannot be turned off. Source : Google Analytics help documentation (2026)
The most misunderstood setting in the product, because its scope is narrower than its name suggests.
The options. Two months or fourteen months on a standard property. Twenty-six, thirty-eight or fifty months on enterprise properties.
What it affects, verbatim. The data retention setting does not affect standard aggregated reports, including primary and secondary dimensions, even if you create comparisons in them. It only affects explorations and funnel reports.
Which explains a common experience. Standard reports go back years. The moment you build an exploration to answer a real question, the data stops fourteen months ago. Nothing is broken; that is the documented behaviour.
The clause that overrides your setting. A two-month retention period is always applied to age, gender and interest data, regardless of what you choose.
What to do about it today. Check the setting. If it is on the two-month default, change it to fourteen. Retention is not retroactive, so every month you leave it is a month you will not get back.
And the deeper implication for a B2B business. A B2B sales cycle frequently exceeds fourteen months. The product cannot show you an exploration spanning your own buying cycle, at any setting, on a standard property. That is a structural limit, not a configuration error.
Modelling: when the numbers are estimates
Two different modelling systems, two different thresholds, and they are frequently confused.
Behavioural modelling in analytics, the first condition. The property collects at least 1,000 events per day with analytics storage denied, for at least 7 days.
The second condition. The property has at least 1,000 daily users sending events with analytics storage granted, for at least 7 of the previous 28 days.
Where the estimated data appears. Only under the blended reporting identity. Most exploration templates include only data from users who consented, with two exceptions that do include estimated users.
What that means practically. Two colleagues can open the same property, look at the same period, and see different totals, because they have different reporting identities selected. This is not a bug and there is no warning.
Conversion modelling in the ads product, which is separate. It has its own threshold: a daily ad click threshold of 700 ad clicks over a 7 day period, per country and domain grouping.
And the consequence for reporting. Modelled conversions appear in the Conversions column and flow into every downstream report using that data. There is no separate column, so the reported figure is a mixture of observed and estimated events.
The reconciliation problem this creates. Your analytics property and your ads account model different things, at different thresholds, with different eligibility rules. They were never going to agree, and now you know one of the reasons why.
A change worth knowing about if any of your historical reporting predates it.
What was removed, verbatim. The first click, linear, time decay, and position-based attribution models are no longer available as of November 2023.
What remains in the analytics product. Data-driven, paid and organic last click, and paid channels last click.
What happened on the ads side. Conversion actions that used the deprecated models were upgraded to use data-driven attribution, and data-driven is now the default for most conversion actions.
Why this matters retrospectively. Any comparison spanning that date compares two different attribution regimes. If a channel’s contribution appears to have changed in late 2023, that may be the model change rather than the channel.
And prospectively. Data-driven attribution is a model, not an observation. It distributes credit according to a proprietary calculation you cannot inspect or reproduce.
The one thing you can still do. Note the model in use next to any channel comparison you publish. It is a single line, and it is the difference between a defensible chart and one that will be relitigated in six months.
Six checks, in order of how much they change what you are looking at.
Open your data retention setting. If it is on the two-month default, move it to fourteen. It is not retroactive, so every week you wait is lost.
Look for the data quality icon on your key reports. If thresholding is active, note which reports it affects and stop presenting those numbers as complete.
Find your (other) row. Sort your main dimensions by row count and see whether an (other) row exists and how much traffic sits in it. If it is material, the percentages beneath it are wrong.
Check your reporting identity. Note whether it is set to blended, and note that changing it changes your totals without changing anything about your website.
Strip identifiers out of your dimensions. Query strings, session IDs, anything unique. Cardinality is created at collection time and cannot be fixed later.
Write the attribution model on any channel chart you publish. One line. It ends the argument before it starts.
Thresholding removes rows to prevent identification, is system defined, cannot be adjusted, and publishes no numeric threshold at all.
It fires on demographics and low-user search terms, which makes small B2B audiences the most exposed.
Cardinality above 500 values is high, described by the vendor as guidance rather than a limit, and the excess is condensed into an (other) row.
That row can hold most of your traffic, which makes every percentage computed from the visible rows wrong.
Data retention affects explorations and funnels only, not standard reports, and age, gender and interest are always capped at two months.
Behavioural modelling needs 1,000 events a day denied for 7 days, and 1,000 daily users granted for 7 of 28, and shows only under blended identity.
Ads conversion modelling is separate, needs 700 clicks over 7 days per country and domain, and lands inside the Conversions column unlabelled.
Four attribution models vanished in November 2023: first click, linear, time decay and position based.
Fix your retention setting today, then go and find your (other) row. Book a diagnostic, or see how we approach B2B websites.
Frequently asked questions
Why does my report say data has been withheld?
Data thresholding. The vendor applies it to prevent anyone inferring the identity or sensitive information of individual users from demographics, interests or other signals. It is system defined and you cannot adjust it.
What is the thresholding limit?
No number is published. The documentation refers to minimum aggregation thresholds and to having enough total users, without ever stating a figure. That opacity is deliberate and documented as such.
What is the (other) row?
It appears when a table exceeds its row limit. The product surfaces the most common dimension values and condenses the less common ones into that row. Any dimension above 500 values is considered high cardinality.
Is 500 a hard limit?
No. The vendor states that 500 values per dimension is not a limit but guidance. The actual row limits vary by report and property type and are not published as a single figure.
Does the data retention setting affect my standard reports?
No. It affects only explorations and funnel reports. Standard aggregated reports are unaffected, which is why most people never notice the setting until they try to build an exploration.
Why can I never look at old demographic data?
Because a two-month retention period is always applied to age, gender and interest data regardless of what you set. That one is not adjustable.
When does the product model data?
Behavioural modelling requires at least 1,000 events a day with storage denied for at least 7 days, and at least 1,000 daily users with storage granted for 7 of the previous 28 days. The result appears only under the blended reporting identity.
Which attribution models disappeared?
First click, linear, time decay and position based, as of November 2023. What remains is data-driven, paid and organic last click, and paid channels last click.