How to Set Up Google Consent Mode v2 (Step-by-Step)

Google Consent Mode v2 is now mandatory for any business running Google Ads, using Google Analytics, or deploying Google Tag Manager. Since March 2024, Google requires all advertisers serving ads in the EEA to implement Consent Mode v2 to retain access to remarketing, audience features, and conversion measurement. But the impact extends far beyond Europe — MENA businesses running Google Ads campaigns that target any European audience, or that use GA4 for analytics, must implement these consent signals or face significant data loss.

Why Google Consent Mode v2 Is Required

Google introduced Consent Mode v2 in response to the EU Digital Markets Act (DMA), which classifies Google as a gatekeeper and requires explicit user consent before processing personal data for advertising. Without Consent Mode v2 signals from your website, Google cannot determine whether a visitor has consented — so it treats all data as non-consented. This means no remarketing audiences, no conversion modeling, and degraded campaign performance.

The practical impact is severe. Advertisers without Consent Mode v2 lose access to audience lists, see conversion tracking gaps of 30-60%, and cannot use Smart Bidding effectively because Google lacks the consent signals needed for its machine learning models. For MENA e-commerce brands spending significant budgets on Google Ads, this translates directly into wasted ad spend and lower ROAS.

What Changed from v1 to v2

Consent Mode v1 had two parameters: analytics_storage and ad_storage. Version 2 adds two critical new parameters: ad_user_data (controls whether user data can be sent to Google for advertising purposes) and ad_personalization (controls whether personalized ads can be shown). These new parameters are mandatory — Google Ads will not function correctly without them. Your CMP must fire all four signals on every page load.

The Four Consent Parameters

Google Consent Mode v2 uses four parameters to control how Google tags behave. Each must be set to either 'granted' or 'denied'. On initial page load, all should default to 'denied' until the visitor makes a choice:

• analytics_storage — controls Google Analytics cookies (maps to your 'analytics' consent category)
• ad_storage — controls advertising cookies and identifiers (maps to your 'marketing' consent category)
• ad_user_data — controls whether user-level data (email, phone) can be sent to Google for ad matching
• ad_personalization — controls whether Google can use data for personalized ad targeting and remarketing

Step 1: Set Default Denied State

The most critical step is ensuring your default consent state fires BEFORE any Google tags load. This means calling gtag('consent', 'default', { analytics_storage: 'denied', ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied' }) as the very first thing in your page head — before GTM, before GA4, before any other script. If this default fires after Google tags, you have a compliance gap.

Step 2: Update Consent on User Choice

When the visitor interacts with your consent banner and makes their choice, your CMP must immediately fire gtag('consent', 'update', {...}) with the new parameter values. If the visitor accepts analytics but declines marketing, the update call sets analytics_storage to 'granted' while keeping ad_storage, ad_user_data, and ad_personalization as 'denied'. This update must fire synchronously — any delay means Google tags may fire with stale consent state.

Step 3: Handle Returning Visitors

For returning visitors who previously gave consent, your CMP must read the stored consent cookie and fire the appropriate default state on page load. If a visitor accepted all categories yesterday, today's page load should fire the default with all parameters granted. This ensures Google tags receive correct consent signals immediately, without waiting for the banner to appear. Arqam360 handles this automatically by reading the consentiq_consent cookie before any tags fire.

Impact on GTM, GA4, and Google Ads

With Consent Mode v2 properly implemented, Google Tag Manager fires tags in 'advanced' mode — sending cookieless pings when consent is denied, which Google uses for conversion modeling (recovering an estimated 70% of lost conversions). GA4 continues to receive anonymized event data even without consent, providing directionally accurate analytics. Google Ads benefits the most: with all four parameters properly signaled, you retain access to remarketing audiences, Enhanced Conversions, and Smart Bidding optimization. Without Consent Mode v2, Google Ads essentially operates blind.

Testing Your Implementation

Verification is essential. Use Google Tag Assistant (the Chrome extension) to inspect consent signals on your live site. Check three scenarios:

• Fresh visitor: Verify default 'denied' fires before any tag, then 'update' fires on banner interaction
• Returning consented visitor: Verify default fires with 'granted' immediately on page load
• Consent withdrawal: Verify 'update' fires with 'denied' when a visitor revokes consent
• Google Ads diagnostics: Check Tools > Diagnostics in Google Ads for green checkmarks on all four parameters

Setup with Arqam360 (Zero Code Required)

Arqam360 handles the entire Consent Mode v2 implementation automatically. There is no code to write, no GTM variables to configure, and no tag sequencing to manage. Add the Arqam360 script to your site and enable the Consent Mode toggle in your dashboard — everything else is handled for you:

• Fires denied defaults before any Google tag loads — guaranteed first-position execution
• Updates all four parameters in real-time when visitors interact with the banner
• Automatically reads stored consent for returning visitors
• Supports both 'basic' mode (tags blocked until consent) and 'advanced' mode (cookieless pings sent)
• Compatible with GTM, gtag.js direct, GA4, and Google Ads conversion tracking
• Works alongside server-side Google Tag Manager via Arqam360's sGTM integration

How Consent Mode v2 Maps to Saudi PDPL Requirements

Google Consent Mode v2 was built primarily to satisfy the European Digital Markets Act and GDPR. The good news for Saudi merchants: the same signal architecture also satisfies the Personal Data Protection Law (PDPL) consent requirements, with one structural difference worth understanding. PDPL Article 6 requires explicit consent before processing personal data for non-essential purposes. The Implementing Regulations make clear that opt-out consent (the kind some U.S. privacy frameworks use) is not acceptable. Visitors must actively grant permission before any tracking-cookie write, before any tracking-pixel fire, and before any analytics ID is created.

Consent Mode v2's denied-by-default architecture lines up cleanly with this. When you fire gtag('consent', 'default', {analytics_storage: 'denied', ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied'}) before any Google tag loads, you have satisfied the PDPL no-processing-before-consent requirement for every Google product on the page. The update call after the banner click is the PDPL-recognised consent event. Auditors looking at your site's network requests in a fresh browser will see the denied default fire first, then no Google data calls until the user clicks — which is exactly the audit trail SDAIA is increasingly looking for.

Platform-Specific Implementation

How you wire Consent Mode v2 depends on your storefront platform. Every path below produces the same end state — denied default fires first, update fires on consent — but the implementation surface differs.

Shopify

Shopify exposes the Customer Privacy API, which is the official integration point for consent on Shopify storefronts. A compliant CMP installed via the Shopify App Store calls window.Shopify.customerPrivacy.setTrackingConsent() when the visitor accepts or declines. If you also use Google Tag Manager on Shopify, the CMP must additionally call gtag('consent', 'update', ...) — the Customer Privacy API does not automatically propagate to GTM tags. The Arqam360 Shopify app handles both surfaces in one click; merchants on the App Store install it, the banner appears, both Shopify analytics and GTM-loaded Google tags inherit the consent state automatically.

Salla

Salla merchants embed CMP scripts via the App Store or by pasting a script tag into the storefront theme settings. The widget loader pattern Salla recommends — async, single script, executes before any third-party tag — is ideal for Consent Mode v2 because the gtag default-denied call fires before Google's gtag.js bundle even loads. The Arqam360 Salla app installs in two clicks from the marketplace and ships denied-default Consent Mode v2 wired in. No theme code, no GTM container, no developer required.

Zid

Zid follows a similar app-embed pattern to Salla. The script tag added by the Zid app sits in the storefront head, fires Consent Mode v2 defaults before page tags, and updates on banner interaction. Zid merchants often have heavier ad spend than Salla peers (more Google Ads conversion tracking, more Meta CAPI) so the GCM v2 wiring is even more revenue-critical here — denied defaults that the merchant cannot detect quietly suppress 30-50% of attributable conversions until consent is granted, the exact problem GCM v2 modeling solves.

WordPress

WordPress merchants have two paths: a CMP plugin or manual GTM configuration. The Arqam360 WordPress plugin (slug: arqam360-consent-privacy-pdplgdpr on wordpress.org) handles GCM v2 automatically — install, activate, paste the API key from your dashboard, and the banner ships with denied defaults wired. For sites with custom GTM containers, you can also use the GCM-v2 built-in template; the configuration is identical, just managed in GTM rather than in WordPress admin.

Custom-built sites

For sites without a CMP plugin or app integration, the manual setup is: (1) add the gtag stub to the document head before any other script — this is the gtag('consent', 'default', ...) call with all four parameters set to 'denied'; (2) load Google tags (gtag.js, GA4, Google Ads, Floodlight) AFTER the default fires; (3) wire your banner's accept/decline buttons to gtag('consent', 'update', {...}) calls. The order is non-negotiable — the default must fire first or Google tags will read implicit consent from their own state and ignore your subsequent updates.

How to Verify Your Implementation Works

Three free tools confirm GCM v2 is wired correctly. Run all three on a fresh browser session (incognito or a new browser profile) to simulate a first-time visitor; running on your own browser with existing cookies will give misleading 'consent granted' readings.

• Google Tag Assistant Companion (Chrome extension): open the extension, refresh the page, click the 'Tags' tab. You should see the gtag('consent', 'default') call fire first, with all parameters showing 'denied'. After clicking your banner's Accept button, a gtag('consent', 'update') call should fire with the parameters you mapped to 'granted'.
• GTM Preview Mode (Tag Assistant): connect to your GTM container in Preview mode. You should see the consent event fire before any tag executes. Tags configured with 'Require additional consent for tag firing' should stay paused until the matching consent parameter flips to 'granted'.
• GA4 DebugView: visit the GA4 property → Configure → DebugView. Hit the site with debug_mode=1 in the URL. You should see no events when consent is denied, then a flood of events appear after granting. If events arrive in DebugView while the banner is still showing denied, your default fired AFTER GA4's first tag — fix the load order.
• Browser DevTools Network tab: open DevTools → Network → filter by 'google-analytics' or 'doubleclick'. On a fresh visit you should see ZERO requests to these domains before banner interaction. If you see requests firing immediately, Consent Mode is not blocking them — the default state isn't set or the tags are loading independently of gtag.
• Saudi PDPL audit framing: an SDAIA inspector reviewing a complaint will run the same network-tab check. Your defense against an investigation is the network log showing 'no Google tracker requests before consent.' Make this trivially verifiable on your site by ensuring 100% blocking until consent — partial blocking ('most tags wait, one fires early') is harder to defend than full blocking.
• Returning-visitor verification: in incognito, accept consent, close the window, open a new incognito window, visit the site again. Your stored consent should restore, the default call should fire with 'granted' values, and tags should execute normally. If the banner shows again, your CMP isn't persisting the consent record correctly — a separate compliance bug to fix.

Five Common Mistakes (and How to Avoid Them)

Most failed GCM v2 implementations fail in one of five specific ways. The pattern is consistent across our Saudi scan data — over 70% of stores fall into one of these traps. If you implemented Consent Mode v2 yourself, check your setup against each before assuming you're compliant.

Mistake 1 — Firing the default AFTER GA4. The most common failure. Developers add gtag('consent', 'default', ...) inside the same script block as gtag('config', 'G-XXXXX', ...) or after the GA4 tag in GTM. Result: GA4 has already initialized with implicit consent, then sees the denied default but treats it as a contradiction and ignores it. Tags fire data unconditionally despite the consent UI showing 'denied.' Fix: the consent default must be the FIRST gtag call on the page, before any other Google product loads.

Mistake 2 — Missing the new v2-specific parameters. Consent Mode v2 introduced ad_user_data and ad_personalization on top of v1's ad_storage and analytics_storage. Most CMPs migrated from v1 to v2 simply by renaming, leaving the two new parameters unset (which Google treats as denied by default — sometimes desirable, sometimes not, but always non-explicit). The fix is to explicitly set all four parameters on both the default and the update calls. If your CMP doesn't emit ad_user_data and ad_personalization, it's a pre-v2 implementation regardless of what its docs claim.

Mistake 3 — Mapping 'marketing' to ad_storage only. The category-to-parameter mapping is a frequent source of silent under-consent. A user accepts 'Marketing' on your banner, but if your CMP only updates ad_storage and ignores ad_user_data and ad_personalization, you've technically not granted full advertising consent — Google Ads remediated-conversion modeling won't engage, Meta CAPI gets a partial signal, and your remarketing audiences won't populate. Map 'Marketing' to all three ad parameters (ad_storage + ad_user_data + ad_personalization) simultaneously.

Mistake 4 — Not handling consent withdrawal. PDPL Article 6 requires that withdrawing consent is as easy as giving it. Most CMPs handle the initial grant but never fire a gtag('consent', 'update', ...) call when the user later clicks 'Reject all' or changes their preferences. Result: tags continue firing on every page load even though the consent state has changed in your CMP's local storage. Fix: every settings change must propagate an update call. Test by accepting then immediately rejecting from the preferences modal — network requests to google-analytics should stop within one page navigation.

Mistake 5 — Relying on a CMP that doesn't fire gtag updates at all. Some older 'cookie banner' tools manage cookies via document.cookie writes but never integrate with Consent Mode v2's gtag API. To Google's tags, this looks like no consent management exists; default state stays at whatever was last set (often nothing), and modeling either fails to engage or engages at the wrong baseline. Fix: pick a CMP that emits gtag consent calls natively rather than only writing cookies. The check that matters is observable: open the Tag Assistant and confirm a denied default fires before any Google tag, then an update on the visitor's choice. Arqam360 emits all four parameters that way.

Frequently Asked Questions

Authoritative Sources

Next Steps

If you are setting up Consent Mode v2 from scratch, the fastest path is to install a CMP that ships denied defaults already wired, then run the five-verification-tool check above to confirm. Note that Google's certified CMP list is a separate requirement, and only for serving ads in the EEA, UK and Switzerland — it is not a measure of whether Consent Mode v2 is implemented correctly. If you already have a CMP but suspect it is non-compliant, run the verification tools first: most failures are in mistake categories 1, 2, or 3 above and are fixable without changing vendors.