A professional working on a laptop in a contemporary office setting, focused on technology and productivity.

GA4 Reporting Identity on WordPress: Why Your Conversions and Channels Don’t Match

BySplinternet Marketing

If your GA4 numbers changed after switching Reporting Identity, linking Google Ads, enabling Consent Mode, or comparing Search Console to GA4, do not assume tracking suddenly broke. In many WordPress setups, the bigger problem is that teams compare reports built on different identity rules, attribution models, channel definitions, and privacy behaviors, then make budget or SEO decisions from the mismatch.

Google’s own documentation is clear on the main point: Reporting Identity changes how GA4 stitches and reports users. It does not “fix” attribution, and it does not mean your site started collecting events in a fundamentally new way overnight.

Why GA4 numbers change when you switch Reporting Identity

In GA4, Blended, Observed, and Device-based are different reporting lenses. According to Google Analytics help documentation, Blended can use User-ID, device identifiers, modeled data, and Google signals where available. Observed is narrower. Device-based relies primarily on device-level identifiers.

That matters because the same event stream can produce different user, session, and key event counts depending on which identity space GA4 uses in reporting. If your stakeholders compare one report under Blended against another export or ad-platform view that is effectively more device-based, the totals can move even when the site’s event firing did not change.

Consent configuration adds another layer. Google’s Consent Mode documentation explains that consent state affects how tags behave and what identifiers are available. If consent is denied for ad or analytics storage, some reporting can rely more heavily on modeled behavior or lose identifiers that would otherwise support stitching. Google also documents that thresholds can apply in some reports when Google signals and privacy protections are involved, which is another reason totals may not line up cleanly.

One important business implication: changing Reporting Identity or attribution settings can shift which channels or paths receive credit for key events, even if the conversion event on the site never changed. That is a reporting and credit-assignment change, not proof that campaign performance actually rose or fell.

Where the mismatches usually come from on WordPress

On WordPress, I would check implementation before debating GA4 philosophy.

First, confirm you do not have mixed tagging: a GA4 plugin, Google Tag Manager, theme-header code, WooCommerce extension output, or server-side tagging all firing overlapping pageviews or events. Duplicate page_view, purchase, generate_lead, or sign_up events will distort everything before Reporting Identity even enters the conversation.

Second, check attribution settings. Google documents that attribution model settings affect how credit is assigned across acquisition and conversion reporting. If someone changed attribution in Admin, your channel and conversion views may stop matching older screenshots, Google Ads numbers, or a Looker Studio report built on a different assumption.

Third, remember that GA4 default channel grouping follows Google’s current channel rules, not Universal Analytics habits and not your internal media naming logic. If your UTM taxonomy is loose, or if paid social, email, affiliates, and SMS are tagged inconsistently, channel totals can drift into buckets your team does not expect.

Fourth, do not treat Search Console integration as a conversion reconciliation tool. Google’s documentation shows that the GA4 link brings in Search Console reporting for organic search queries and landing pages, but it is not designed to match GA4 sessions or key events one-for-one. The products answer different questions and use different scopes and collection methods.

What to do next

  • Record your current setup: Reporting Identity, attribution model, key events, Google Ads link status, Search Console link status, and whether Google signals is enabled.
  • Use one primary tagging method where possible. Audit plugins, GTM, hardcoded theme snippets, and server-side containers for duplicate GA4 configuration tags or duplicated ecommerce events.
  • Test consent behavior with your CMP in real browsers. Verify default consent state, updates after banner interaction, and whether analytics and ads storage states are being passed consistently.
  • Verify User-ID logic if you expect cross-device stitching. Many WordPress and WooCommerce sites think they have User-ID working when they do not.
  • Check channel inputs: UTM naming, auto-tagging, referral exclusions, and payment gateway returns that can create session or source confusion.
  • Annotate changes when identity, attribution, consent, or key event settings change so future comparisons are not made against a different measurement lens.
  • Compare like with like: GA4 standard reports to GA4 standard reports under the same settings, ad-platform reports to ad-platform reports, and Search Console for organic query and landing-page context rather than conversion reconciliation.

The practical rule is simple: before changing Reporting Identity, prove your WordPress tagging and consent setup are clean. Otherwise you may “solve” a reporting mismatch by changing the lens while the underlying implementation problem stays in place.

Sources

Know someone who would benefit from this update? Share this article with them.

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.

Related Posts

Splinternet Marketing