Why GA4 and BigQuery User Counts Differ – Splinternet Marketing & SEO

GA4 and BigQuery can show different user counts because they may represent or calculate users differently. A mismatch alone does not prove that tracking or the export is broken. Before auditing tags, confirm you are comparing the same property and date range, the same user metric, and definitions that can reasonably be aligned.

This audit is for GA4 property owners and the marketers or developers responsible for reconciling its reports with BigQuery. Some Google Signals data and modeled data are not available in the BigQuery event export, so every difference cannot be resolved by choosing a different query or reporting identity.

Start with the property, dates, and metric

Record the GA4 property used for the report and the property whose data is exported to BigQuery. Then set the same date range for both figures. Write down the exact GA4 report and whether its metric is Total Users or Active Users. Google’s BigQuery comparison guide distinguishes these metrics; don’t treat them as interchangeable just because both are labeled as user counts.

Also write down what the BigQuery query counts. A count of distinct user_pseudo_id values, for example, is not automatically equivalent to a GA4 report’s user metric. The identifier and query definition determine what the BigQuery number represents.

Check GA4 reporting identity

In GA4, inspect the property’s reporting identity in Admin under Data display. Google’s Reporting identity guidance describes three options:

Device-based uses device ID only.
Observed uses User-ID and device ID.
Blended uses observed identifiers and can also use modeling.

User-ID is an identifier a site or app can provide to recognize a signed-in user across interactions. Device ID identifies activity associated with a device or browser. These options affect how users are represented in GA4 reports. Google says changing reporting identity does not change data collection or processing, and the setting can be changed without permanently changing the data.

Record the property’s current setting; don’t change it just to force the counts to match. A setting change can alter how reports represent users, but it does not rewrite the BigQuery export or guarantee matching totals.

Look for a thresholding notice in the report

Open the specific GA4 report you are comparing and inspect its data-quality indicator. If it shows that thresholding has been applied, record that notice: Google says thresholds can limit data shown in reports or explorations. Treat thresholding as a possible explanation only when the report actually indicates it. Its presence does not establish the cause of every difference with BigQuery.

Account for Google Signals and consent-related modeling

Google says Google Signals data is not exported to BigQuery. Its guidance on data thresholds notes that users or events per user can therefore differ between Analytics and BigQuery. Google’s documented illustration describes one person using three browsers: Google Signals may allow standard reporting to consolidate that activity, while BigQuery can retain three separate user_pseudo_id values.

That illustration shows a possible difference, not what will happen for every property or user. It also does not mean Google Signals identities can be reconstructed from the event export.

Consent-related modeling can create another limit to a direct comparison. Where GA4 uses behavioral modeling for people who decline Analytics identifiers, modeled data can inform reporting, but Google says that modeled data is not available in the BigQuery event export. The export therefore cannot be used to recreate those modeled users.

Use this like-for-like audit

Confirm the property: record the GA4 property and the corresponding BigQuery export.
Match the date range: use the same start and end dates in both comparisons.
Name the GA4 metric: record the report and whether it shows Total Users or Active Users.
Record reporting identity: note Device-based, Observed, or Blended.
Check report conditions: record any visible data-quality or thresholding notice. If none is shown, don’t attribute the difference to thresholding on that evidence.
Inspect the BigQuery definition: write down the user identifier being counted and the query’s definition of a user.
Consider the export limits: note whether Google Signals or consent-related modeling could affect the GA4 report but is unavailable in the event export.

Hypothetical example: A property owner compares a GA4 Blended report with a BigQuery count of distinct user_pseudo_id values. If the report includes modeled behavior or Google Signals consolidates activity across browsers, those figures may not represent users in the same way. The next step is to document the report, metric, identity, and query—not to change the reporting identity and assume the numbers should match.

Decide whether to investigate tracking

Call the comparison like-for-like only when the property, date range, user metric, and user definition are aligned closely enough for the comparison to mean what you intend. If they are not, document why the counts differ and what each number represents. A remaining mismatch alone still does not identify its cause; the property settings, consent implementation, selected report, and query may need separate inspection.

Investigate collection or export implementation when other evidence points to a problem there—not simply because two unlike user counts disagree. What exact GA4 metric and BigQuery identifier are you comparing?

Sources

Editorial note: AI assists with research, drafting and automated checks. Sources are linked so you can verify the guidance. Platform requirements can change; confirm the details that apply to your setup.