Google Consent Mode v2 in Saudi Arabia: Step-by-Step Setup for PDPL

Google Consent Mode v2 is how a website tells Google's tags what each visitor agreed to. Since March 2024, Google has required it from advertisers who want to keep remarketing, audience features and conversion measurement for users in the European Economic Area (EEA), and Google's EU user consent policy also covers the UK and Switzerland. For stores in Saudi Arabia the driver is different: the consent requirement in the Personal Data Protection Law (PDPL). This guide covers both.

Consent Mode carries the visitor's choice; PDPL decides when you need to ask for one. The rules themselves are in our Saudi PDPL cookie consent guide.

What is Google Consent Mode v2?

Google Consent Mode v2 is a Google API that passes a visitor's consent choices to Google tags such as GA4, Google Ads and Floodlight. It uses four signals: analytics_storage, ad_storage, ad_user_data and ad_personalization. Each is set to granted or denied, and Google's tags change what they store and send accordingly.

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

Arqam360's banner fires the denied defaults before the visitor chooses, then sends one update when they do: the Analytics category grants analytics_storage, and the Marketing category grants the three advertising signals together. functionality_storage and security_storage are always sent as granted, because they cover storage the site needs to work.

Is Google Consent Mode v2 mandatory?

For advertisers reaching users in the EEA, effectively yes: since March 2024 Google has required Consent Mode v2 signals to keep remarketing, audience features and conversion measurement for that traffic. Outside the EEA, the UK and Switzerland, Google does not impose the same requirement. There, the reason to implement it is local privacy law.

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 on measurement. Without Consent Mode v2 signals, Google cannot tell a consented visitor from one who declined, so for affected traffic it restricts remarketing audiences and cannot apply conversion modelling, and Smart Bidding works from thinner data. For stores that spend seriously on Google Ads, that shows up as weaker attribution and less efficient bidding.

Do Saudi stores need Google Consent Mode v2?

Google's own Consent Mode v2 requirement targets EEA and UK traffic, not Saudi Arabia. The Saudi driver is the PDPL: tracking that collects personal data needs a valid basis, normally consent, before it runs. If a Saudi store uses Google Analytics or Google Ads, Consent Mode v2 is how that consent reaches Google's tags.

Be precise about which rule applies. A Saudi store serving Saudi visitors is not caught by Google's EEA requirement, so anyone telling you Google will switch off your Saudi campaigns without Consent Mode v2 is overstating it. What the store is caught by is the PDPL, which SDAIA has enforced since 14 September 2024. The PDPL does not mention Consent Mode; it requires that consent be obtained and respected. Consent Mode v2 is the practical way to make Google's tags respect it, and it keeps conversion modelling available for visitors who decline.

Consent Mode v2 was built primarily for the EU's Digital Markets Act and the GDPR, but its signal design fits the PDPL well. Under the PDPL, visitors should actively grant permission before a tracking cookie is written, before a tracking pixel fires, and before an analytics identifier is created. An opt-out model, in which tracking runs until someone objects, does not meet that standard.

Consent Mode v2's denied-by-default design lines up with this. When you fire gtag('consent', 'default', {analytics_storage: 'denied', ad_storage: 'denied', ad_user_data: 'denied', ad_personalization: 'denied'}) before your Google tags load, no Google product on the page processes data as if consent had been given. The update call after the banner click records the visitor's actual choice. Anyone checking your site's network requests in a fresh browser will see the denied default first, then no Google data calls until the visitor clicks, which is the evidence you would want to show if a complaint reached SDAIA.

How do you set up Google Consent Mode v2?

Set all four signals to denied before any Google tag loads, update them with gtag('consent', 'update', …) when the visitor makes a choice, and restore the stored choice on later visits. A consent management platform (CMP) can do all three for you; the steps below show what it has to do.

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.

What happens to Google data when visitors decline consent?

In advanced mode, Google tags send cookieless pings when consent is denied, and Google uses them to model the conversions it can no longer observe. In basic mode, tags do not load until consent is granted, so nothing is sent. In neither mode are advertising cookies set for a visitor who declined.

Modelling is Google's answer to the gap. Reporting early results in April 2021, Google said conversion modelling through Consent Mode recovers, on average, more than 70% of ad-click-to-conversion journeys lost to cookie consent choices, and added that results vary widely with consent rates and setup. Treat that as Google's own early figure, not a forecast for your store. GA4 can also model behaviour for users who decline, once traffic thresholds are met. With all four parameters signalled correctly, Google Ads keeps remarketing audiences for consented users, Enhanced Conversions and Smart Bidding.

How do you set up Consent Mode v2 on Shopify, Salla, Zid and WordPress?

Use each platform's consent route. On Shopify, a CMP app that calls the Customer Privacy API and also sends gtag consent updates; on Salla and Zid, a consent app that adds the banner script to the storefront; on WordPress, a CMP plugin or a GTM consent template. In every case, the denied default must fire before your own tags.

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 add consent tools through the Salla App Store or the store's custom-code settings. One detail is specific to Salla: the platform loads its own Google Tag Manager container very early, so no app can set the consent default ahead of it. A consent app can set the denied default before your own page-load triggers and tags, and update it when the visitor chooses. The Arqam360 Salla app provisions the banner with Consent Mode v2 defaults on install, without theme code or a GTM container. Whichever app you use, check the order in Tag Assistant after installing.

Zid

Zid follows a similar app pattern to Salla. The script added by the Zid app sits in the storefront head, sets Consent Mode v2 defaults before your page tags, and updates them when the visitor interacts with the banner. Stores that run Google Ads conversion tracking or Meta's Conversions API should verify the order in Tag Assistant just as carefully: a default that fires late means tags have already run.

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. A Google tag that loads before it runs without any consent state and typically sends its hits and sets cookies for that page view. Later updates still apply from then on, but they cannot undo what already fired.

How do you check that Consent Mode v2 is working?

Open your site in a private window and use Google Tag Assistant: a consent default with all four signals denied should appear before any Google tag, and an update should follow when you click the banner. Then check the browser's Network tab: no requests to google-analytics.com or doubleclick.net should leave before you choose.

Each check below takes a few minutes. Run them in a fresh browser session (a private window or a new browser profile) to simulate a first-time visitor; your everyday 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 events appear after granting. If events arrive in DebugView while the banner still shows 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 framing: if a complaint reached SDAIA, the simplest evidence you could show is a network log with no Google tracking requests before consent. Make that easy to demonstrate by blocking fully until consent; partial blocking, where most tags wait but one fires early, is harder to defend.
• 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.

Quick checklist: four scenarios to test

Verification is essential. Use Google Tag Assistant (the Chrome extension) to inspect consent signals on your live site. Check four 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

Five Common Mistakes (and How to Avoid Them)

Most failed GCM v2 implementations fail in one of five ways. If you implemented Consent Mode v2 yourself, check your setup against each before assuming it works.

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 initializes and sends its first hits before any consent state exists, so that page view is measured and cookies may be set before the visitor has chosen. The late default does govern what happens next, but it cannot retract what already fired — while the consent UI shows '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. Some 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. The PDPL gives individuals the right to withdraw consent, and withdrawing should be as easy as giving it. Many 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 keep firing on every page load even though the consent state has changed in the CMP's local storage. Fix: every settings change must propagate an update call. Test by accepting, then immediately rejecting from the preferences panel — 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.

Setting up Consent Mode v2 with Arqam360

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:

• Sets the denied defaults early in the page, before your own Google tags and page-load triggers
• Updates all four parameters as soon as 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

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 verification checks 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 not working, run the verification checks first: most failures are in mistake categories 1, 2, or 3 above and are fixable without changing vendors.