What should a team validate first when modelled conversions in ga4: when they activate and when they don't appears?

Reproduce the problem in the live implementation, isolate whether it is scoped to one report or flow, and compare it against at least one secondary source before changing the setup.

How do I know whether the fix actually worked?

You need before-and-after evidence in the browser and in the downstream report. A clean-looking dashboard without validation is not enough.

When should this become a full GA4 audit instead of a quick fix?

If the issue touches attribution, consent, revenue, campaign quality, or data trust for more than one workflow, it is usually safer to audit the surrounding implementation than patch only the visible symptom.

Modelled Conversions in GA4: When They Activate and When They Don't (2026)

What are modelled conversions in GA4?

Modelled conversions are conversions GA4 statistically infers for the consent-denied population using machine learning trained on the consent-granted population. When users decline cookies (Consent Mode V2 with analytics_storage = denied), GA4 receives cookieless pings without identifiers — modelling reconstructs likely conversions from these.

Four prerequisites must ALL be met: (1) Consent Mode V2 in Advanced mode (Basic disables modelling entirely), (2) Blended reporting identity (Device-based or Observed disables modelling), (3) 1,000+ daily ad clicks per domain over 7 consecutive days (Google Ads modelling threshold), and (4) 7-day window of denied-state data for the model to train.

Below any threshold, modelling silently disables — no UI warning. Modelled data is shown without distinction from observed, with a small information indicator only.

This is the most misunderstood feature in GA4's privacy stack.

What modelling actually does

The mechanic in plain language:

A user visits with consent denied (analytics_storage=denied)
Advanced Consent Mode fires a cookieless ping to GA4 — contains event name, page URL, timestamp, but no client_id or user_id
The ping enters GA4's modelling pipeline rather than the standard reporting pipeline
GA4's ML model — trained on the property's consent-granted data — predicts whether this user likely converted
If yes, a synthetic conversion is added to your reports

Modelled conversions appear in your GA4 reports alongside observed conversions. They're not labelled differently in standard views — only the small information indicator on certain reports tells you modelling is contributing.

The output: a report that's closer to "true" conversion volume than the observed-only data would be. The catch: only when the prerequisites are met.

The four prerequisites — all required

Modelling has four requirements. Failure on any single one disables modelling silently.

1. Consent Mode V2 in Advanced mode

Basic Consent Mode blocks all GA4 hits when consent is denied. With no data flowing, the model has nothing to operate on.

Advanced Consent Mode fires cookieless pings even when consent is denied — the data the model trains on. This is the only mode that enables modelling.

Verify: in DevTools, with consent denied, check if any collect requests fire. If yes (with gcs=G100), you're on Advanced. If no requests fire, you're on Basic — modelling cannot work.

2. Blended reporting identity

GA4 has three reporting identity options: Blended, Observed, and Device-based. Only Blended enables modelling.

Device-based — disables modelling entirely
Observed — disables modelling entirely
Blended — required for modelling to operate

Verify: GA4 Admin → Property settings → Reporting identity. Confirm "Blended" is selected.

3. 1,000+ daily ad clicks per domain over 7 consecutive days

The volume threshold for Google Ads-driven modelling. Properties below this threshold can't activate modelled conversions for paid traffic.

This is per-domain, not per-property. A property with multiple domains needs each domain to clear the threshold independently.

Verify: Google Ads → Campaigns → check daily clicks per campaign aggregated to domain level. If below 1,000/day per domain, modelling won't activate for that domain's Google Ads conversions.

For non-Google-Ads-driven traffic (organic, email, paid social), GA4 has its own modelling thresholds that aren't publicly documented but appear to operate at lower volumes.

4. 7-day denied-state data window

The model needs at least 7 days of denied-state data to train. New properties or properties with very recent V2 implementations don't have this data yet — modelling waits until enough data accumulates.

Want to see whether attribution loss is already distorting your channel data?

Audit attribution

A property with 100% acceptance rate (everyone clicks Accept All) has zero denied-state data — there's nothing to model on, so modelling never activates even though the property's volume might otherwise qualify.

Verify: check your consent acceptance rate. Below ~95% accepted = some denied data exists; modelling can train. Above ~95% = effectively no denied data; modelling has nothing to do.

How to verify modelling is active

Three checks:

Check 1 — GA4 admin indicators. Admin → Property settings → Reporting identity should be Blended. The page may show a small note about modelling status.

Check 2 — Comparison reports. In a standard Acquisition report, hover over the "Conversions" column header. A small information indicator may indicate modelled data is included. Click for details.

Check 3 — BigQuery validation (most reliable). Run a query counting events by privacy_info.uses_transient_token (cookieless pings):

The "Yes" rows are your cookieless pings — the data modelling operates on. If the count is consistently > 100/day, you have enough denied-state data for modelling to train.

When modelling silently disables

Five common silent-disable scenarios:

Scenario 1 — Consent acceptance climbs above ~95%

If your CMP UX dramatically improves and acceptance rate spikes (typical after fixing dark-pattern UX or removing a confusing banner), denied-state data drops below the model training threshold. Modelling disables.

Counter-intuitive insight: moderate consent acceptance (60-80%) is what enables modelling. Very high acceptance defeats the purpose by leaving no denied population to model.

Scenario 2 — Reporting identity changed

Someone changes Reporting identity to Observed (perhaps to "improve accuracy" without understanding the consequence). Modelling disables.

Scenario 3 — Volume drops below threshold

Seasonal traffic decline pushes daily ad clicks below 1,000/domain. Modelling disables for that domain's paid conversions.

Scenario 4 — Consent Mode regression

A CMP update or new banner deploy reverts to Basic mode (perhaps as a perceived "more compliant" choice). Modelling disables — Basic mode blocks the cookieless pings the model needs.

Scenario 5 — V2 signal regression

A property running V1 only (missing ad_user_data and ad_personalization) loses modelling for Google Ads-driven conversions even with all other prerequisites met. The V2 signals are required for the Ads-side modelling pipeline.

In all five scenarios, the GA4 UI doesn't loudly warn — modelling just stops contributing. Numbers gradually drop without obvious cause. Stakeholders interpret as "tracking is broken."

What modelling can't replace

Modelling fills the consent-denied gap statistically. It doesn't replace:

Direct attribution accuracy. Modelled conversions are statistical inferences, not measured conversions. Use them for trends and aggregates, not specific user journey analysis.
Real-time data. Modelling lags 24–48 hours minimum.
Cross-device tracking for denied users. Each device's denied data is modelled independently.
Specific event detail. Modelled conversions don't have full event parameters; they're aggregate-level signals.

Stakeholders should understand: modelling helps your aggregate numbers be approximately correct in the consent-aware era. It doesn't make individual user journey reports magically complete.