Implementation Best Practices: Cookie Consent

Conduct a thorough analysis of which regulations apply to your organization. This ensures your implementation focuses on the most relevant compliance requirements, avoiding wasted effort on non-applicable regulations.

Leverage OneTrust's regulatory templates and updates to stay current with changing laws. Privacy laws are constantly evolving. Using OneTrust's pre-built templates and updates saves time and helps ensure ongoing compliance with the latest regulatory changes.

Form a cross-functional privacy team including representatives from Legal, IT, Information Security, HR, and key business units. Include individuals who act as DPOs for legal entities, if applicable. Also consider including internal contacts for third parties. Privacy impacts all areas of an organization. A diverse team ensures comprehensive coverage of privacy concerns and promotes organization-wide buy-in.

Clearly define roles and responsibilities for each stakeholder in the OneTrust implementation process.

Tool Owner

Thewill maintain the functional implementation, which includes all configuration steps required in the OneTrust tool.

Development Decision Maker

The  will oversee the technical implementation of the OneTrust CMP across your digital assets, integrating with your internal tools, and ensuring the relevant tracking technologies are being blocked after giving consent.

Establish regular communication channels and meeting cadences for the privacy team. Consistent communication keeps all stakeholders informed, allows for timely problem-solving, and maintains momentum throughout the implementation process.

Identify executive sponsors to champion the implementation and secure necessary resources. Executive support is crucial for overcoming organizational barriers, securing budget and resources, and emphasizing the importance of the privacy program across the organization.

Decide if mirroring your actual organizational hierarchy within OneTrust, including the different sub-organizations/brands is relevant to you, for example if you would prefer different brands within your organization to only have visibility of their own digital assets. However, it is not always necessary for every business and may lead to an overcomplicated set-up.

Implement role-based access control (RBAC) to ensure appropriate data access and permissions. RBAC enhances data security, prevents unauthorized access, and ensures users only see information relevant to their roles and responsibilities.

Plan for future organizational changes and ensure your structure is scalable. Organizations evolve over time. A flexible, scalable structure in OneTrust reduces the need for major reconfigurations as your organization changes.

Consider language requirements if multi-lingual use is applicable to your organization.

Prepare your domains in advance:

Scanning times can vary depending on the size of your domain, some take a few hours, while others might take a few days. Since categorization relies on the cookies found by the scanner, it’s a good idea to have a list of the domains you want to implement on so you can start scanning early and avoid delays in the categorization process.

Optimize your scan:

OneTrust provides a few configuration options to help optimize your scan. The recommendation is to leverage these options where possible to ensure the scanner is able to crawl the key pages where you are expecting cookies to be found.

Provide a sitemap

Providing a sitemap can help the scanner prioritize pages defined in your sitemap, as opposed to crawling through your website by taking a random route.

Target, include or exclude, pages, paths to scan

If you want to prioritize the scan of specific subdomains, pages, or paths, you can use “Target” in the scanner configuration, and once these are completed, the scan will continue to the remaining of the website. In the same way, you could also “Exclude“ or “Include” subdomains, pages, or paths from the scan if this is needed.

Scan pages with query parameters

This feature allows you to add query parameters to your scan to potentially replicate an instance where query parameters are added on a URL. Add comma-separated ID and source parameters to include as query parameters in your scan, such asId=1234,src=a7dh-k9dy. Do not prefix with '?'. This will be automatically added to the parameters once saved.

Safelist the scanner IP address and/or user agent:

If your website security mechanisms designed to protect the website is inadvertently interfering with the scanning process, you can safelist the scanner IP address and/or the user agent. To set the user agent to a specific string as "OneTrustBot", enable in the scanner configurations "Enable Unique User Agent". You can find the scanner IP address to safelist in this article About OneTrust Hosting Options, Locations, and Backup.

If you need bypass a login form or accept an existing banner:

Use the login page configuration

If there is an area of your site behind a login, please provide login credentials and ensure the authentication method is simple for a successful scan. For more information, seeScanning Behind Authentication.

If you need to accept an existing banner to drop cookies or authenticate

If the existing banner on your website, when accepted, sets a session cookie, you can use this to simulate the banner being accepted so the scanner can collect the cookies. In the Login Settings, you can add this cookie name and value before performing the scan to accept the existing banner. You can also use this option to Authenticate if there is authentication cookie. For more information, seeScanning Behind Authentication.

Schedule scans:

It is recommended to configure schedule scans, as this will not be enabled by default. The recommendation is to set the scan to run every 3 months to make sure your website is regularly audited. If you expect to update tracking technologies on your website more often, you might want to increase the frequency. You can set up the scheduler to run on its own and send an email to let you know when the scan completed.

Limit scan:

Limit scans to 1,000 pages when possible to reduce potential errors and avoid long-running scans. When combined with site maps and specific targets, there is little to no benefit to scan beyond 1,000 pages—it's unlikely that additional cookies will be found and greatly increases scanning time.

Categorize unknown cookies:

As “unknown" is not a valid category, ensure you categorize all cookies, so they are visible in the Cookie List. Populate the missing information like description so this is also visible. If you are unsure what purpose to assign to “unknown” cookies, the best practice is to consult with your website developers as they will know what their functionality is so you can accurately categorize them.

Maintain consistent Cookie IDs: If you create extra cookie categories or edit existing ones, ensure that you use a consistent standard for cookie IDs, like the out of the box IDs C0001, C0002, etc. This consistency will simplify the configuration process, especially when setting up cookie blocking with tag manager integration or client-side cookie blocking.

Consolidating Cookies that contain names with variable IDs: When a cookie is generated multiple times with different IDs (e.g., "cookie_1234" or "cookie_12345"), it is the same cookie but detected each time with a unique ID. To avoid displaying multiple entries of the same cookie in your cookie list, you can request OneTrust to consolidate these cookies into a regex pattern (e.g., "cookie_xxxxx"). This way, only one entry will appear in the cookie list, improving clarity and organization.

Use a Relevant Naming Convention for the Templates: When creating templates, use a naming format that enables you and your team to quickly distinguish and identify what each applies to. For example:

• [Company Name – Consent Framework]

  • OneTrust – GDPR

• [Company Name - Region – Consent Framework]

  • OneTrust - EU – GDPR

  • OneTrust - US - CCPA

When to Use the Website-Level Branding vs. Regular Templates: If you're using the same template for a group of websites but need to apply small modifications at the website level without affecting other websites, you can enable Branding to override the template configurations for that specific website. For example, if you need to override the cookie policy link or button colors in a specific website. If you have multiple languages, then it will be better to use Templates because in Branding, you will not be able to define the Cookie Policy link or Impress Link for multiple languages.

Use a Relevant Naming Convention for Geolocation Rules and Groups:

When creating Geolocation Groups and Rules, use a format that enables you and your team to quickly distinguish and identify what each applies to. For example:

a. Naming for Geolocation Rule Groups:

• [Company Name] – [Geolocation Rule Group]

  • OneTrust – Geolocation Rule Group

  • OneTrust – Default Rule Group

b. Naming Geolocation Rules:

• [Global/Region] – [Audience]

  • Global Audience – Opt-In

  • EU Audience – GDPR Opt-In

  • US Audience – CCPA Opt-Out

Enable collection of data:

Enable Capture Records of Consent within your geolocation rules to capture the consent data that populates the Dashboards. When enabling Advanced Analytics, the recommendation would be to select the Strictly Necessary purpose as it will always be enabled so you can always collect advanced analytics, such as browser type, device type, and location. After enabling, publish the scripts to start tracking consent and start seeing the data in the Dashboards. Consent is also logged when you use the Test CDN script, so if you’re doing heavy testing, you might want to disable this to not capture this test data.

Testing and Publishing Scripts:

Implement the Test script on a staging site only and the Production script on your live production website only (the domain you scanned). Before publishing and implementing your Production script, the recommendation is to first publish and deploy the Test script to your staging site to review the changes. Once you’ve confirmed all changes are working as expected, you can safely publish and implement the Production script to your live production website. Ensure to test and review the changes on your live production website. This approach helps prevent unexpected changes from being pushed live to your users.

Avoid duplicate loading of the OneTrust cookie banner Script:

The OneTrust cookie banner script should only be triggered from either the tag manager or the source code, but not both simultaneously. Loading the script from both sources can cause conflicts and unexpected behavior. Ensure the script is fired from only one of the two to avoid issues on your website.

Accessing the Preference Center after giving Consent: After a user has consented or closed the cookie banner, they should have a way to access the preference center in case they want to manage or update their consent preferences. You can implement the "Cookie Settings" button onto your website, by copying the code snippet provided in the Scripts section.

Ensuring changes are visible after Publishing Scripts: After publishing your Test or Production script, the updates are reflected on your site instantly. However, if you don’t see the changes after publishing your script, try clearing your website data, cache, and cookies. This will ensure you're viewing the latest version of your site and the updated script.

Script Versioning:

OneTrust will release updates to the Cookie Consent script every 3 weeks. Changes are gradual and keeping up with new releases allows your organization to access and utilize new features and enhancements, so it is recommended to publish on a frequent basis, usually every 3 months or aligning with your scheduled updates for your website. You can select the script version to publish in the Choose script version to publish field within the Publish pane to ensure you're using the most up-to-date version.

Review incompatibilities features:

If you decide to publish the script using an older version, be sure to review the incompatible features listed in the Publish pane. A comparison between the selected version and the latest available version will be provided, allowing you to identify any potential issues before publishing.

If you have cookies that are set directly in your website Source Code, use either Autoblock or JavaScript rewrite:

Autoblock

This option uses the information collected by the scanner: the cookies and source URLs for the cookie. So, you don’t have to make code changes to individual elements that create cookies on your website. However, you need to implement the OneTrust script in the website source code for it to work and not via a Tag manager. See if you meet the requirements to implement by reviewing the following documentation:Is Auto-Blocking Appropriate for Your Domain?

JavaScript rewrite

Use this method when you need to control individual elements on your source code. You need to manually adjust the script tag or iframe tag on your source code with category IDs. For more information, seeClient-Side Cookie Management.

Note:

The recommendation is to use this blocking method if you would prefer to have more granular control over your blocking set-up.

If your Cookies are set via a Tag Manager:

• To manage the blocking directly on your Tag Manager, you need to group tags into categories with the respective firing conditions so they fire only when this category is enabled. You also need to ensure that for any new cookie tags added, you need to assign the respective condition to enable/block based on the category.

Test your cookie blocking:

Test if your blocking is working

It is helpful to test your blocking by replicating the experience of a new site user. Consider testing in an incognito window, or if in a regular window, inspect the page, clear site data and cache. Next, review the cookies that are dropped on your browser before consent is given in Dev Tools > Application Cookies. Assuming an Opt-in model, if you see cookies dropped before consent is given, try deleting these individual cookies and refreshing the page to see if they drop again. If they drop again, this means the blocking is not working for these cookies, so you need to review the configuration. For more information, seeTesting Your Cookie Blocking Implementation.

Testing Autoblock

After implementing Autoblock, if you still see cookies dropping on your browser, find which script generates the cookies and check if the source URL for that script is inside theAutoblock.js. If this is not there, then you will need to assign this to the respective cookie.

Test your Tag Manager blocking

If your tag manager allows you to preview before publishing the changes, use this to see if the tags are firing correctly.

Test your JS Rewrite blocking

When testing your source code blocking, look at the individual elements on the DOM by inspecting the page and finding the HTML elements to see if they change from text/plain to text/javascript when consent is given. When rejecting consent, you will need to refresh the page to see if it is reverting back to text/plain. You can see if the cookies are dropping before consent under Application > Cookies.

Why are cookies not removed after withdrawing consent

Cookies can still display after withdrawing consent as they get saved on the browser. To confirm if they are really active, you can delete them and refresh the page. If they return, it means the script that creates them is still active after rejecting, so the blocking is not working correctly. If they don’t return, it means they were just saved on the browser from the moment when consent was given.

Monitor your website analytics

If you see no impact in your analytics after implementing the CMP, then it might indicate the cookies are not getting blocked. A big drop in your analytics might indicate something is not configured properly with the firing, so some tags might not be firing properly.

Use the OneTrust Live Preview

Use the Preview when publishing to see what the latest changes look like in your live website. For this to work, you need to have the Production script already implemented on the live website so you can test the new changes in preview before publishing the production script.

Google Consent Mode:

• If you’re using Google Consent Mode Advanced, be transparent in your cookie policy by explicitly stating that anonymous data may be collected before consent is granted. Clearly inform users that more detailed tracking, such as personalized ads or advanced analytics, will only begin after they have provided their consent.

Test only one element at a time:

Focus on changing one aspect (e.g., layout or color) in each test to isolate the impact of that change on opt-in rates. For example, start by testing different layouts before moving on to other elements.

Enable email notifications:

Set up notifications to receive alerts when A/B tests are completed, so you know when results are ready to review.

Iterate and refine based on test results:

Continuously improve your banner by applying insights from each test. Refining your design over time can increase consent opt-in rates and enhance the user experience.

Use Unique User Identifiers:

When a user is identified (e.g., via login), pass a unique identifier (such as email or user ID) to OneTrust before loading the OneTrust script or SDK. This ensures consent profiles are properly synced across platforms.

Use the same purposes:

The recommendation is to ensure purposes are consistent across your digital assets (for example websites and mobile applications).

Test functionality: After setting up the solution, verify that this is working correctly by using your browser Dev Tools to check the syncing of user preferences under the network call with URL https://consent-api.onetrust.com/v1/preferences?syncgroup=.

Monitor banner reappearances:

The consent banner should not reappear if users already consented. However, if a new category is introduced, ensure the banner reappears so consent can be given for the unaddressed categories. For more information, see Cross-Domain and Cross-Device Consent.

Authenticate users:

Convert anonymous users into known profiles by using a consistent identifier (e.g., email or user ID). This ensures all consent preferences are tied to the correct user across platforms.

Integrate consent data into downstream systems:

Ensure that consent data is securely backed up and integrated into downstream systems. Use integration workflows to automatically send consent preferences into these other systems.

Review prerequisites:

Before implementing this functionality, ensure you have the necessary infrastructure in place, including Cross-Domain and Cross-Device Consent setup and secure user authentication methods. For more information, see Connecting CMP Preferences with Universal Consent & Preference Management Profiles.