Cross-Domain and Cross-Device Consent

  • Updated

Premier-Only Feature

As of 2025, most major browsers no longer support Cross Site Scripting. Due to that, Osano's legacy "cross-domain support" will not function on Google Chrome browsers operating on version 115 or newer, or other relevant browsers with restrictions. If cross-domain support is enabled, users will be prompted to provide consent on all listed domains individually.

Due to the nature of cross-domain support, browser restrictions may apply (e.g., Safari's default settings, Firefox default settings, Chrome v115).

Osano’s cross-domain and cross-device consent capability allows you to associate a user’s consent choices with a unique identifier, enabling those preferences to follow them as they interact with your brand across different domains and devices. This feature uses the userData API to link consent behavior to a specific user without ever transmitting raw identifiers to Osano servers.

 

What Is Cross-Domain and Cross-Device Consent?

Normally, a user who visits your properties from multiple devices or browsers must provide consent on each one individually. With cross-domain and cross-device consent enabled and configured, Osano uses your provided userData identifier to:

  • Store a user’s consent choices locally.

  • Associate that data with a hashed user identifier.

  • Retrieve those preferences when the same identifier is seen again.

With this in place, users don’t have to re-confirm their choices on every device, and your brand delivers a more consistent, respectful experience.

 

How It Works

Step 1: Identify the user.
As soon as a user logs in or is otherwise identified, assign a unique, consistent identifier using the userData property.

Step 2: Store consent locally.
When a user makes a consent decision, it’s stored locally along with a one-way hashed version of the identifier.

Step 3: Retrieve consent elsewhere.
If that same identifier is used on another site or device, Osano automatically checks local storage and syncs the previously recorded preferences—no banner required unless new purposes are introduced.

 

Implementation Example

This snippet sets the user’s ID before Osano loads:

<script> window.Osano = window.Osano || {}; window.Osano.cm = window.Osano.cm || {}; window.Osano.cm.userData = 'user-12345'; // Unique, consistent identifier </script> <script src="https://cmp.osano.com/XXXXXXXX.js"></script>

Example Usage

console.log(window.Osano.cm.userData); // Output: 'user-12345'

This value can be a string or a number (automatically converted to a string) and must be 128 characters or fewer.

Want help setting it up? Visit the developer docs for more.

 

Requirements

  • Cross-domain and cross-device consent must be enabled in your Osano CMP configuration. Please reach out to Osano support with the osano.js associated with the configurations you want to enable userData usage on.

  • The identifier must be unique, consistent, and non-personally identifiable, unless processed in a compliant manner.

 

What This Feature Doesn’t Do

  • It does not transmit user identifiers to Osano.

  • It does not automatically merge anonymous and known user sessions.

 

When Will the Banner Reappear?

If all of the above is configured correctly, the consent banner will not show again if:

  • The user has previously consented on another domain/device.

  • The same userData value is set before the CMP loads.

  • No new purposes or vendors have been introduced.

The banner will reappear if:

  • The identifier is not recognized (e.g., the user is anonymous).

  • New consent purposes are introduced on a property.

  • The identifier is set after the CMP loads.

 

Privacy & Compliance Notes

  • The userData value is hashed before storage and never sent to Osano servers.

  • You are responsible for ensuring any identifier used complies with applicable privacy laws.

  • Do not use this feature to track users across properties without clear legal justification.