Start with scope, not with a banner
Almost everything written about this in India is European material with the nouns swapped, and the swap breaks in two specific places worth knowing before you spend a rupee.
First, the EU's cookie banner does not come from GDPR. It comes from a separate rule that makes storing or reading information on a user's device the thing requiring consent. India has no equivalent. Under the DPDP Act the trigger is processing personal data, so the question is never "is this a cookie" but "does this identify a person". A first-party cookie holding a random string that never links to anything is a much weaker case than the same cookie joined to a logged-in account.
Second, GDPR gives you legitimate interests as a lawful basis, which is what most European analytics arguments actually rest on. The Act gives you consent, plus a short closed list of legitimate uses — medical emergencies, state functions, employment purposes and similar. Website analytics is not on that list and cannot be argued onto it. That is a real difference and it runs the opposite way to what most imported guidance implies.
The Act applies to digital personal data processed within India, and to processing outside India that relates to offering goods or services to people in India. So a Bangalore D2C brand is in scope, and so is the US-hosted analytics stack it uses. It does not apply to personal data an individual has themselves made public, or to purely personal or domestic processing — neither of which describes your site.
What in a standard setup is personal data, and what isn't
The Act defines personal data as any data about an individual who is identifiable by or in relation to that data. No name required — the test is whether you can single someone out. Run your own stack against this list before anyone sells you a compliance project.
| What you collect | Personal data? | Why |
|---|---|---|
GA4 client ID (the _ga cookie) | Treat as yes | A persistent identifier that lets you follow one visitor across sessions. Singling out is the test, not naming. |
| Visitor IP address | Treat as yes | Google's commitment not to log or store individual IPs is scoped to EU, Switzerland and UK traffic. Indian traffic is outside that scope. |
| User ID you send after login | Yes | It is your own key back to a named account in your CRM. The least arguable item here. |
gclid, ad cookies, remarketing audiences | Treat as yes | These exist to attribute a conversion to a person rather than a page, and to follow that person elsewhere. |
| Form submissions and lead exports | Yes, unambiguously | Name, phone, email. The item that actually matters and the one privacy projects usually skip. |
| Session recordings and heatmaps | Yes, often sensitive | A replay of somebody typing into your checkout is about as identifiable as data gets. |
| Sessions, users, bounce rate, average position | No | Nobody is identifiable in a count. Search Console query data is aggregated and thresholded before you see it. |
Notice and consent before the tag fires, in plain terms
Strip the legalese and there are three requirements. A notice, given before or alongside the request, saying what personal data you're processing and for what purpose, how the person can exercise their rights, and how they can complain to the Data Protection Board. Consent that is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, and limited to the data actually needed for that purpose. And withdrawal that is as easy as giving it was.
Translated into a tag setup:
- Essential first-party measurement can fire on load — the things your site needs to work and to count page views without following anyone across sites. Non-essential tags should wait.
- Advertising, remarketing and cross-site identifiers wait for consent. These are the tags with the clearest link to an identified individual and the weakest argument for necessity.
- Pre-ticked boxes and implied consent by scrolling are not clear affirmative action. Nor is a banner with only an accept button.
- Withdrawal has to be reachable. A persistent link in the footer that reopens the choice is the low-effort implementation, and it also satisfies the "as easy as giving" requirement.
- Bundled consent fails. Consent has to be limited to the specified purpose, so one checkbox covering analytics, ads, WhatsApp marketing and profile enrichment is the wrong shape.
- Google's consent mode is the plumbing, not the policy. It sets
analytics_storage,ad_storage,ad_user_dataandad_personalizationstates so tags behave according to the choice. It does not decide what your default should be — you do, with counsel.
The over-compliance that costs data and buys nothing
We have a direct stake in this. We're judged contractually on numbers that come out of these tools, so we watch clients destroy their own measurement in the name of a risk they haven't assessed. These are the five we see most, in rough order of damage.
None of these is a legal opinion. Each is a measurement cost with no matching compliance benefit.
- Dropping GA4 retention to two months. It doesn't reduce your exposure — the setting governs user- and event-level data used in explorations, and aggregate reports are unaffected either way. What it does is remove your ability to run a year-on-year path analysis. Fourteen months is the usual right answer, chosen deliberately.
- Deleting historical data "to be safe". You delete your baseline. Every measurement of whether anything worked afterwards is now an opinion. If a specific field has to go, delete that field.
- Blocking analytics entirely and falling back on server logs. Server logs contain full IP addresses and user agents. You swapped a documented, controllable pipeline for an undocumented one and called it caution.
- Cookie walls that block the page until the visitor accepts. Consent has to be free and unconditional, which sits badly with pay-with-your-data. It is also a conversion disaster on Indian mobile traffic.
- Turning off granular location and device data across the board while the lead form still posts unencrypted to a shared inbox. This is the pattern in miniature: the fix lands where it's easy, not where the personal data is.
What it does to your reporting, and to any number you're judged on
This is the part nobody warns founders about, and it matters more than the banner design.
Once a consent choice exists, some visitors decline, and the tags that would have measured them don't fire. Your analytics stops being a census and becomes a sample with an unknown response rate. Google's consent mode fills part of that hole with modelled numbers — estimates, clearly, and better than a hole, but not observations. Meanwhile the platforms keep reporting conversions their own way, so your GA4 total, your Ads total and your CRM count drift further apart than they already did.
Three practical consequences:
- Deploying consent management breaks your baseline. Organic sessions can drop overnight with no change in actual visits. Either freeze the baseline before you deploy, or re-baseline immediately after — and write down which you did, with the date.
- Year-on-year comparisons across the deployment date are not comparisons. Say so in the report rather than explaining it in month nine.
- Guarantees have to be written against a number that survives. Ours is your trailing-90-day count of qualified leads from organic search, taken from your CRM, frozen on day one. We use the CRM deliberately: it is the one system whose count doesn't move when a tag stops firing. Beat it in 90 days or we keep working free until we do — and that only means anything if the number is stable. How we set a baseline has the full method.
Where to get actual legal advice, and why this page is not it
We are a marketing agency. What we can tell you is what these tools collect, which of the standard fixes destroy data, and what happens to your reporting — because we do this every week and we carry a commercial commitment on the output. What we cannot tell you is whether your specific processing is lawful.
Brief an Indian data-protection lawyer if any of these apply: you process data about children, you're in a regulated sector with its own rules on top, you transfer personal data outside India, you're large enough to be notified as a Significant Data Fiduciary, or you're relying on anything other than consent. Those are the cases where the answer is genuinely specific to you and where guessing is expensive.
Two other things worth knowing. The Act delegates most operational detail — notification formats, retention periods for particular classes of fiduciary, consent-manager registration — to rules made under it, and those rules are where a real deadline lives. Ask for the current text rather than a summary. And treat anyone selling you a fixed compliance package with no discussion of what you actually collect as selling a banner, which is the cheapest and least useful part of this.
In the meantime the highest-value work is unglamorous and free: stop collecting fields you never use, get email addresses out of your URLs, and write down who can reach your lead data. That's most of the risk, and none of it requires a project.