OneTrust JavaScript consent events: what to listen for and why
What it is
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.
When you need it
You want to measure banner performance - show rate, accept rate, time-to-decision - as its own analytics question, separate from what scripts fire afterward.
You're building a custom preferences UI that needs to accurately reflect OneTrust's underlying state as the visitor interacts with it.
You're debugging why a specific visitor's consent flow behaved unexpectedly and need the actual sequence of lifecycle events, not an assumption about what should have happened.
How to implement it
- 1
Identify which lifecycle events your deployed script version exposes
Exact event names have shifted across major CMP script versions - verify against current OneTrust docs for the version actually deployed on your tenant rather than assuming an older reference is still accurate.
- 2
Attach listeners only for the events your instrumentation actually needs
Listening to every available event by default produces noisy logging that's harder to act on - scope listeners to what a specific report or feature genuinely requires.
- 3
Send banner-lifecycle events to analytics as their own event type
Tag them distinctly from "a tag fired because consent was granted" events elsewhere on the site, so a report on banner performance doesn't get mixed in with a report on downstream tag-firing behavior.
- 4
Read state through documented events and getters, not by inferring from cookies
If building a custom preferences UI, OneTrust's internal storage format isn't a public contract and can change between releases - the documented event/getter surface is the stable interface to build against.
- 5
Keep verbose event logging behind a debug flag
Consent-event logging can be genuinely high-volume across every visitor interaction with the banner - don't ship it to production console output by default.
How to verify it worked
With verbose event logging enabled, interact with the banner through every path (accept all, reject all, customize, dismiss) and confirm each produces the expected, distinct event.
Check your analytics platform and confirm banner-lifecycle events arrive tagged separately from downstream tag-fire events, not merged into one event category.
Remove the debug flag and confirm a production build ships with no verbose console output from the listener code.
Related
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.