Consent Mode v2 on Shopify: Basic vs Advanced Implementation — What Each Sends Before Consent

This guide is for Shopify merchants choosing between basic and advanced Consent Mode v2 — and the state where a banner gates tags but sends no signal. It compares the three at mechanism level: what leaves the browser before a choice, how Shopify’s Customer Privacy API carries the decision, and what GA4 and Google Ads show later.

It does not rank modes or tools, and it does not rule on your legal obligations; a privacy lawyer owns those. This covers technical implementation, not legal advice. It quotes no vendor prices; for CMP pricing, see each vendor’s pricing page.

What does basic Consent Mode v2 actually send before a choice?

In basic mode the Google tag does not load until the visitor answers the banner, so Google receives nothing before that point — not even the default consent state — and nothing at all if the visitor declines. After a grant, the tag loads and sends the default and updated consent states.

On Shopify, two mechanisms must line up: the banner or CMP writes the decision through the Customer Privacy API, and your tag loader reads it before injecting the Google tag. Those are independent, and a fault appears when the two disagree — the CMP records a choice while a theme snippet, app tag, or web pixel injects the tag.

The cost is structural: Google states that in basic mode, conversion modelling in Google Ads falls back to a general model.

What does advanced Consent Mode v2 send before a choice?

Advanced mode loads the Google tag on page open with consent defaults denied; while consent is denied the tag sends cookieless pings and no full measurement, and it switches to full measurement and cookies only on a grant.

Google describes three cookieless pings while consent is denied: consent state pings from each page where consent mode is enabled, key event pings, and Google Analytics pings.

Those pings are thin, but cookieless is not identifier-free. Google lists their contents as functional information (timestamp, user agent, referrer) and aggregate or non-identifying information: whether the current or a prior page carried ad-click parameters such as GCLID or DCLID, a boolean consent state, and a random number generated on each page load. With ad_storage denied, Google states that no new advertising cookies or device identifiers are written and none are read, and that Ads products truncate IP addresses at collection — yet the full page URL, including ad-click parameters, is still collected. ads_data_redaction redacts those identifiers in consent and key event pings and in page URLs that contain them.

The consent state travels in request parameters. Google documents gcs as transmitting ad_storage and analytics_storage, and gcd as always being sent whether or not consent mode is active.

Advanced also enables the advertiser-specific Google Ads conversion model. GA4 behavioural modelling is a separate product with its own requirements: consent mode on every page, tags loaded before the consent dialog in all cases, at least 1,000 events per day with analytics_storage denied for at least 7 days, and at least 1,000 daily users sending granted events for at least 7 of the previous 28 days. Meeting those does not guarantee eligibility; the model applies its own quality checks. Google Ads conversion diagnostics distinguishes “Consent mode is implemented” from “Consent mode is implemented and modeling is active”, and Google documents an Ads click threshold of 700 clicks over 7 days.

On Shopify the same Customer Privacy API is a storefront JavaScript API, mapped differently: the CMP translates its purposes into Google consent types and sends the update on a choice. Web pixels are a separate execution context — strict for app pixels, lax for custom pixels — where the pixel reads init.customerPrivacy and subscribes to visitorConsentCollected. Shopify’s pixel manager releases a pixel only when visitor permission covers every declared purpose, so a pixel withheld until permission exists cannot emit pre-consent Google pings; those come from the Google tag in the storefront document. Google states that Google tags inside a Shopify custom pixel are not a supported implementation.

What happens if you run no consent mode at all?

A banner that gates your Google tags without calling a consent API leaves Google unable to verify the visitor’s choice; Google’s EEA guidance says this may lead to loss in data. Basic and advanced consent mode both exist to correct it.

The same documentation states that advertisers must collect consent for EEA end users and share signals with Google to keep using applicable tags for measurement, personalisation, and remarketing; without valid signals, those features are restricted for EEA traffic. GA4’s Consent settings show per data stream whether advertising and behaviour analytics signals are arriving.

So no consent mode is not neutral: it is the state both other options exist to improve on.

Side-by-side

The table compares the three states on the criteria that decide most Shopify implementations. It describes trade-offs and does not rank them; none repairs a purchase event broken for unrelated reasons.

Criterion	Basic Consent Mode v2	Advanced Consent Mode v2	No consent mode (CMP gating only)
Event source	Tag injected only after the visitor chooses	Tag loads on page open, defaults denied	Loader or CMP decides; no consent API called
Purchase and refund coverage	Neither mode instruments purchases or refunds; your theme, app, or pixel must send the purchase, and refunds need their own order-data path	Same instrumentation; consent mode only governs when the signal may carry full measurement	Same instrumentation, but events reach Google with no consent state attached
Deduplication	Inherited from your Shopify purchase path; unchanged by mode	Same	Same
Consent handling	Tags withheld until grant; states sent after grant	Defaults denied, update on choice, pings while denied	Recorded by the CMP, not signalled to Google
Control and data destination	Merchant controls tag loading; nothing reaches Google before a grant	Merchant controls defaults and updates; cookieless requests reach Google while denied	CMP controls gating; Google receives requests with no consent state
Dependency and lock-in	Depends on the CMP loader and your own gating	Depends on the CMP mapping to Google consent types	Depends entirely on the CMP
Maintenance burden	Re-check gating when the loader or CMP changes	Re-check defaults, updates, and region logic	Only the CMP gate to build; EEA features stay restricted
Who it suits	Stores that will not load a Google tag early	Stores that want modelling eligibility and EEA coverage	Stores prepared to lose EEA Google measurement

Decision table

Match your situation to a starting point. These are defaults for common cases, not rules.

If your situation is …	Choose …
EEA visitors are a meaningful share of traffic and you need advertiser-specific Google Ads conversion modelling	Advanced — basic sends no pre-consent signal and models from Google’s general model
You want GA4 behavioural modelling to be eligible	Advanced — Google requires tags to load before the banner in all cases
No Google request may occur before a choice	Basic Consent Mode v2
You run basic mode and want to know what modelling remains	Google’s general Ads conversion model; advanced only if you need the advertiser-specific one
Your CMP records consent but Google receives no signal	Implement consent mode; basic is a valid first step
Your purchase event is already broken or double-counted	Neither — fix the purchase path first
You do not know what Google currently receives	Audit the default and update before choosing a mode

When not to use each option

Basic forfeits modelling depth, advanced sends cookieless pings before a choice, and no consent mode risks your EEA features.

Do not choose basic mode if you need GA4 behavioural modelling — its prerequisites require tags to load before the dialog in all cases — or if the general Ads model is not enough for your EEA bidding. Basic does support Google’s general Google Ads conversion model.

Do not choose advanced mode when your legal position forbids any request to Google before a choice; when your CMP cannot map purposes to all four Google consent types; or when nobody can verify the default and the update, since advanced mode fails quietly when the update never fires.

Do not run no consent mode when you advertise to EEA users, need audiences or remarketing there, or are treating “the banner blocks tags” as equivalent to consent mode.

How I verify this in real implementations

Verification covers what the page sets before any tag, what changes on consent, what each platform reports, and whether purchases reconcile against orders.

1. Read the default in Tag Assistant. Confirm all four parameters — ad_storage, ad_user_data, ad_personalization, analytics_storage — are denied before tags run.
2. Grant consent and read the update. Confirm the four are granted, then check which tags fired or were blocked. A missing update points to the CMP wiring.
3. Inspect the requests. Confirm the consent state is present in the request parameters, that advanced mode sends a denied-state request before a choice, and that basic sends none. Repeat with a simulated EEA location.
4. Read what the platforms report. In Google Ads conversion diagnostics, distinguish “Consent mode is implemented” from “Consent mode is implemented and modeling is active”, allowing for a documented delay of up to two weeks. GA4 DebugView shows events arriving live.
5. Check the Shopify side. Confirm which execution context each tag runs in: the Customer Privacy API and the Google tag belong to the storefront document, while a web pixel sits in its own sandbox, reads init.customerPrivacy, and subscribes to visitorConsentCollected. A pixel Shopify has not released yet cannot be the source of a pre-consent ping. Where Meta events run too, Events Manager Test Events should show the pixel obeying the same gate.
6. Reconcile against orders. Compare GA4 purchases with a closed-period Shopify orders export using the standard order-level method. Consent mode changes signal quality, not how you reconcile — order reconciliation is where a real gap shows.

Common failure modes

Consent mode can fail in the wiring even when the model is healthy: a default set too late, an update that never fires, a region default that contradicts the banner, or a CMP that records a choice no tag ever reads.

• Default set after a tag has already run, so consent mode does not affect the request already sent.
• Update called as the page unloads, so the browser cancels the request and the granted state never reaches Google.
• The choice is not persisted, so a granted visitor reloads into the denied default on the next page.
• No update at all — the banner records a decision while the tag stays at its default state, in either direction.
• Region logic missing or contradictory, so EEA defaults bleed into other traffic or contradict the banner.
• Incomplete purpose mapping, or two Google tag paths live at once and loading tags with different defaults.

Limitations

Consent mode changes what Google receives and what it can model. It does not make an unreconciled number true, recover traffic a visitor refused, or replace legal advice; every mode stays bounded by the visitor’s choice and browser protections.

Modelled data is estimated, not observed. Google states behavioural modelling is included only when confidence in model quality is high, and that when there is not enough consented traffic to inform the model, events from users who decline consent are not reported at all. Several GA4 features never include it, among them audiences, user explorer, retention reports, predictive metrics, and BigQuery export. In reports, modelling applies to user, session, and new-user metrics but not to event counts such as page_view.

Shopify’s pixel sandbox and the storefront document are separate execution contexts: the pixel that observes consent is not the Google tag that acts on it, so they can disagree if declared purposes, CMP mapping, and tag defaults drift apart. No consent mode fixes attribution differences between GA4, Google Ads, and Shopify orders — they count different things on different clocks.

Alternatives

If your problem is not which mode to run, another layer may help: server-side delivery for transport loss, reconciliation for platform disagreement, and an audit when you do not know what is sent.

For the consent work itself, the Consent Mode v2 service covers CMP integration, region-aware gating, and server-side propagation, and the Consent Mode v2 knowledge base entry defines the signals and consent types. If requests are lost after consent rather than before it, that is transport, and server-side tracking is the layer to examine.

If the platforms simply disagree, start with why GA4 revenue does not match Shopify. If consent gating pushes legitimate sessions into the wrong bucket, see unassigned traffic and the GA4 unassigned traffic check. If you cannot tell what is sent at all, that is a tracking audit.