Original Research

Google Consent Mode v2 Setup Guide (India) | ibs Fulcro

A real, technical walkthrough for setting up Consent Mode v2 through Google Tag Manager, built for Indian marketing teams working toward DPDP compliance. Plus two direct questions answered honestly: can this actually be implemented in India, and what genuinely happens to remarketing when a user says no.

Key Takeaways

  • Yes, it can be implemented in India, but Google doesn't require it here. Google's own mandate for Consent Mode v2 applies to EEA, UK, and Swiss traffic specifically. Using it in India is a real, sound, voluntary choice in support of DPDP compliance, not a Google requirement being enforced on Indian sites.
  • Remarketing to a user who declines consent is not possible, on either platform. Both Meta and Google structurally require storing an identifier tied to that specific person to remarket to them. Consent denial blocks exactly that. What survives is aggregate, anonymised conversion modelling, real signal, but not a way to rebuild that individual's remarketing profile.
  • The real setup is five steps, done once, correctly. A Consent Management Platform, a default-denied consent state, a Consent Initialization trigger that fires before every other tag, an update command tied to the user's real choice, and verification that the signal actually reaches Google, not just that the banner looks right.

First, Directly: Can This Be Implemented in India?

Yes, technically. Consent Mode v2 is a generic gtag and Google Tag Manager API, four consent parameters and two JavaScript commands, not code that only works for European traffic. Any website, anywhere, including one serving only Indian visitors, can implement it.

The real nuance worth being precise about: Google's own mandate for Consent Mode v2, the requirement that non-compliant accounts lose remarketing and personalised advertising features, currently applies specifically to advertisers serving or measuring users in the EEA, the UK, and Switzerland. Google has not issued the same mandate for India. Implementing Consent Mode v2 here is a real, deliberate, voluntary technical choice made in support of DPDP compliance, not something Google is currently enforcing on Indian sites the way it enforces it on European ones. That distinction matters: you won't get a Google warning for skipping it in India today, but skipping it doesn't make unconsented GA4 or remarketing tracking DPDP-compliant either. The two are separate questions.

The honest legal position: DPDP requires consent before tracking, regardless of what Google does or doesn't enforce. Consent Mode v2 is one real, working technical mechanism for honouring that requirement while preserving some measurement capability. It's the tool, not the law.

Second, Directly: What Happens to Meta and Google Remarketing?

For any individual visitor who declines consent, remarketing to that specific person becomes impossible, on both Meta and Google. This isn't a platform limitation to work around; it's the structural point of consent denial. Remarketing works by storing an identifier tied to a real person and using it to show them ads later. Denying consent blocks exactly that identifier from being stored in the first place.

What does survive, on the Google side, depends on which Consent Mode implementation is used. Advanced Consent Mode still sends an anonymised, cookieless ping even when consent is denied, no cookie set, no individual identified, but the aggregate signal feeds Google's conversion modelling, giving a real, if imperfect, estimate of overall campaign performance across consenting and non-consenting users combined. Basic Consent Mode is stricter: it blocks the tag from firing at all on denial, meaning no modelling signal either, a cleaner compliance posture with a real, larger measurement gap.

On the Meta side, the same real principle applies through the Meta Pixel's consent command and the Conversions API: without consent, no identifier is passed, and that individual cannot be added to a remarketing audience. Aggregate modelling may still apply depending on how Meta's systems are configured, but individual-level remarketing does not survive a decline, by design.

Step by Step: Setting Up Consent Mode v2 Through Google Tag Manager

This assumes a GA4 property (Universal Analytics was retired on 1 July 2024 and is no longer operational) and a Google Tag Manager container already installed on the site. Screenshots for each step below to be added.

1

Choose and install a Consent Management Platform

Select a CMP capable of sending Google's four real consent signals (ad_storage, analytics_storage, ad_user_data, ad_personalization), not just a cookie banner that looks like a consent tool. The CMP is what actually captures a user's real, granular choice and passes it through to Google Tag Manager.

Screenshot to be added
2

Set the default consent state to denied

Before any tag loads, all four parameters must default to 'denied.' This is the real, technical expression of DPDP's opt-in requirement: no tracking happens until a user has actively made a choice, not until they've simply loaded the page.

Screenshot to be added
3

Fire the default command through GTM's Consent Initialization trigger

In Google Tag Manager, the default consent command must run through the dedicated 'Consent Initialization' trigger, which fires before every other tag on the page, including GA4 and any remarketing tags. If the default command fires late, or through a regular trigger, tags can fire before the denied state is actually in place, defeating the entire setup.

Screenshot to be added
4

Fire the update command when the user makes a real choice

Once a visitor interacts with the consent banner, granular grant or decline, the CMP should fire gtag's 'consent update' command with the real values the user actually chose, not a blanket grant. This is what moves the relevant parameters from denied to granted for that specific user, for that specific purpose.

Screenshot to be added
5

Verify the signal is actually reaching Google, not just that the banner looks right

Use Google Tag Manager's Preview mode and Google's Tag Assistant to confirm the real consent state at each stage: the default 'denied' state on load, and the 'granted' update firing correctly after a real user action. A banner that displays correctly but never actually calls the gtag consent commands is decorative, not functional, and won't produce compliant behaviour no matter how it looks to a visitor.

Screenshot to be added

Why the Order of Operations Is the Part Most Setups Get Wrong

The single most common real failure in Consent Mode v2 implementations isn't a missing parameter, it's sequencing. The default command has to run before the Google tag loads and before any other GTM tag fires. A consent banner that visually appears correct but was wired through a regular page-load trigger, rather than GTM's Consent Initialization trigger specifically, can still let the first network requests fire without any consent state attached at all. The setup looks right and fails silently, exactly the kind of gap that's invisible until a real compliance review or a real data drop-off shows something is wrong.

Why does this matter under Indian law specifically? We've published a real breakdown of the legal basis: why GA4 and remarketing pixels are non-compliant when they fire before consent under the DPDP Act, why GDPR's “legitimate interest” shortcut doesn't exist here, and the real enforcement timeline and penalties. Read the full DPDP breakdown.

Worried about how much real traffic consent-gated GA4 is actually missing? We've published a real, proposed framework for measuring the gap directly: running a consent-free tool like Plausible alongside GA4, calculating an extrapolation quotient by segment, and automating the comparison through Claude and the real GA4 MCP server. Read the verification framework.

Want the complete implementation reference, not just the Google-specific steps? We've published our full, real build standard for cookie and tracking consent under DPDP, non-negotiables, a reference banner pattern, reusable copy, and a complete QA checklist, alongside working code for every step above. Read the complete standard.

References

  • Google, Consent Mode: Frequently Asked Questions, and Consent Mode v2 technical documentation.
  • Google Tag Manager Help, “Updates to consent mode for traffic in European Economic Area (EEA).”
  • Meta Business Help Center, Meta Pixel and Conversions API consent documentation.

Need help navigating the marketing impact of the DPDP Act? Reach out to us for a no-obligation chat, or explore our Brand & Digital Strategy practice.

Let's talk about what this could look like for your brand

Start a Project