Universal Consent Overview

Today, a user's consent choice is saved to their browser and, if you use Embedded Deployment or Google Tag Manager across related sites, shared across subdomains. Universal Consent extends this by tying a consent choice to the user instead of the browser or app, so it's honored everywhere you've deployed DataGrail Consent. This closes the gap where a user opts out on one property but remains opted in on another simply because the two run in different browsers, on different domains, or on different devices.

Deployment Options

Universal Consent supports two deployment options, depending on the surfaces where a user's consent choice needs to be honored.

Option	Where Preferences Are Shared	Example	What You Need
Web	Across every domain where you've deployed DataGrail Consent	A user opts out on brand-a.com and is automatically opted out on brand-b.com	Consent deployed on each domain, plus a backend that can sign preference updates. Works with your existing web banner and deployment paths — no changes to how your banner looks or behaves are required.
Web + Mobile	Across domains and devices	A user's choice on your website is automatically applied in your iOS, Android, or React Native app, and the reverse	Everything in Web, plus the DataGrail mobile SDKs

How It Works

Universal Consent separates collecting a consent choice (which happens rarely, when a user interacts with your banner) from evaluating it (which happens constantly, on every page load and app launch).

• Identity and hashing. Your SDK (web, iOS, Android, or React Native) takes the identifier you've already associated with the logged-in user, such as a random UUID or another opaque, random account identifier, and hashes it (SHA-256) on the device before anything is sent over the network. Only the hash travels to DataGrail — the raw identifier stays in memory on the client and is never transmitted.
• Signed writes. Because browsers and mobile apps are untrusted clients, every write is signed by a system you control. Your backend signs a canonical string with a secret DataGrail issues you, and DataGrail independently verifies that signature before saving the write. Your secret never reaches a browser or app.
• Fast reads. Consent lookups are served from DataGrail's global edge network and are cache-friendly, so a repeat check for the same person is typically served from cache rather than a fresh lookup.
• Graceful fallback. If a lookup or write fails for any reason, the web banner and mobile SDKs fall back to the consent choice already stored on that device and continue operating normally. Device-local consent is always the source of truth if Universal Consent isn't available.

For the full signing recipe, headers, and code samples, see the Developer Guide.

Requirements

Before enabling Universal Consent, confirm you meet the following requirements.

Requirement	Details
A stable, opaque identifier for logged-in users	Universal Consent recognizes a person using an identifier your backend already assigns them, such as a random user UUID. Don't use an email address or phone number, even hashed: those values are guessable, so a list of candidates could be hashed and matched against stored records. It must also be non-guessable, such as a random UUID, never a sequential or enumerable ID: reads need only public values (your API key, customer ID, and project ID), so anyone could hash guessable IDs and look up other users' records.
A backend that can sign preference updates	Your backend needs an endpoint that can generate an HMAC signature for each consent write, using the signing secret issued with your API key. See the Developer Guide for the signing recipe and reference signers.
An API key and signing secret	You issue these from your Universal Consent settings once the feature is enabled. Both are shown only once, so store them in your secret manager right away.
DataGrail Consent deployed on each domain, in one Consent Project	Each domain that should share preferences needs its own DataGrail Consent deployment, and every one of those containers must belong to the same Consent Project. The user hash includes the project, so containers in different projects never match. See Deployment Paths.
DataGrail mobile SDKs (Web + Mobile only)	Cross-device sharing requires the DataGrail mobile SDKs for iOS, Android, or React Native.
Universal Consent enabled on your Consent Project	Ask your DataGrail contact to enable Universal Consent for your account, then turn it on for your Consent Project under Consent > Settings > Universal Consent and issue your first API key. Republish every container in the project afterwards: a container starts using Universal Consent only after it's republished.

Next Steps

Once you've confirmed the requirements above, continue to the guide for your role.

Guide	For
Universal Consent Lifecycle & Compliance Guide	Privacy and compliance professionals reviewing how consent flows through the system
Developer Guide	Developers implementing the identity hash, write signing, and client SDKs