Consent settings

Every event Monita observes can carry a consent value (cn), supplied by the page hook you wire to your consent management platform during installation. Consent settings (app.monita.ai/compliance/consent) controls how that value is interpreted — and that interpretation feeds every consent-aware feature in the suite.

Where the value comes from

The monitoring script calls your get_consent page hook on every event and attaches whatever it returns. You decide what to expose — most teams return their CMP’s own consent string unchanged. Setup details are in the website install guide.

Auto-detected formats

By default Monita recognizes standard CMP output automatically:

Format	What it looks like	Per-vendor verdict
OneTrust groups	C0001:1,C0002:1,C0004:0 or bare group ids	Yes — via the standard OneTrust category template: C0002 governs analytics vendors, C0004 targeting/advertising, C0005 social
Didomi vendor lists	iab:98,c:tiktok-XXXX,didomi:google,… (or a full didomiState blob)	Yes — a vendor on the list is consented; a vendor absent from it is not
IAB TCF strings	A long base64 consent string	Counts as explicit consent data being present; individual vendors read as indeterminate
Simple yes/no	yes, true, 1, granted, denied, rejected, …	Yes — applies to every vendor

When a CMP is detected in the page environment, the settings page names it per property.

Verdicts are deliberately three-state — consented, consent-negative or unknown. When a format can’t answer the question for a particular vendor, Monita says unknown rather than guessing.

Manual rules for custom formats

If your site sends a custom cn format, switch the scope to Manual and declare what each value means:

1. Add rules of the form pattern → verdict: match by equals, starts with, contains or regex, and map to consented or consent-negative.
2. Optionally scope a rule to a vendor purpose category — ads & social, analytics, or session replay & chat — instead of the default all vendors. Use this for signals like a CCPA opt-out that governs advertising but says nothing about analytics.
3. Order matters: rules are checked top to bottom, and the first rule whose pattern and vendor scope both apply decides the verdict for that vendor. Values no rule matches stay unknown.

Configuration is set at the organization default and can be overridden per property. The page shows the actual cn values observed in your traffic over the last 72 hours, how each currently reads, and — while you edit — how your draft rules would read them, so you can verify the mapping before saving.

Caution

A value you map to consent-negative while ad tags fire is flagged as a potential violation across the compliance suite. Make sure the mapping reflects what the value actually means on your site.

Per-vendor consent expectations

Not every vendor firing without consent is a breach. Some fire anonymized by design when consent is absent; others your organization has decided are essential. Each vendor carries a consent expectation that tells the compliance suite how to read its no-consent fires:

Expectation	What it means	How it reads
Consent required (default)	A fire without affirmative consent is a violation	Flagged as a breach on the Command center consent-by-vendor table
Consent mode	The vendor fires anonymized without consent by design — e.g. Google Advanced Consent Mode, where pings are cookieless until consent is granted	A consent mode badge replaces the breach flag; the counts stay visible so you can still see the volume
Exempt	Your organization accepts this vendor’s fires regardless of consent — e.g. an essential business partner	A grey exempt badge; fires without consent are accepted

Set the expectation from the dropdown on each vendor’s row in Vendor lists, via the API (PUT /v1/compliance/vendors/{vendor} with consentExpectation — see the API reference), or with the set_vendor_policy tool on the MCP server.

Caution

Consent mode and exempt change how fires are labelled, not what Monita observes — the events still appear in every table and export. Reserve exempt for vendors your privacy team has explicitly signed off on; it is your organization’s judgement on record, not Monita’s.

Properties without an on-page CMP

Some properties will never show a detectable CMP — in-product surfaces, native-app webviews, or pages where consent is collected upstream. By default the Command center property portfolio marks a property with no detected CMP as amber not detected, which reads as a problem to fix.

If that’s by design, switch Consent settings to the property’s scope and tick “No on-page CMP on this property”. The portfolio then shows a neutral n/a for that property’s CMP instead — the property is no longer flagged for something it can’t have.

The checkbox is per property; it only appears when a property scope is selected, and it doesn’t change how the property’s consent values are interpreted — your organization default or property-level rules still apply.

Why consent context matters

The consent verdict attached to each event powers:

• Command center — the consent-by-vendor breach table and the consent-negative markers on the traffic map.
• Regulation checks — statutes like CCPA/CPRA and the state comprehensive acts hinge on trackers firing against opted-out traffic from covered states.
• Compliance issues — a vendor firing on consent-negative traffic files into Issues like any other detection, and routes through your alert rules.

Without a consent signal, vendor activity still appears everywhere — it just reads as “no consent data”, which is itself a posture worth fixing.

Tip

After changing consent settings, give it a few minutes of live traffic and re-check the observed-values table — every value should read as consented or consent-negative, with unknown reserved for genuinely ambiguous shapes.