India's DPDPA in Practice: The Consent Changes We Shipped on a Live Product Site

If your company is incorporated in India and processes the personal data of people in India, the DPDPA applies to you — regardless of where your servers are or whether you have a single European user. That is the sentence most Indian SaaS teams skip, because almost every consent article they read was written about GDPR.

We work on this from both sides. ZeengoCorp is a Gurugram-based venture studio, and one of our products — NoteVault — is a privacy app whose entire value proposition is that data never leaves the device. So when we added analytics to our own corporate site, we had to answer the question properly rather than copy a European banner.

This is what we changed, what it cost, and the two things that broke along the way.

What the DPDPA actually asks for

The Digital Personal Data Protection Act, 2023 makes a company that determines the purpose of processing a Data Fiduciary. If you run analytics on your own site, that is you. The obligations that matter for a web team are narrow and concrete: give clear notice, obtain consent that is free and specific, make withdrawal as easy as giving, and be able to demonstrate you did all three.

Notably, the Act does not care where your users are. It cares who you are and whose data you process.

Where teams get it wrong

The most common mistake is treating DPDPA as "GDPR, but India" and applying one global rule. The two laws differ in ways that change the engineering:

Dimension	GDPR (EEA/UK)	DPDPA (India)
Trigger	Where the user is	Who the fiduciary is, and whose data
Legal bases	Six, incl. legitimate interest	Consent-led, narrower exemptions
Consent standard	Freely given, specific, informed	Free, specific, informed, unconditional
Withdrawal	Must be as easy as giving	Must be as easy as giving
Enforcement	DPAs per member state	Data Protection Board of India
Penalty ceiling	4% global turnover	Up to ₹250 crore per breach type

The practical consequence: an Indian company serving mostly Indian users cannot rely on a banner shown only to Europeans. That is the exact gap we found in our own first implementation.

What we shipped

1. Consent Mode v2 defaults, before anything else loads

The single most common implementation bug is loading the analytics tag first and the consent defaults second. If defaults land after the measurement snippet, the first pageview has already been sent under the wrong assumption and the default is decorative.

Ours runs at the earliest possible point in the document, ahead of both Google Analytics and session replay. It also declares the v2 signals — ad_user_data and ad_personalization — which have been required since March 2024 and which a surprising number of sites still omit.

2. Region-scoped defaults, not a blanket deny

A global default-deny sounds safest and is usually wrong. Our Search Console data shows traffic is overwhelmingly India and the United States, with the EEA a long tail. Denying storage worldwide would apply an EEA rule to markets that generate most of the traffic, fragment sessions, and destroy analytics continuity — for no compliance benefit in jurisdictions that do not require it.

Consent Mode's region parameter exists precisely for this. We deny by default across the EEA, UK, Switzerland and India, and grant elsewhere. Google enforces the list server-side from the request IP.

The India entry is the part most implementations miss.

3. The banner gates something real

Adding India to the banner but leaving analytics storage granted there would have been the worst of both worlds: the UX cost of a prompt with none of the compliance benefit. If you ask for permission, the default has to actually withhold something until the answer arrives.

Stated plainly, that has a cost. Until an Indian visitor accepts, those sessions are cookieless pings that GA4 models rather than measures directly. We accepted that trade because the alternative is a banner that lies.

4. Session replay waits for consent

We use Microsoft Clarity for heatmaps and replay. Loading it unconditionally is tempting because its own regional gate handles the EEA. We gated it on our consent state anyway, for a reason we could measure.

The measured cost of doing it properly

Numbers from Lighthouse against production, throttled mobile:

Change	Metric	Before	After
Session replay always on	Best Practices	96	73
Replay gated behind consent	Best Practices	73	96
Third-party cookies audit	Pass/fail	fail	pass
Consent defaults added	Cumulative Layout Shift	0	0
Consent defaults added	Total Blocking Time	140ms	180ms

Clarity sets third-party cookies on its own domain and syncs identifiers to Bing. That trips Lighthouse's third-party-cookies audit, which carries the heaviest weight in the Best Practices category — a 23-point swing from one tag. Gating it fixed the score and the compliance question in the same change.

The honest trade: replay now covers a consenting subset rather than everyone, so session volume is lower. Once a banner exists, that is the correct outcome.

Two bugs worth knowing about

A hoisted function silently discarded every consent call. Google's standard analytics snippet declares gtag with a function declaration. Function declarations hoist. If your consent defaults created their own gtag first, the analytics snippet's version overwrites it and throws away every queued consent instruction — reverting all defaults to granted, silently, with no error. Assigning conditionally instead of declaring fixes it.

A geo heuristic is not a compliance mechanism. We show the banner based on the browser's timezone rather than an IP lookup, because a geolocation request on first paint would slow every visitor worldwide to serve a prompt a minority need. But the timezone is only deciding whether to show a banner. The actual enforcement is Consent Mode's region list, which Google applies server-side. If the heuristic is ever wrong, storage stays denied for real Indian and European visitors and the banner simply does not appear. The failure mode is less tracking, never tracking without consent. Build it so the cheap check can fail safely.

A short checklist

1. Load consent defaults before every measurement tag, not after.
2. Include the v2 signals; omitting them degrades measurement even where consent is granted.
3. Add IN to your region list if you are an Indian entity — not just the EEA.
4. Make sure the default actually withholds something, or the banner is theatre.
5. Gate cookie-setting third parties like session replay on the same decision.
6. Make withdrawal as easy as granting; the Act is explicit about this.
7. Measure the performance cost. If it is large, that is information, not an argument against compliance.

Frequently asked questions

Does the DPDPA apply if all my users are outside India? The Act governs digital personal data processed in India, and processing outside India where goods or services are offered to people in India. An Indian company processing Indian users' data is squarely in scope. If you genuinely have no Indian users and no Indian processing, your exposure is different — but for most Indian startups the honest answer is yes.

Is a cookie banner legally required by the DPDPA? The Act requires notice and consent for processing personal data, not a banner specifically. A banner is the common mechanism for analytics because analytics identifiers are personal data. What matters is that notice is clear, consent is genuine, and withdrawal is as easy as granting.

Can I show one banner globally and be done? You can, and it is the simplest position to defend. The cost is friction for users in jurisdictions that do not require it. We chose region-scoping because our traffic distribution made a global banner expensive, but a single global prompt is a legitimate choice.

Does denying analytics storage mean losing the data entirely? No. With Consent Mode, denied traffic still sends cookieless pings and Google models the gap. You lose user-level precision, not the whole signal. Treat modelled data as directional.

How does this affect Core Web Vitals? Consent defaults themselves are negligible — a small inline script. The cost comes from the tags they gate. In our case, deferring analytics and gating session replay improved Best Practices by 23 points and left Cumulative Layout Shift at zero.

Related reading

• How ZeengoCorp built DialMaster — engineering decisions on our B2B product
• NoteVault: hidden file locker for Android — privacy architecture with zero cloud sync
• About ZeengoCorp — how the studio operates
• Contact us — questions on any of the above

Written from a live implementation on this site in August 2026. Nothing here is legal advice; talk to counsel about your own obligations.