Guides
OneTrust capabilities, explained and verified
Each guide names what a specific OneTrust capability actually is, when a privacy or marketing team needs it, how to implement it correctly, and - the part most documentation skips - how to verify it actually worked, in your own browser or debug tools, not just that the configuration looks right.
AI & emerging channels
2OneTrust AI Guard: what it is and when you need it
AI Guard is OneTrust's policy and inspection layer for data flowing into and out of AI systems - LLM prompts, model responses, and AI-agent tool calls. It sits in front of your application's calls to a model provider, classifies content against configured sensitivity profiles, and can redact, block, or simply log matches in real time, rather than relying on the model provider's own safety layer to catch a leak after the fact.
Read the guideAI & emerging channelsllms.txt and AI-crawler access: giving agents a straight answer instead of a guess
llms.txt is a plain-text file, published at your domain root the same way robots.txt is, that tells AI agents and crawlers which content is meant for their consumption and where to find the clearest version of it. OneTrust's integration guide frames this as a governance question, not just a discoverability one: which content is fair game for third-party AI systems, and whether AI-agent traffic needs the same consent and logging treatment as human visitor traffic under your existing privacy program.
Read the guideConsent architecture
4Cross-domain and cross-device consent sync in OneTrust
Cookies are scoped to the domain that set them, so a visitor's consent choice does not automatically carry over to a sibling domain, a genuinely separate top-level domain, or a mobile app running alongside your web property. OneTrust supports syncing consent across those surfaces by linking it to a persistent identifier - a parent-domain cookie for same-registrable-domain subdomains, or an identity-linked consent profile for separate domains and web-plus-app setups - rather than by any automatic cross-origin mechanism, since browsers don't provide one.
Read the guideConsent architectureGeolocation-based consent rules: serving the right banner by region
Geolocation-based consent rules let one implementation show different banner behavior depending on the visitor's detected region - an explicit opt-in template where a regulation requires it, a lighter opt-out model where one applies, and no banner at all where neither does - configured through region-mapped rule sets rather than one global template applied everywhere.
Read the guideConsent architectureMulti-profile consent management for multi-brand and multi-region sites
Multi-profile configuration lets one OneTrust tenant maintain separate consent setups - distinct banners, categories, vendor lists, or even different regulatory templates - for distinct brands, regions, or business units, instead of forcing one global configuration or standing up a separate OneTrust account per brand. Each profile is its own self-contained rule set that gets mapped to the domains or apps that should use it.
Read the guideConsent architectureTriggering OneTrust collection points programmatically
A OneTrust collection point is a defined moment for capturing a specific kind of consent or preference - a newsletter opt-in, a purpose-specific consent inside a product flow. Triggering it programmatically means invoking that collection point from your own application code at the moment it's actually relevant, rather than only ever presenting it as a static embedded form a visitor happens to land on.
Read the guideDeveloper integration
3Responding to consent state changes without polling
Rather than polling for the current consent state on an interval, OneTrust's SDKs expose a callback that fires the moment a visitor's consent actually changes - a new choice, a revocation, or a change synced from another surface - so an application can react immediately by loading a script, tearing one down, or refreshing UI, instead of waiting for the next page load or checking on a timer.
Read the guideDeveloper integrationOneTrust JavaScript consent events: what to listen for and why
Beyond the single consent-change event, OneTrust's JavaScript layer exposes a broader set of events across the banner's lifecycle - shown, closed, preferences opened, an initial choice versus a later update. These are the hooks for instrumenting the consent experience itself (measuring how visitors interact with the banner) and for building a custom preferences interface, distinct from the change-event pattern used to gate other scripts on the outcome.
Read the guideDeveloper integrationContent Security Policy configuration for the OneTrust CMP
OneTrust's CMP script calls a specific set of domains at runtime - the script origin itself, the API/logging origin that receives consent choices, and a CDN origin serving rule and consent-string data. Under a strict Content-Security-Policy, none of those calls are allowed by default, so the CMP either fails to load entirely (worst case: no banner, no consent gate, and other tags firing unconstrained) or throws CSP violations that mask the real problem underneath.
Read the guideAd tech & mobile governance
3Consent integration with Google's Tag Gateway for advertisers
Google's Tag Gateway for Advertisers moves ad-related tag execution - Google Ads and Floodlight-style measurement - to a first-party, server-side-adjacent path served from your own domain, rather than a purely client-side gtag.js call to a Google-owned domain. That changes where and how consent needs to be checked compared to the classic client-side setup, so a OneTrust consent integration for it has to confirm consent signals reach the gateway before it processes anything, not just that the client-side tag respects them.
Read the guideAd tech & mobile governanceIAB TCF v2.2 implementation with OneTrust
The IAB Transparency & Consent Framework (TCF) v2.2 is the standardized way programmatic advertising vendors read a visitor's consent choices without each one needing a direct integration with your CMP. OneTrust's TCF implementation generates the encoded euconsent-v2 consent string and exposes the __tcfapi command-queue interface that IAB Global Vendor List-registered vendors read from - the mechanism that turns one banner's choices into a signal dozens of ad-tech vendors can all consume the same way.
Read the guideAd tech & mobile governanceMobile app privacy scanning: finding undisclosed SDKs and trackers
OneTrust's app scanner analyzes a mobile app binary or build artifact to automatically discover which third-party SDKs it includes, what data those SDKs are capable of accessing, and cross-references that against what's actually declared in App Store Privacy Nutrition Labels and Google Play Data Safety sections. It's functionally the mobile equivalent of the web cookie and tag discovery covered on this site's own vendor-discovery use case - built for the fact that mobile SDKs get added transitively through dependencies just as often as web scripts get added by a marketing tool nobody told engineering about.
Read the guideWant this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.