At a glance
The DPDP Act doesn’t name cookies specifically, but cookies and similar tracking identifiers linkable to an individual are treated as personal data — so non-essential tracking cookies (analytics, ad targeting, retargeting pixels) need real, opt-in consent before they fire, not a banner that’s technically present but pre-ticked or ignorable. Strictly necessary cookies (keeping a cart working, basic site function) have a stronger case for running without a separate consent step, under the legitimate-use logic. That distinction is where most agencies’ current setups fall short.
Educational resource only. This explains how the consent requirement under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) applies to cookies and tracking pixels for marketing agencies; it is not formal legal advice. The Act has no dedicated cookie-law provision the way the EU’s ePrivacy rules do, so this is an evolving, interpreted area — re-check current guidance periodically.
The situation
India doesn’t have a dedicated cookie law the way the EU has its ePrivacy rules — so a lot of agencies have treated cookie banners as a nice-to-have or a copy-paste from a global template, without asking whether the DPDP Act actually requires anything of them. It does, once cookies are read for what they technically are.
Are cookies “personal data” under DPDP?
Generally, yes — a cookie or tracking identifier that can be linked back to an individual falls within personal data, even without a name attached. The DPDP Act defines personal data broadly around anything that relates to an identifiable individual. A tracking cookie, device identifier or pixel that lets a business recognise the same visitor across sessions and build a profile of their behaviour fits that definition in practitioner reading of the Act, even though the Act doesn’t use the word “cookie” anywhere in its text. That reading — not an explicit cookie clause — is what pulls tracking cookies into the Act’s consent framework.
Essential vs non-essential cookies
The two categories land on different sides of the consent line.
- Strictly necessary cookies — the ones that make the site actually work (keeping a shopping cart intact, remembering a login session, basic load-balancing) — have the stronger case for running as a legitimate use, without a separate opt-in, since the site can’t function as requested without them.
- Non-essential cookies — analytics, advertising and retargeting pixels, third-party ad-network tags — don’t have that same functional necessity. These are the ones that need a genuine opt-in before they fire, because their purpose is measurement and targeting, not making the page work.
What real consent for tracking cookies looks like
The design failure mode is the same one the DPDP Act calls out everywhere else: a banner that exists but doesn’t actually ask. A cookie notice that loads tracking scripts before the visitor responds, or that only offers “Accept All” with no equivalent “Reject” option, isn’t consent under the Act’s free/specific/informed/unambiguous standard — it’s the same pre-ticked-box problem the Act is written against generally. A defensible setup:
- Blocks non-essential cookies until the visitor actively opts in — not “loads everything, asks permission after.”
- Offers a real choice, not just an “Accept” button with no equally easy “Reject” or “Manage preferences” option.
- Lets categories be chosen separately where practical (analytics vs. advertising) rather than one bundled yes/no.
- Makes withdrawal as easy as consent — a visitor who opts in today should be able to turn tracking off later without hunting for a settings page.
What agencies should actually build
- Audit what’s actually firing — many sites run tracking scripts the marketing team didn’t explicitly commission (a leftover pixel, an old integration); know the real list before designing consent around it.
- Separate essential from non-essential in the consent tooling, not just in an internal document.
- Gate non-essential scripts behind the opt-in technically, not just present a banner while scripts load regardless.
- Update the privacy notice to name the categories of cookies used, what each does, and how long they persist.
- Build the withdrawal path into the same interface, not a separate support-ticket process.
First-party vs third-party cookies
The distinction matters for risk, not for whether consent is needed — a first-party analytics cookie and a third-party ad-network cookie both need real opt-in if they’re non-essential, but the third-party version carries a bigger governance problem. A first-party cookie is set by the site the visitor is actually on, and its data typically stays with that one business. A third-party cookie — set by an ad network, a social-media pixel, or an analytics vendor embedded across many unrelated sites — lets that third party build a profile of the same visitor across every site carrying its tag, which is a wider footprint than the visitor consenting on any single site would reasonably expect. Practically, that means a third-party tracking tag deserves its own named line in the consent interface (“this site shares data with [ad network] for retargeting”), not a generic “we use cookies” statement that doesn’t tell the visitor which company actually receives their data.
Retargeting pixels and ad-network tags
A retargeting pixel is functionally the same consent problem as a tracking cookie, just delivered differently — and agencies often treat it as a separate, lower-scrutiny category by habit, which doesn’t hold up. Facebook/Meta pixels, Google Ads conversion tags, and similar retargeting scripts read and write tracking identifiers the same way a cookie does, specifically to build audiences for ad targeting — squarely in the “non-essential, needs consent” category, not a special exception because it’s called a pixel instead of a cookie. Agencies running retargeting campaigns for clients should treat pixel consent with the same rigor as cookie consent: gated behind the same opt-in, named in the same notice, and — importantly — actually disabled client-side when a visitor declines, not just excluded from a report while still firing in the background.
Consent management platforms: build it or buy it?
A dedicated consent management platform (CMP) handles the gating, categorisation and withdrawal mechanics that are genuinely hard to build reliably from scratch — for an agency running consent across many client sites, that reliability is usually worth the cost. A CMP sits between the visitor and the site’s tracking scripts, blocking non-essential ones until consent is actually given, remembering the visitor’s choice, and exposing a “manage preferences” option that satisfies the withdrawal requirement without custom engineering per client. Building the equivalent in-house is possible but easy to get subtly wrong — a script that fires a fraction of a second before the gate, or a “reject” button that doesn’t actually stop server-side tracking — which is exactly where most non-compliant setups this piece has flagged actually go wrong. For an agency managing consent across a portfolio of client sites rather than one, a CMP’s centralised configuration and audit trail is the more defensible and more scalable choice over rolling a bespoke banner per site.
FAQ
Does the DPDP Act have a specific law about cookies, like the EU’s ePrivacy Directive?
No — the Act doesn’t mention cookies by name. The consent requirement for tracking cookies comes from reading them as personal data under the Act’s general definition, which is the interpretation most practitioners currently apply.
Can a website run analytics cookies without asking for consent?
Analytics cookies used for tracking and profiling generally need consent — they’re not typically “strictly necessary” for the site to function, which is the bar for running without a separate opt-in.
Is a cookie banner that only has an “Accept All” button compliant?
It’s a weak position — the Act’s consent standard expects a genuine, unambiguous choice, and an interface that makes “no” harder to find than “yes” mirrors the same pre-ticked-box problem the Act targets elsewhere.
Do agencies need to change existing client sites, or just new builds?
The consent requirement applies to how the cookies function regardless of when the site was built — an older site running non-essential tracking without real opt-in carries the same gap as a new one.
Are retargeting pixels (Meta, Google Ads) treated differently from cookies?
No — they raise the same consent question and belong in the same non-essential, opt-in-gated category, even though they’re not technically called cookies.
Is it worth using a consent management platform instead of building a custom banner?
For an agency managing consent across multiple client sites, generally yes — a CMP handles the gating and withdrawal mechanics reliably, which is easy to get subtly wrong in a custom build.