After going live with OneTrust Cookie Consent on a website, it is essential to take steps to maintain the implementation.
If new content is being added to the site or changes are being made to the configurations within the Cookie Consent application, action will need to be taken accordingly.
Appointing a OneTrust Super User
To keep the OneTrust platform running smoothly, it is recommended to appoint a OneTrust Super User. This person:
Is trained on the OneTrust platform during implementation.
Completes OneTrust certifications.
Stays up to date with product updates and new features.
Acts as first-line support for internal users when issues arise.
Leverages OneTrust self-service support resources.
Rescanning and Evaluating Content for Blocking
If the person or team managing the Cookie Consent application is not aware of the content being added to the site or the cookies that will be dropped by newly added content, make sure to rescan the site at a frequency that makes sense for the team.
For example, if there is a code released to the site or the tag manager updates once a month, the best practice would be re-scanning the domain once a month after the release. For more information about scheduling scans, see Scanning a Website.
After the rescan is complete, export the scan results. Manually compare the new scan export with previous scan exports to see if there are any additional cookies added to the website. If there are additional cookies, identify which scripts or tags these cookies are coming from and apply the proper blocking methods. For more information, see Client Side Cookie Management and Integrating with Google Tag Manager.
You can utilize the scan export resource URLs when reevaluating. There are two methods for checking the URLs:
For more information, see Managing and Categorizing Cookies.
It is not necessary to republish the script for blocking new cookies unless the cookie belongs to a category that is not yet present in the Preference Center or OneTrust Cookie Auto-Blocking™ is being used for blocking cookies. Also, if the Auto-Blocking feature is being used, it is necessary to test the functionality of the auto-blocking with the Testing script on a staging or preproduction site prior to publishing the production script. For more information, see Publishing and Implementing Cookie Consent Scripts.
Example: I only have cookies categorized in the Strictly Necessary category and the Performance category. Only these two categories are shown in my Preference Center. I manually add a Functional cookie and associate it with my domain in the Cookie Consent application. After I add my new Functional cookie, I must republish my script to ensure that the Functional category is displayed to the users in my Preference Center. That way, users can opt in or out of the Functional category and the script will fire or not fire based on my configured blocking method.
Configuration Changes to Categorization, Templates, Geolocation Rules and Republishing
Removing Old Cookies
Over time, as more scans take place for a particular domain, there may be cookies that are no longer found within the domain. These cookies are now redundant and serve no purpose within the domain. For best results, you can remove these cookies from the application on a regular schedule to maintain an accurate inventory of cookies.
For more information, see Managing and Categorizing Cookies.
Changing Cookie Categories
In order for a cookie category to appear in the Preference Center, it is necessary for the category to have at least one cookie assigned to it. You must republish the script whenever a cookie is assigned to a category that has not been previously used for that domain. This enables the user to provide or revoke consent for the newly added category.
In case it is necessary for all users to provide their consent again due to the addition of a new category, ensure that the setting Do you require users to reconsent? is selected in the Publish pane. For more information, see Publishing and Implementing Cookie Consent Scripts.
Make sure to implement the proper blocking methods for the newly categorized cookie. For more information, see Client Side Cookie Management and Cookie Consent Integration with Google Tag Manager.
Example Scenarios:
Note
If you make any configuration changes to a template or geolocation rules, you will need to republish the script.
I have created a category group and added the Performance and Targeting cookie categories as subgroups. I must republish the script to ensure the new category group is displayed.
I updated the Notice Description text on my banner. I now need to republish my script.
I added an additional geolocation rule to my geolocation rule group that is associated with my domain. I now need to republish my script.
Script Software Versioning
Another reason to republish the script regularly is to allow the latest software updates to take effect. The software version for the OneTrust application is updated approximately once every month, and each release may include useful functionality. The version being used for your scripts can be selected within the Publish pane, in the field Choose script version to publish. For more information, see Publishing and Implementing Cookie Consent Scripts.
Note
If you choose to publish a script without updating, the incompatible features between the latest version available and the version currently selected will be shown.
Example: A feature that would allow for functionality beneficial to use case has been added in the latest release. I now need to update the script version I want to publish and republish my script.
To see what is included in the latest release, see the latest OneTrust Release Notes.
Live Preview Mode
Live Preview feature is a feature that allows for the viewing of changes that are being tested. For this feature to function, the CDN banner script will already need to be implemented onto the domain you wish to view.
For more information, see Using Live Preview to Perform Real-Time Testing.
Add the Blocking Methods to Standard Operating Procedures for New Site Content
Another way to maintain the implementation for new site content is to add the blocking methods to the standard operating procedure for adding new site content.
Example: If the team is adding a tag to Google Tag Manager that is dropping cookies that fall under the Targeting category, you can apply the appropriate trigger to the new tag so that tag is only fired or only drops the cookies when the Targeting cookie category is active. For more information on blocking, see Client Side Cookie Management and Cookie Consent Integration with Google Tag Manager.
You can rescan your site to get the new cookie into the Cookie Consent application for tracking, or add the cookie manually. For more information about scans or adding cookies, respectively, see Scanning a Website and Managing and Categorizing Cookies.
For any assistance required post implementation, the following methods can be used to reach out to the support team.
To create a support case in myOneTrust
Navigate to my.onetrust.com
-
Click Get Help at the top of the screen. The Tell us about your issue screen appears.
Click a tile to select the relevant topic for your inquiry.
Enter your question into the Search field.
Review the results.
-
If FAQs do not resolve your question, click the Create Support Case tile.
For more information, see Creating a Support Case in myOneTrust.
To create a support case in the OneTrust application
Log in to the OneTrust application.
-
Click the Help icon 
in the top right corner.
-
Select Get Help
-
Click the Contact Us button at the bottom.
Enter you message to support.
Click the Send button.
For more information, see Contacting OneTrust Support.
In order to ensure that your query can be handled as effectively as possible, please collect the following information before you raise your case:
Environment URL (e.g., app.onetrust.com/app-eu.onetrust.com)·
Tenant GUID. You can find this in the application by clicking Account ID when entering your message to support.
Which module the query is related to (if applicable).
A description of the issue you are facing. Please be as detailed as possible.
Your expected result.
Steps our support agents can take to replicate your issue. Please be as detailed as possible and include screenshots or screen recordings.
Permission to access the tenant (if applicable).
If your issue is related to an integration, the URL or other platform where you are experiencing the issue.
The severity of the impact.
If other team members have experienced the issue.
If HAR is required, see Creating a HAR File for Troubleshooting.
