Privacy and Consent for the Docket Widget

Last updated: August 10, 2026

Privacy and Consent for the Docket Widget

Use this article to understand what Docket can do with visitor identity persistence and consent signals for the website widget. This is product documentation, not legal advice. Work with your privacy or legal team to decide which setting is appropriate for your site.

What Docket Controls

Docket can control whether the widget persists a returning-visitor identity across sessions. The current implementation supports three visitor cookie modes:

  • Existing behavior: Docket keeps the current returning-visitor identity behavior for the tenant.

  • Consent gated: Docket persists returning-visitor identity only when the configured consent signal grants the required targeting category and Global Privacy Control is not signaling opt-out.

  • No cookie: Docket does not persist returning-visitor identity through the widget cookie path.

How Consent-Gated Identity Works

When consent-gated identity is enabled, the widget reads browser consent signals during auth initialization and sends the raw signals to Docket. The backend evaluates those signals against the tenant configuration and returns whether identity may persist for that page load.

For OneTrust in the current implementation, Docket can read the OptanonConsent cookie and OnetrustActiveGroups. The backend treats OptanonConsent as authoritative when it includes group consent data, and only falls back to OnetrustActiveGroups when that cookie signal is absent.

If the browser sends Global Privacy Control, or OneTrust records GPC in the consent cookie, Docket does not persist returning-visitor identity in consent-gated mode.

What Happens When Identity Is Not Persisted

When the backend says identity should not persist, the widget revokes durable cookie persistence, clears the browser fingerprint seed, and continues the current session with an in-memory visitor ID. On the next page load, the visitor starts fresh unless consent and tenant configuration allow persistence.

Docket also skips external IP enrichment for non-consented visitors in this path. Do not describe this as “no data collection”; it is specifically a returning-visitor identity persistence and enrichment control.

What Your Team Owns

  • Choosing the appropriate visitor cookie mode for your tenant.

  • Maintaining the consent banner, privacy notice, and consent categories on your website.

  • Confirming which OneTrust targeting category IDs should allow Docket identity persistence.

  • Validating that your site sends the expected consent and GPC signals before launch.

Before You Launch

  1. Confirm the visitor cookie mode with your Docket team.

  2. If you use consent-gated identity, confirm the CMP source and targeting category IDs configured for your tenant.

  3. Test a page load with consent granted and confirm returning-visitor identity can persist.

  4. Test a page load with consent denied or GPC enabled and confirm identity persistence is blocked.

  5. Review the behavior with your privacy or legal owner before rolling it out broadly.

Troubleshooting

Issue

What to Check

Visitors are not recognized across sessions

Confirm the tenant is not set to no-cookie mode, that consent-gated mode has the right OneTrust targeting IDs, and that GPC is not enabled for the test browser.

Consent looks granted but identity still does not persist

Check whether OptanonConsent includes the expected granted group. When that signal is present, Docket treats it as authoritative.

You are unsure which mode applies

Ask your Docket team to confirm the tenant visitor cookie mode and CMP configuration before documenting or launching the behavior.

Related Articles

  • Security Guidelines for Passing Visitor Context

  • Troubleshooting Widget Not Loading or Displaying

  • Understanding Widget Behavior and Access