OneTrust Implementation Consultants

What a OneTrust implementation actually involves

Buying OneTrust gets you a console. It does not get you a compliant site. The gap between the two is where most projects stall: a banner that fires after the analytics tag, categories that nobody mapped to real cookies, a geolocation rule set that treats the UK as EEA, and a preference centre nobody links to from the footer.

We work through that gap in a defined order, because the order matters. Scan first, so decisions are made against the cookies you actually set rather than the ones you think you set. Categorise second. Configure the templates and geolocation rules third. Only then touch the tag manager, because that is where a mistake silently breaks measurement rather than loudly breaking the page.

The deliverable is a working configuration plus the documentation that explains why each decision was made. Six months later, when a regulator, an auditor, or a new marketing hire asks why a given vendor sits in Functional rather than Targeting, the answer should be written down.

• Cookie and tracker scanning, with manual verification of what the scanner missed behind auth walls and consent gates
• Category mapping across first-party and vendor cookies, local storage, pixels and SDKs
• Banner and preference centre templates built to your design system, not the OneTrust default
• Geolocation rule sets that reflect actual legal exposure — EEA, UK, Switzerland, Brazil, and US state-by-state
• Google Tag Manager and server-side integration so tags respect consent state instead of a race condition
• Consent record retention, export and audit-trail configuration

Universal Consent and Preference Management (UCPM)

Cookie consent is the visible part. The larger problem for most organisations is that consent lives in five places at once: the CMP for web tracking, the CRM for email, the mobile app for push, the call centre script, and a spreadsheet somewhere for events. Nobody can answer 'what has this person consented to' without three people and an afternoon.

UCPM is OneTrust's answer to that, and it is a genuinely different project from a cookie banner. It needs a data model decision up front — what a purpose is, what a subject identifier is, how you reconcile an anonymous web visitor with a known contact once they log in. Get that wrong and you will be re-implementing in a year.

We scope UCPM around the identifiers you already have rather than the ones a reference architecture assumes. In practice that usually means email as the primary identifier, a hashed device identifier for pre-login web, and an explicit merge event at login. Preference centres, double opt-in flows and receipt storage follow from that.

• Purpose and topic taxonomy design that maps to how your business actually markets
• Preference centre build, hosted or embedded, with authenticated and token-based access
• Integration with your CRM or marketing automation platform so preferences propagate rather than drift
• Consent receipt storage, proof-of-consent export, and retention rules

Migrations and rescue work

A meaningful share of the work we are asked to do is not greenfield. It is a migration from another CMP onto OneTrust, or a rescue of a OneTrust instance that was configured by someone who has since left.

Migrations are mostly about consent continuity. If you move platforms and drop the existing consent signals, every returning visitor sees the banner again and your opt-in rate visibly craters for a fortnight. That is avoidable: existing consent state can usually be translated into the new platform's cookie format, provided the category mapping between old and new is done deliberately rather than by name matching.

Rescue work starts with an audit. We compare what the console says is configured against what the browser actually does — which tags fire before consent, which cookies are set regardless of category, which geolocation rule is being hit. The gap between the two is the actual finding, and it is almost never in the console.

How we work

Engagements are scoped in weeks, not quarters. A single-domain cookie consent implementation on a straightforward stack is typically two to four weeks including testing. Multi-domain estates, multiple languages, or a UCPM component push that toward six to ten.

We do the work in your environment with your team present, not in isolation. Knowledge transfer is part of the deliverable rather than an upsell — the point is that your team can change a banner text or add a vendor without calling us. Documentation and a walkthrough session close every engagement.

We also work across other consent platforms where OneTrust is not the right fit or is not what you already own. The implementation discipline is the same; the console is different.