Set up the Consent Manager banner

Configure your consent banner's layout, purposes, and legal behavior, then publish it to your domains.

What this is, and why it matters

The Consent Manager is where you configure the cookie/tracker consent banner your website or app shows to visitors. Under §6 of the DPDP Act, every request for consent must be accompanied by a clear notice, and consent must be as easy to withdraw as to give — the banner is how you meet that requirement in practice, and this page is where you control exactly how it looks and behaves per domain.

Before you start

You need the Fiduciary Admin role — DPOs don’t have access to this page (they operate in Rights & Grievances and Risk & Governance instead).
Decide whether you need more than one domain group — use separate groups when different domains (e.g. a marketing site vs. a product app) need different banner designs or purposes.

Steps

Open Consent Manager from the sidebar. If you manage more than one domain group, pick it from the Domain Group selector at the top, or select the + button to create a new one.

Caption: the page header, showing the Domain Group dropdown and the dashed “+” button that opens the “Create Domain Group” dialog.
In the Design tab, set the banner’s Layout (bar, box, or dialog) and Position on the page.

Caption: the collapsible Layout card in the Design tab with the three layout options and position control.
Still in Design, scroll to Banner Behavior and choose how visitors interact with purposes: Multi-level (visitors can pick individual purposes), Inline Toggles (per-purpose switches directly on the banner), or Accept Only (a single accept button, no per-purpose choice — use only where that’s legally sufficient for your use case).

Caption: the Banner Behavior selector, with the explanatory tooltip (“Multi-level allows users to pick purposes; Inline shows toggles; Accept Only is a single button”) visible.
Switch to the Content tab to edit the banner’s wording, and the Privacy tab to review the legal/consent-purpose configuration that backs the banner.
Check your changes in Live Preview on the right — it renders the actual ConsentBanner component with your current settings, so what you see is exactly what visitors will see.

Caption: the right-hand Live Preview card, with the banner rendered as an overlay on the mock preview environment.
When you’re happy with the configuration, select Publish Changes at the bottom of the settings panel. The button shows a spinner while publishing, then confirms with Published!.
Go to the Deploy tab for the install snippet, and use Test Installation to confirm the banner is live on your domain.

Caption: the Deploy tab’s Installation card with the copyable script tag and the “Test Installation” action.

What happens next

Publishing updates the banner immediately for every domain in the selected group — there’s no separate release step. Every consent a visitor gives through the banner is recorded and becomes visible in the Consent Register and Analytics pages. If you later change what a purpose covers in a way that materially affects existing consent, consider a Re-consent Campaign instead of just editing the banner in place.

If your organisation turns on minor mode (on the Children’s Data page), the banner enforces the DPDP Act s.9(3) ban on tracking and targeted advertising directed at children, using each purpose’s minor policy from your privacy notice. Under Off nothing below happens and the banner behaves exactly as before.

Who is restricted. Under Known minors, a visitor is restricted only once there is a minor signal for them. Under Assume minor, every visitor is restricted until there is an adult signal at or above your adult assurance level. A minor signal always wins.
The age question. Under Assume minor the banner asks “Are you 18 or older?” as part of the choice. The answer is recorded for that browser and sent to us, so the server enforces the same thing. It is a self-declaration, so it unlocks anything only when your adult assurance level is self-declared; with a stricter level the question is not shown. Turn it off with Ask visitors’ age in Banner Behavior if your site passes the age itself (below).
While restricted. Purposes barred for minors are shown unticked and locked, labelled “Not available for users under 18”. Accept All accepts the allowed purposes only, with a short note saying why. Grants already stored for barred purposes are withdrawn. With data-dpdp-auto-block="true", scripts in barred categories are never released, known trackers (Google Tag Manager, Google Analytics, Meta, DoubleClick) stay blocked even when you have not tagged them, and blocked scripts with no data-dpdp-category are not released at all under any minor mode other than Off. Google Consent Mode keeps ad_storage, ad_user_data and ad_personalization denied, and analytics_storage denied unless an analytics purpose is allowed for minors and chosen. Known first-party ad and analytics cookies (_ga*, _gid, _fbp, _uet*, _gcl* and similar) are deleted on a best-effort basis.

For your developers

The script tag exposes these on window.DPDPGuard:

// Your own signup or age gate knows the visitor's age.
DPDPGuard.setAgeSignal({ band: "12_16" }); // under_8, 8_12, 12_16, 16_18, adult

DPDPGuard.getMinorStatus();
// { mode, status: "minor" | "adult" | "unknown", restricted, restrictedPurposes }

DPDPGuard.isRestricted("Marketing"); // a purpose label, purpose key or category
DPDPGuard.hasConsent("Marketing");   // always false for a barred purpose while restricted

window.addEventListener("dpdp:minor-status", (e) => {
  if (e.detail.reloadRecommended) {
    // Scripts already ran before the visitor turned out to be a minor.
  }
});
window.addEventListener("dpdp:consent-changed", (e) => console.log(e.detail.consents));

setAgeSignal is always recorded as a self-declaration: it can always make a visitor restricted, but an adult signal lifts the restriction only when your adult assurance level is self-declared, and it never overrides a minor signal.

The honest limit. A browser cannot unload a script that has already run. If a visitor becomes restricted after scripts were released — for example, they answer the age question on a page where trackers had already loaded — the banner applies everything above and fires dpdp:minor-status with reloadRecommended: true. Add data-dpdp-minor-reload="true" to the script tag to have the banner reload the page itself, so it comes back with the barred scripts blocked. Tracking your own servers run (server-side tag managers, CRM enrichment) is outside the banner’s reach.