I get asked two versions of the same question. Do Indian sites need Consent Mode v2? And what does the DPDP Act mean for our tracking? They are related but different. Consent Mode is a Google technical framework that adjusts how tags behave based on a user's consent choices. The Digital Personal Data Protection Act, 2023 is Indian law about how organisations collect and use personal data, with Rules notified in November 2025 and phased in over eighteen months. This article explains both from a marketing operations point of view and what I set up for Indian clients. It is not legal advice: for your specific obligations, talk to a lawyer who works on data protection.
What Consent Mode v2 actually is
Consent Mode is a way for your site to tell Google's tags what the visitor has agreed to. It uses consent states, set to granted or denied: analytics_storage and ad_storage, which control whether cookies are used for analytics and advertising, and two parameters added in version 2, ad_user_data, which governs whether user data can be sent to Google for advertising, and ad_personalization, which governs remarketing and personalised ads. Your consent banner or consent management platform sets these states, and Google tags adjust. In basic mode, tags do not load at all until consent is given. In advanced mode, tags load but send cookieless pings when consent is denied, which Google uses for conversion modelling. Google made Consent Mode v2 a requirement for advertisers who use its measurement and remarketing features with users in the European Economic Area, and its EU user consent policy also covers the UK and Switzerland. Google has not imposed the same requirement for Indian traffic. So for a site that serves only Indian users, Consent Mode v2 is not a Google mandate today.
What the DPDP Act asks for, at a high level
The DPDP Act sets out how a data fiduciary, the business deciding why and how personal data is processed, may handle the digital personal data of individuals in India. At a high level, it requires a lawful basis for processing, primarily consent that is free, specific, informed and unambiguous, given through a clear affirmative action. It requires a notice explaining what data is collected and for what purpose. It gives individuals rights to access, correct and erase their data and to withdraw consent as easily as they gave it. It places duties on businesses around security safeguards, breach notification and retention. The DPDP Rules, 2025, notified by the government in November 2025, phase these obligations in: some provisions took effect on notification, the consent manager framework follows after a year, and the bulk of substantive obligations apply eighteen months after notification, which puts it around May 2027. Penalties under the Act can be significant. Exactly how each provision applies to cookies, pixels and ad tracking is something to confirm with counsel, but the direction is clear: personal data used for marketing needs informed, recorded, withdrawable consent.
Where marketing tracking touches the DPDP Act
Most of what a performance marketing stack does involves personal data. Lead forms collect names, phone numbers and emails. Meta Conversions API and Google enhanced conversions send hashed emails and phone numbers to the ad platforms. Remarketing audiences are built from site visitors and customer lists. CRM integrations move this data between systems, and WhatsApp marketing uses phone numbers for outreach. Hashing does not, by itself, take data outside the scope of a privacy law, so I treat hashed identifiers as personal data for planning purposes. That means the consent question is not only about a cookie banner. It is also about the consent language on lead forms and checkouts, whether customers agreed to their data being used for advertising and shared with platforms, how you honour withdrawal across the CRM and ad audiences, and how long you keep leads that never converted. These are operational questions, and they fall to whoever owns the marketing stack as much as to legal.
Why I wire Consent Mode in for Indian sites anyway
Even without a Google mandate for India, I set up a consent banner with Consent Mode v2 for most Indian clients for three practical reasons. First, many Indian brands serve some users in the UK, Europe or elsewhere, and if any of those users see your ads or remarketing, Google's EU consent policy applies to them. A geo-aware consent setup handles that cleanly. Second, once DPDP obligations are in force, you will need a mechanism to capture, record and honour consent choices. Building that into the tag layer now, while the stakes are lower, is cheaper than retrofitting it. Third, Consent Mode is the plumbing that connects consent decisions to tag behaviour. If a visitor declines advertising, ad_user_data and ad_personalization set to denied stop Google tags from using their data for ads. Equivalent logic in server-side GTM can stop Meta CAPI events from carrying their identifiers. Without that plumbing, a consent banner is decoration.
What I set up, step by step
The build is the same shape for most clients. Choose a consent management platform that supports Consent Mode v2 through Google's CMP integration, supports regional rules so EEA and UK visitors get an opt-in banner, and keeps consent records with timestamps. Configure default consent states in Google Tag Manager before any tags fire, region by region. Map each tag to the consent it needs: GA4 to analytics_storage, Google Ads and Floodlight to ad_storage and ad_user_data, Meta and other ad pixels to the advertising category. Pass consent state to the server container so server-side events respect it, including Meta Conversions API, which has no native Consent Mode equivalent and needs explicit logic. Update lead forms and checkout with clear notice text and, where appropriate, a separate opt-in for marketing communications. Finally, document the data flows: which systems receive which personal data, for what purpose, and how a withdrawal request propagates. That document is useful for your lawyer and indispensable for whoever maintains the stack after me.
What this does to your numbers
Any consent setup that actually blocks tags when consent is denied will reduce the data reaching analytics and ad platforms for those visitors. In advanced Consent Mode, Google uses cookieless pings and modelling to estimate some of the missing conversions in GA4 and Google Ads, though modelling has eligibility thresholds and is not a full replacement. Meta has its own approaches for measurement without full identifiers. The practical response is to strengthen the signal you do have: server-side tagging for consented users, enhanced conversions and CAPI with good match quality, offline conversion imports from the CRM for leads who gave consent at the form stage, and first-party data that customers knowingly shared. I would rather plan for slightly less data that is clean and defensible than build a growth model on tracking that may need to be switched off at short notice. Again, none of this is legal advice. It is the operational groundwork that makes whatever your counsel recommends quick to implement.
FAQ
Google's Consent Mode v2 requirement applies to users in the EEA, and its EU user consent policy covers the UK and Switzerland. It is not a Google requirement for Indian traffic. Indian sites that reach users in those regions should implement it for that traffic.
The Act requires notice and consent for processing digital personal data, with obligations phasing in under the DPDP Rules through around May 2027. How that applies to cookies and pixels on your site is a question for a data protection lawyer. This article is not legal advice.
They send hashed personal data such as emails and phone numbers to ad platforms, so I plan as if consent for advertising use is needed and build consent checks into the server container. Confirm the specific requirements for your business with counsel.