Google Consent Mode v2 and the DPDP Act: How Indian Websites Should Configure Tags in 2026

Short answer: Google Consent Mode v2 is Google's mechanism for adjusting tag behaviour based on a user's consent signals. It is a commercial requirement for running Google Ads remarketing and conversion features — not a legal compliance mechanism. Under India's DPDP Act you still need a compliant consent notice, per-purpose choice, and a durable consent record. Consent Mode consumes that decision; it does not produce it.

Two Different Requirements That Get Confused

Marketing teams in India routinely conflate two obligations that have nothing to do with each other.

	Google Consent Mode v2	DPDP Act 2023
Imposed by	Google (contractual platform policy)	Parliament of India (statute)
Consequence of ignoring	Remarketing audiences and conversion modelling degrade or stop	Penalties up to ₹250 crore
What it governs	How Google tags behave once consent is known	How consent is asked for, recorded, and withdrawn
Produces a consent record?	No	Required
Requires multilingual notice?	No	Yes — English plus 22 Scheduled languages on request

Key insight: Consent Mode is the plumbing downstream of the decision. The DPDP Act governs how the decision is obtained and evidenced. A site can be perfectly wired for Consent Mode v2 and still be in clear breach of the Act — and frequently is, because the banner that feeds the signals bundles every purpose into one Accept button.

The Four Consent Signals

Consent Mode v2 uses four parameters. Two arrived with v2 specifically to support Google Ads personalisation requirements.

Signal	Controls	Introduced
analytics_storage	Analytics cookies and GA4 measurement storage	v1
ad_storage	Advertising cookies and identifiers	v1
ad_user_data	Sending user data to Google for advertising purposes	v2
ad_personalization	Use of data for personalised advertising and remarketing	v2

Two further parameters — functionality_storage and personalization_storage — cover site functionality and personalised content, and security_storage covers authentication and fraud prevention. Each is set to granted or denied.

Basic vs Advanced Consent Mode

The choice between the two modes is the decision most likely to create a DPDP problem, because Advanced mode loads Google tags before consent is given.

	Basic mode	Advanced mode
Tags before consent	Blocked entirely — nothing fires	Tags load and send cookieless pings
Data on refusal	None	Aggregated, cookieless signals
Conversion modelling quality	Lower	Higher
DPDP risk profile	Lower — no processing before consent	Higher — requires careful assessment

Advanced mode transmits cookieless pings before the user has decided. Google's position is that these pings contain no identifiers. Under the DPDP Act, the question is whether what is transmitted constitutes personal data — data about an identifiable individual. If it does not, the Act is not engaged. If your implementation passes anything that could re-identify a user — a hashed email from an enhanced-conversions setup, a user ID, a client ID tied to a logged-in session — it is engaged, and you have processed personal data before consent.

The defensible default for an India-focused site is Basic mode, moving to Advanced only after a documented assessment of what is actually transmitted pre-consent. Losing some conversion modelling accuracy is cheaper than arguing about pre-consent processing in front of the Board.

Implementation: Google Tag Manager

Step 1 — Set defaults before anything else fires

Consent defaults must execute before any Google tag. In GTM this means a Consent Initialization trigger, which fires ahead of All Pages. Everything defaults to denied:

gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  functionality_storage: 'denied',
  personalization_storage: 'denied',
  security_storage: 'granted',
  wait_for_update: 500
});

security_storage stays granted — it covers authentication and fraud prevention, which the DPDP Act treats as legitimate uses rather than consent-dependent processing. wait_for_update gives the consent platform time to restore a returning visitor's stored decision before tags evaluate.

Step 2 — Update on the user's actual decision

When the user makes a per-purpose choice, push the update. This is the point where the DPDP requirement for granular consent has to survive the translation into Google's four buckets:

gtag('consent', 'update', {
  analytics_storage: analyticsAccepted ? 'granted' : 'denied',
  ad_storage: marketingAccepted ? 'granted' : 'denied',
  ad_user_data: marketingAccepted ? 'granted' : 'denied',
  ad_personalization: marketingAccepted ? 'granted' : 'denied'
});

Note the failure mode hiding in that snippet: if your banner only offers one "Accept" button, analyticsAccepted and marketingAccepted are the same variable, and you have bundled purposes — which is exactly what the DPDP Act prohibits. The Consent Mode wiring is correct and the consent is invalid.

Step 3 — Set consent checks on your tags

In GTM, each tag has "Additional consent checks." GA4 tags should require analytics_storage; Google Ads conversion and remarketing tags should require ad_storage plus the v2 signals. Non-Google tags — Meta Pixel, LinkedIn Insight, Hotjar, Clarity — do not read Consent Mode at all and must be blocked with GTM triggers or by the consent platform directly.

Step 4 — Handle the returning visitor

A user who accepted analytics last week should not see the banner again, and their stored decision must be restored on page load, before tags evaluate. A user who withdrew consent must have that withdrawal restored just as reliably. Withdrawal that silently resets to the default on the next visit is the single most common defect we see in Indian implementations.

What Consent Mode Does Not Give You

Everything in this list is required by the DPDP Act and absent from Consent Mode:

• A consent record. Google does not keep evidence on your behalf. You need a timestamped, immutable record of which purposes a specific person consented to, against which version of the notice.
• An itemised notice. The user must see what is collected, why, and by whom — per purpose, before consenting. See our Rule 3 notice guide.
• Multilingual delivery. The notice must be available in English or any of the 22 Eighth Schedule languages, at the user's option.
• Withdrawal parity. Withdrawing must be as easy as granting. A banner with one-click Accept and a support-ticket withdrawal fails.
• Non-Google tag governance. Meta, LinkedIn, and session-recording tools are outside Consent Mode entirely and are frequently the bigger exposure.
• Rights handling. Access, correction, erasure, and grievance redressal for the data your analytics stack collected.

Server-Side Tagging Does Not Move the Obligation

A pattern we see increasingly in Indian implementations: move tagging server-side, and treat the consent problem as solved because the browser no longer sets third-party cookies directly.

It is not solved. Server-side tagging changes where the processing happens, not whether it happens. If your server forwards a user's identifiers to Google, Meta, or any analytics vendor without that user having consented, you have processed and disclosed personal data without a lawful basis. The DPDP Act attaches to the processing, not to the transport mechanism.

Server-side tagging is genuinely useful — it improves data quality, reduces client-side payload, and gives you a single control point for redaction. Use it, and make that control point enforce consent: the server container should check consent state before forwarding, and drop events for users who declined. Teams that skip this end up with a system that is technically cleaner and legally worse, because now the non-consented tracking is invisible in the browser's network tab.

Nine Defects We Find in Indian Implementations

From consent audits across Indian sites, ranked by how often they appear:

1. Tags fire before the banner is answered — GA4 and Meta Pixel already set cookies on first paint.
2. One Accept button covering all purposes — bundled consent, invalid under the Act.
3. Reject is harder than Accept — Accept is one click, refusing requires opening a second panel and toggling.
4. Withdrawal does not persist — the user withdraws, returns next week, and the default is restored.
5. No consent record — the site knows the current state but cannot prove what was agreed, when, against which notice.
6. Non-Google tags ungated — Consent Mode is wired correctly while LinkedIn Insight and a heatmap tool fire unconditionally.
7. English-only notice served to an audience that is majority non-English-reading.
8. Cookie list out of date — the banner declares six cookies; a scan finds twenty-two.
9. Consent state not sent to the backend — the frontend knows, the CRM and email platform do not, and marketing keeps sending.

The Pre-Consent Audit Nobody Runs

Before arguing about modes, find out what your site actually does today. Open a private window, load your homepage, and — without touching the banner — check the network tab and cookie store. On most Indian sites we scan, the results are: GA4 already set _ga, Meta Pixel already fired, a session-recording tool is already capturing, and two ad-network cookies nobody can account for are present.

That state is unlawful under the DPDP Act regardless of how the Consent Mode configuration reads, because processing began before consent. Automated scanning makes this repeatable — our guide to automating cookie scanning covers the mechanics, and the India cookie consent requirements guide covers what the banner itself must do.

Frequently Asked Questions

Is Google Consent Mode v2 mandatory in India?

Not by law, but effectively yes for advertisers. Google requires the v2 signals for remarketing audiences and conversion modelling features. Without them, those features degrade. It is a platform requirement rather than a DPDP Act requirement — the Act says nothing about Google's tags.

Does implementing Consent Mode v2 make my website DPDP compliant?

No. Consent Mode reads a consent decision and adjusts Google tag behaviour accordingly. The DPDP Act governs how that decision is obtained, presented, recorded, and withdrawn. You need an itemised per-purpose notice, granular choice, multilingual availability, easy withdrawal, and a durable consent record — none of which Consent Mode provides.

Should Indian websites use basic or advanced Consent Mode?

Basic mode is the lower-risk default because no Google tag fires before consent. Advanced mode sends cookieless pings pre-consent and gives better conversion modelling, but requires a documented assessment that nothing transmitted before consent constitutes personal data under the DPDP Act. If your setup uses enhanced conversions or passes user IDs, that assessment gets difficult.

What happens to my conversion tracking if users refuse consent?

In Basic mode, refused users are not measured at all. In Advanced mode, Google uses cookieless pings to model conversions in aggregate. Either way, expect measured conversions to fall — that gap is not a bug, it is the accurate picture of how many users actually agreed to be tracked.

Does Consent Mode cover Meta Pixel and LinkedIn tags?

No. Consent Mode is a Google-specific API. Non-Google tags must be blocked independently, either through GTM trigger conditions tied to your consent state or directly by the consent management platform. This is a frequent gap: the Google stack is properly gated while the Meta Pixel fires on page load regardless.

Do we need cookie consent for a purely informational website in India?

If the site sets any cookie beyond what is strictly necessary to deliver the page — analytics included — then yes, you are processing personal data and consent obligations apply. Strictly necessary cookies for security and session management fall under legitimate uses and do not require consent.

Where Consently Fits

Consently produces the consent decision that Consent Mode consumes — and keeps the evidence. Per-purpose consent capture, automated cookie scanning and classification, notices in all 22 Scheduled languages, one-click withdrawal with the withdrawal correctly restored on return visits, blocking for non-Google tags, and immutable zero-PII consent records with notice versioning. It emits the Consent Mode v2 signals natively, so the Google stack stays compliant with Google while the record-keeping stays compliant with Indian law. See it on your site.