Collaborative discussion over data charts and laptop, focusing on business strategies.

GA4 Attribution & Identity in 2026: Align Reporting and BigQuery

In 2026, the most common GA4 complaint I hear from WordPress and WooCommerce operators is simple: “The numbers don’t match.”

GA4 UI users differ from BigQuery users. Channel ROAS shifts after a settings change. Google Ads shows more conversions than GA4. Leadership assumes tracking is broken.

In most cases, it’s not a tagging failure. It’s configuration drift between Reporting Identity, Attribution settings, Key events, and Default channel grouping.

Here’s what each layer actually controls — and how to audit it before you question your revenue math.

What Reporting Identity and Attribution Actually Control

Reporting Identity changes deduplication in reports — not raw event collection

Google’s GA4 Reporting Identity documentation defines three options: Blended, Observed, and Device-based.

  • Blended can use User-ID (if implemented), Google signals (if available), and device identifiers.
  • Observed uses User-ID and device identifiers, without Google signals modeling.
  • Device-based relies on device identifiers only.

This setting affects how users and conversions are deduplicated in reports. It does not change how events are collected or stored.

If you switch from Device-based to Blended, you may see:

  • Fewer reported users (due to cross-device deduplication)
  • A different conversion rate
  • No actual change in traffic volume

That shift reflects reporting logic, not new visitor behavior. Cross-device impact depends on whether you have a working User-ID implementation and Google signals availability. Without those, Blended may not materially change reporting.

Important: identity changes affect how data is processed and shown in reports going forward. They do not fully rewrite historical modeling across all reports, which is why trend lines can look uneven after a mid-quarter change.

Attribution settings apply to key events

GA4 Attribution Settings are configured at the property level. Per Google’s documentation, they define:

  • The attribution model (for example, data-driven or last click)
  • The lookback window for acquisition and other key events

These settings apply to key events (formerly conversions). They do not change how events are collected; they change how credit is distributed in reports.

If you extend a lookback window from 30 to 90 days, more channels may receive credit for the same conversion. If you switch from last click to data-driven attribution, branded search may lose some credit while upper-funnel campaigns gain partial credit.

Those shifts can materially change reported ROAS and channel contribution even when traffic and revenue are stable. Model changes influence reporting and forward-looking evaluation; they are not a retroactive rewrite of all historical reporting contexts.

Default Channel Grouping is a separate classification layer

GA4’s Default Channel Group rules classify traffic based on source, medium, campaign parameters, and auto-tagging signals, as defined in Google’s Default Channel Group documentation.

This is separate from attribution modeling.

If your email platform uses inconsistent UTMs, traffic may fall into Unassigned or Direct. That is a classification issue. Changing attribution models will not fix mis-labeled traffic.

Why BigQuery and Looker Studio Don’t Match the GA4 Interface

According to GA4 BigQuery Export documentation, BigQuery contains event-level export data: individual events and parameters as collected.

The GA4 interface layers reporting identity, attribution modeling, Google signals (if enabled), privacy thresholding, and Consent Mode modeling on top of collected data.

Because of that:

  • User counts in BigQuery will not exactly match GA4 UI users under Blended or Observed identity.
  • Revenue totals often reconcile more closely than user metrics, assuming event parameters are implemented correctly.
  • Modeled data influenced by Consent Mode can affect what is visible in the UI.

Google’s Tag Platform Consent Mode documentation confirms that consent state affects how tags behave and what data is available for measurement and modeling. When consent limits identifiers, reporting layers may rely on modeled behavior.

BigQuery is not the “true” number while GA4 is wrong. They operate at different layers. BigQuery is best used to validate event counts and revenue totals, not to replicate UI user metrics without rebuilding identity and attribution logic yourself.

What to do next

If you operate WordPress or WooCommerce with Google Ads, Meta Ads, or local SEO campaigns, run this controlled audit before presenting numbers to leadership:

  1. Document Reporting Identity. In Admin → Reporting Identity, confirm whether Blended, Observed, or Device-based is active. Record the date of any changes.
  2. Review Attribution settings. Confirm attribution model and lookback windows. Log changes. Do not compare pre-change and post-change ROAS without annotation.
  3. Audit key events. In Admin → Events, verify which events are marked as key events. Confirm value and currency parameters are consistently passed for purchases and lead events.
  4. Validate channel classification. Review top source/medium combinations against GA4’s Default Channel definitions. Fix UTM inconsistencies before debating attribution performance.
  5. Check Consent Mode implementation. If using Consent Mode, confirm consent signals are firing correctly and set expectations internally about modeled reporting.
  6. Use BigQuery intentionally. Reconcile total events and revenue first. Treat user and session comparisons cautiously unless identity logic is aligned.
  7. Create a configuration log. Record identity, attribution, channel grouping, and consent updates. Many “performance swings” are configuration-driven.

When GA4, ad platforms, and BigQuery disagree, the fastest path to clarity is not re-tagging everything. It’s aligning identity, attribution, key events, and channel logic — then documenting those decisions so budget conversations are based on configuration-aware reporting, not panic.

Sources

Need help checking this on your WordPress, Google Ads, Analytics, local SEO, or website setup? Splinternet Marketing can review the issue and help you prioritize the next fix.

This article is for informational purposes only and reflects general marketing, technology, website, and small-business guidance. Platform features, policies, search behavior, pricing, and security conditions can change. Verify current requirements with the relevant platform, provider, or professional advisor before acting. Nothing in this article should be treated as legal, tax, financial, cybersecurity, or other professional advice.

Editorial note: Splinternet Marketing articles are researched from cited platform, documentation, regulatory, and industry sources. AI may assist with drafting and review; final content is checked for source support, practical usefulness, and platform/date accuracy before publication.