/ Docs

Overview and Implementation Guide

Last updated August 27, 2026 · View as Markdown

About this document set

This is the entry point to Relyance's Consent Management documentation. Start here, then branch out to the guide that matches your role:

Document Audience What's in it
Overview and Implementation Guide (this doc) Everyone What Consent Management is, how the pieces fit together, and the step-by-step rollout plan
Legal and Compliance Guide Legal, privacy counsel, DPOs Regulatory coverage, consent models, data minimization, audit posture - no code
Technical Implementation Guide Engineers deploying the agent script Login recordings for authenticated scans, installation, configuration attributes, event system, JS API, CSP, testing, troubleshooting, GTM integration
Admin Configuration Guide Privacy/marketing admins working in the Relyance platform Domain Analyzer (including authenticated scanning, scheduling, notifications), Tracking Technology Management, Region Groups, Interface Builder
Consent Logs and Reporting Compliance, auditors, admins What's captured, how to view it, how to export it
Regional and Jurisdiction Reference Legal + admin Jurisdiction-by-jurisdiction market-standards configuration reference (GDPR, CCPA, LGPD, and 9 more) - fully customizable, not built-in
FAQ: Consent Management Prospects, new customers, sales/CS Common questions in plain language

Relyance Consent Management is an integrated consent management platform (CMP) built into the Relyance AI platform. It handles the full lifecycle of website/app consent compliance:

  1. Discover what tracking technologies (cookies, pixels, SDKs, local/session storage, fingerprinting scripts) are actually running on your properties - automatically, on an ongoing basis.
  2. Categorize each one by purpose (analytics, marketing, functional, etc.) and map it to the vendor and business process it belongs to.
  3. Configure the consent rules that should apply, per jurisdiction - which consent model (opt-in, opt-out, implied, no-choice), what the banner should say and look like, and how signals like Global Privacy Control (GPC) should be honored.
  4. Enforce those rules in the browser in real time, via a lightweight script (the Consent Agent) that blocks or allows each tracking technology based on the visitor's actual consent choice.
  5. Prove it - every consent decision is logged with enough detail (timestamp, region, purposes accepted/rejected, GPC status) to stand up to a regulator or auditor.

Because discovery, categorization, configuration, enforcement, and logging are all part of one connected system (rather than a bolt-on banner tool), changes flow through automatically - approve a newly discovered tracking pixel once, and every part of the system (the agent's blocking rules, the preference center list, the policy page, the audit log) reflects it.

How the pieces fit together

Domain Analyzer  →  Tracking Technology     →  Region/Behavior       →  Interface Builder    →  Consent Agent        →  Consent Logs
(discovers tech     Management                 Configuration            (designs banner,         (enforces rules         (records every
 on your domain)     (approve/disregard,        (per-jurisdiction        preference center,       live, in the            decision for
                      categorize by purpose)     consent model,           opt-out widget,          visitor's browser)      audit/export)
                                                  banner behavior,         policy page)
                                                  GPC handling)
  • The Domain Analyzer crawls your site (or mobile app) and finds every tracking technology in use - see the Admin Configuration Guide.
  • Tracking Technology Management is where your team reviews those discoveries and approves, disregards, or edits them.
  • Region/Behavior Configuration (called Consent Domain Behavior Configuration in the platform UI, built around Region Groups) defines what should legally happen in each jurisdiction - see the Admin Configuration Guide, the Legal and Compliance Guide, and the Regional and Jurisdiction Reference.
  • The Interface Builder is where you design the banner, preference center, opt-out widget, and policy page your visitors actually see.
  • The Consent Agent is the JavaScript embedded on your site that ties it all together at runtime - see the Technical Implementation Guide.
  • Consent Logs capture what actually happened, for reporting and audit - see Consent Logs and Reporting.

Implementation roadmap

A typical rollout moves through seven phases. Legal/privacy, marketing/web, and engineering are all involved at different points - plan for cross-functional coordination, not a single-team project.

Phase 1 - Discovery

Owner: Admin/IT. Add each domain or mobile app to Relyance and let the Domain Analyzer run its first scan. If a domain has pages that sit behind a login, set up authenticated scanning in the same wizard (domains only, not mobile app digital properties) - see the Technical Implementation Guide if a login recording needs to come from engineering. You can also set a recurring scan schedule and notification recipients here rather than relying on manual rescans (see the Admin Configuration Guide). If you run a WAF, CDN bot protection, or IP-based firewall rules, allowlist the Relyance scanning IPs first (see the Admin Configuration Guide) - otherwise the scan can silently fail or return zero results.

Phase 2 - Categorize

Owner: Privacy/marketing admin. Work through the Tracking Technology Management queue: approve technologies that should be governed by consent, disregard anything out of scope, and confirm each is mapped to the right purpose/processing activity. This step directly determines what the Consent Agent will later block or allow.

Owner: Legal/privacy, with admin support. Region Groups are fully customizable - set one up for each jurisdiction you operate in, choosing the consent model and GPC handling per region. The Regional and Jurisdiction Reference provides market-standard configuration patterns as a starting point; it isn't pre-loaded into your account. Everything not explicitly covered by a Region Group falls back to the Global group - it's your catch-all for jurisdictions you haven't explicitly addressed, so configure it deliberately rather than leaving it at whatever it defaults to.

Phase 4 - Design

Owner: Marketing/brand, with legal review. Use the Interface Builder to design the banner, preference center, opt-out widget (US), and policy page - branding, copy, and translations. Legal-required copy (button labels, required disclosures) should be reviewed before publishing; cosmetic edits to display text don't affect the underlying legal/RoPA records, so marketing can iterate freely without legal re-review of every wording tweak.

Phase 5 - Test

Owner: Engineering + QA, with admin sign-off. Before rolling the script out site-wide, install the dedicated test agent script (from Domain Detail → Testing tab in the Relyance platform - separate from the production install snippet) on a staging environment or test pages, optionally gated further with the conditional-load pattern (?loadConsentAgent=true). Use region simulation (?cm_region=FR, ?cm_region=US-CA, etc.) to confirm each jurisdiction's rules render correctly before switching to the production script. See the Technical Implementation Guide.

Phase 6 - Deploy

Owner: Engineering. Once testing confirms the expected behavior, install the Consent Agent script on every page of the domain, as early in <head> as possible. This is the one step in the rollout that requires a code change - see the full walkthrough in the Technical Implementation Guide.

Phase 7 - Go live and monitor

Owner: Admin/compliance, ongoing. Once live, monitor Consent Logs for volume and GPC signal rates, periodically review new Tracking Technology discoveries (sites change - new pixels and scripts get added over time), and export logs as needed for audits or DSARs.

Who should read what