Sec. 6(1) · Rule 3
AvailableThe tags stay off until someone says yes
Most banners record a preference while the tags fire anyway. That is the first thing an auditor checks, and it is the difference between a consent and a note about one.
- Requests before consent
- 0
- Prior blocking
- Gzipped, no framework
- 6 KB
- First-party
- Notice languages
- 22
- Eighth Schedule
- Google Consent Mode
- v2
- Signals
For whoever owns the website. Usually marketing, and usually surprised the tags are the problem.
Before you decide
- googletagmanager.com — 0 requests
- _ga — not set
- _ga_<id> — not set
After you accept analytics
- googletagmanager.com — 1 request
- Consent Mode — analytics_storage granted
- Withdraw from the footer — identifiers cleared
Open your network panel, filter for googletagmanager, and reload. Nothing. Accept analytics in the banner and one request appears. The Cookie preferences link in the footer takes it back.
The left column is what most Indian sites run today, including sites that already added a banner.
| Area | A banner that records | Prior blocking |
|---|---|---|
| Analytics requests before a decision | Fire on page load | None |
| Where the banner script is served from | A third-party CDN | Your own domain |
| Refusing | Buried under Manage preferences | One button, equal weight |
| Withdrawing later | Clear your cookies | A link in the footer |
| What is recorded | A preference, after the fact | A receipt, before the tag |
Four things a banner has to get right
- Sec. 6(1)
Prior blocking, measured at the network layer
A tag is not registered and released — it is never fetched. Scripts ship as type="text/plain" with a data-category and are promoted only on grant, so an undecided visitor is treated exactly like one who refused. The test asserts zero requests, because reading a cookie value afterwards proves nothing about what already left the page.
- Rule 3
A notice, not a interstitial
It says which purposes exist, what each one collects and how long it keeps it, in the notice itself rather than behind a link. Available in the 22 scheduled languages, because a notice a person cannot read has not informed anybody.
- Sec. 6(1)
Nothing pre-ticked, and no weighted buttons
Accept and Reject are the same size, the same colour weight and the same number of clicks. This is the provision most banners fail on, and they fail it in the CSS rather than the logic.
- Sec. 6(4)
Withdrawal from every page
A footer link on every page reopens the choice, and switching a purpose off signals Consent Mode and clears the identifiers already set. Withdrawal has to be as easy as granting was; a preference you can only change by clearing site data is not.
A banner is not compliance
It covers one surface. The consent a person gives here has to reach the systems behind the website, and the purposes offered here have to be the same purposes recorded everywhere else — which is the job of the Consent Manager, not of a script in the page. A site with a perfect banner and a CRM that never hears about a withdrawal has moved the failure, not fixed it.
Questions people ask
- Does the DPDP Act require a cookie banner?
- Not in those words. The Act has no cookie provision and no equivalent of the ePrivacy Directive's Article 5(3), so anyone telling you "the DPDP Act mandates a cookie banner" is selling past it. What the Act does require is a valid consent under Sec. 6(1) — free, specific, informed, unconditional, unambiguous, by clear affirmative action — before personal data is processed. An analytics or advertising tag that assigns an identifier to a browser is processing personal data. A banner is how you obtain that consent on a website; it is a consequence of Sec. 6(1), not a rule of its own.
- What counts as prior blocking, and why does it matter more than the banner?
- Prior blocking means the tag does not load until consent is granted — not that it loads with a flag set to denied, and not that the cookie is deleted afterwards. It matters because it is the only version that is true at the network layer: by the time a third-party script has been fetched, the request carrying the visitor's IP address and page URL has already been made. A banner over a page that is already tracking is a record of a preference, not a consent.
- Can I see it working rather than take your word for it?
- Yes, on this page. Open your browser's network panel, reload, and filter for googletagmanager — you will see nothing until you accept analytics in the banner at the bottom of this site. Accept, and one request appears. Use the Cookie preferences link in the footer to withdraw, and the identifiers are cleared. This site runs the module it is selling; that is the demo.
- Does it work with Google Consent Mode and Google Tag Manager?
- Yes. Consent Mode v2 defaults are declared denied ahead of any tag, and a grant sends the update. That is the part Google needs. It is deliberately not the whole mechanism — Consent Mode alone still loads the Google script before a decision, which is why the tag is withheld as well.
- Where is the banner script served from?
- Your own domain. It ships with the platform and is served first-party, so there is no third-party request to make consent work, nothing for tracking protection to block, and no other company receiving a request from every visitor to your site before they have agreed to anything.
Next step
See it against your own processing
A walkthrough runs on your activities and your purposes, not a demo tenant. Thirty minutes, and you keep the notes.
Book a demo