What Indian law asks for, and what it doesn't
The banner is a European object. It exists because EU rules require consent before storing or accessing information on a user's device — a rule written about the device, which is why it catches cookies specifically and why the resulting dialog talks about cookie categories rather than about you.
India's Digital Personal Data Protection Act is framed differently. It is a notice-and-consent regime for the processing of personal data: tell the person what you are collecting and why, get consent that is free, specific and informed, and give them a way to withdraw it as easily as they gave it. Nothing in that framing turns on whether the storage mechanism happens to be a cookie. Its rules commence in phases, and the date any particular obligation bites for your business is a question for counsel rather than for your SEO agency.
There is an older layer too. The IT Act's rules on sensitive personal data have applied for years to a narrow list — financial information, health data, biometrics and similar. A first-party analytics cookie is not on that list. A lending form is a different matter entirely.
So the honest summary is: the obligation is real, the banner is one possible implementation of it, and importing a European dialog wholesale gives you the costs of the European rule without the parts that would have protected you.
Who plausibly needs one, and who is copying a competitor
Work out which row you are in before you install anything. The commonest mistake we see on Indian sites is a full EU-style consent wall on a business with no European visitors, no ad personalisation and no privacy policy behind the banner it just deployed.
| Your situation | Banner needed | Why |
|---|---|---|
| You sell to or market at visitors in the EEA or UK | Yes | European rules follow the visitor, not the server. Google's own EU user consent policy separately requires publishers and advertisers to obtain valid consent for cookies and ad personalisation for those users. |
| You run remarketing, a Meta pixel or ad personalisation anywhere | Usually yes | Advertising identifiers are what platforms and regulators care about most, and platform policies bind you contractually whatever your jurisdiction says. |
| India-only D2C brand running GA4 and nothing else | A clear notice, not a wall | Under notice and consent the duty is to say plainly what you collect and why and offer withdrawal. A blocking modal is one way to do that, not the requirement itself. |
| Local service business with a phone number and a contact form | Fix the form first | The form is where you actually collect personal data. Purpose, retention period and a named contact matter far more than a cookie dialog. |
| Healthcare, lending, insurance, anything with sensitive data | Yes, and take advice | Sensitive categories carry their own older obligations and much higher consequences. This is not a plugin decision. |
| You installed one because a competitor had one | No | You have imported a foreign rule, kept every bit of its cost, and gained none of the protection it was written to provide. |
What a banner actually costs you, in numbers you can check
Here is the part nobody selling you a consent platform will state clearly. A compliant banner removes a visible slice of your measured conversions, permanently, and that slice does not come back. Not the conversions — the *measurement* of them. The sales still happen. Your analytics stops seeing them.
The size of the loss is your denial rate, and it is genuinely unpredictable in advance. It moves with banner design, wording, placement, device mix and how much your audience has been trained to click reject. Published denial rates range so widely that quoting one at you would be worse than useless, so we don't. You measure your own, and you can only measure it after deployment.
Two mechanisms decide how much of the loss you can recover. The first is consent mode: in advanced mode tags still load with consent defaulted to denied and send cookieless measurements, so some signal survives a rejection. In basic mode tags do not load at all until the user interacts, and a rejection produces silence.
The second is modelling, and this is where most Indian SMB sites discover they are on the wrong side of a threshold. Google requires at least 1,000 events per day with analytics_storage set to denied for seven days, plus 1,000 daily users granting consent on seven of the previous 28 days, before behavioural modelling will run on a property. A site doing 20,000 sessions a month clears neither number. It simply loses the data.
- Freeze a clean two-week window before deployment. Without it you can never separate the banner's effect from everything else that happened that month.
- The gap between Search Console clicks and GA4 sessions is your cheapest ongoing check. The two tools never match anyway, so watch the size of the gap changing rather than the numbers themselves.
- Expect the loss to be uneven. Direct and branded traffic tends to consent at a different rate from cold organic, so your channel mix will appear to shift when nothing has actually moved.
| What you were reading | What happens on day one | Can you recover it |
|---|---|---|
| GA4 sessions and users | Drops by roughly your denial rate | Only above the modelling thresholds; otherwise no |
| Goal and conversion counts | Drops by the same proportion, unevenly across channels | Partly, with advanced consent mode and server-side collection |
| Search Console clicks and impressions | Unchanged — it counts on Google's side of the click | Not affected, which is why it becomes your anchor |
| Ad platform conversion counts | Drops, and bidding degrades with it | Partly, via consent mode and offline conversion imports |
| CRM records and phone or WhatsApp enquiries | Unchanged, because they never depended on a cookie | Yes — this is the number to move your reporting onto |
Implementation choices that lose the least data while staying honest
There is a wide, legitimate range between a banner that consents nobody and a dark pattern with a hidden reject button. Aim for the honest end of it — a dishonest banner gives you bad data *and* no defence, which is the worst of both.
These are the decisions that actually move the number, roughly in order of impact.
- Advanced consent mode over basic. Tags load with consent denied by default and send cookieless signals, so conversion modelling and ad platform bidding keep some input. Basic mode is simpler and blinder.
- Ask once, ask clearly, and make reject one click. Two-click rejects raise your consent rate on paper and hollow out the consent itself. If the point is a defensible record, a coerced yes is not one.
- Reserve the space. A banner injected after the page renders shoves the content down and shows up as layout shift in your field data. Give it a fixed slot from first paint.
- Do not build it as a full-screen mobile modal over your main content. Legal notices are broadly accepted at a reasonable size, but a full-screen overlay hurts your largest contentful paint, annoys the visitor, and consents nobody honestly.
- Load the consent script asynchronously, and prefer one that does not add a render-blocking third-party request on the critical path. Most consent platforms are heavier than the analytics they gate.
- Never serve full content to crawlers and a wall to people. Showing Googlebot something you hide from users is cloaking, and it is a far bigger risk than the data you were trying to protect.
- Keep the consent log. A banner with no record of who consented to what, and no working withdrawal route, is theatre with a cost attached.
How we re-baseline the guarantee when a banner goes live
We should be explicit about this, because it is a conflict of interest we would rather name than have discovered.
Our whole engagement is judged against one number: your trailing-90-day qualified leads from organic search, frozen on day one. A consent banner deployed in month four changes the instrument, not the performance. Left alone, it would make an agency look worse for a compliance decision the client made and we had no business influencing.
So the rule is fixed in advance. When a client deploys a banner mid-engagement, we re-freeze the baseline using the first full 30 days after it goes live, and we move the reported number onto a source the banner does not touch — CRM records, call and WhatsApp logs, and self-reported attribution on the form. We write down which we did and why, before the next report, not after the numbers land.
The rule cuts both ways, which is the only thing that makes it worth anything. If leads genuinely fell that quarter, a banner does not cover it, and we do not get to hide a bad quarter behind a measurement change. Same rule, both directions. That is what the guarantee on our SEO work is actually made of.
If you want the general version of setting a number before work starts, how to set an SEO baseline covers it without the privacy complication.
What a banner does not do
The last failure mode is the most common one: the banner goes up, and everyone treats compliance as finished. It isn't, and the parts left undone are the parts that actually carry risk.
- It does not write your privacy notice, and a banner linking to a page that does not exist is worse than no banner.
- It does not set retention periods, decide who inside your company can see the data, or stop your CRM syncing it to four vendors you have never audited.
- It does not cover the WhatsApp number on your contact page, the enquiry spreadsheet on somebody's laptop, or the lead list your sales team exported last March.
- It does not handle withdrawal, correction or deletion requests, which is the operational work that follows consent and the part nobody budgets for.
- It does not make your ad platform pixels compliant on its own — the tags have to actually respect the choice, and a surprising number of installations never wire that up.