I've been working on implementing OneTrust within our organization for the better portion of two months now and needless to say, it's been quite the learning process. At first, I was under the assumption that you could just "set it and forget it" after loading the script into our site code, but proved not to be the case. What I've found out going through this process is there is a certain way that doing a cookie consent initiative with OneTrust is more of a phased approach rather than just adding some scripts and calling it a day. Overall, here's what I've learned so far in hopes that it might help the OP, or someone else who happens to stumble upon this. This is a very abridged set of information as most of this could be found within other corners of the internet, but I wanted to at least share some of my trials and tribulations with setting up OneTrust.
Scan Site
When first setting up a site within OneTrust you need to scan the site for all cookies that are persistent. Depending on the size of the site, this could take a few days. Once that is done, it will have collected every cookie it can and then cross reference that with Cookiedatabase.org and will start to auto-classify some of the well-known ones that it can reference to. What you will need to then, is to categorize the cookies that are necessary, functional, targeting, and/or social. This is what makes OneTrust aware of any other cookies that it cannot associate within the cookie database and will associate them moving forward. One thing to note is that some of the descriptions that get pulled in from the cookie database are not exactly correct and have a tendency to mis-categorize some cookies for other ones. So, it's important to check (and re-check) this from time to time to make sure that you are categorizing certain cookies specifically for what they are supposed to be (e.g. - necessary, functional, etc). It's good to look them up separately to be sure.
Install Script and Testing
According to the OneTrust docs, the OneTrust script "needs to be installed as the very first script above all else...". If you can do this, great. If not, then it's not the end of the world, as I have tested this every which way, and it still seems to work if it's above or below some other scripts. It does need to be in the <head> of your site, but it doesn't have to be the absolute first thing that loads. In my use case, we have it loading through Google Tag Manager set as a high-priority and it works fine, but you need to do some extra JavaScript stuff to make it load within the <head> of the site otherwise it will error out. See this post for more details: https://www.simoahava.com/analytics/add-html-elements-page-programmatically/
When you generate the scripts to embed on the site OneTrust will generate a production script and a testing script. If you want to test to see how OneTrust will interact with your site and cookies, the best thing is to use the testing script to start with. That way it keeps the reporting separate and allows you to get a better idea of how it will interact with cookies overall. A simple test is to embed a simple cookie within a page on a site and within the class="optanon-category-C000X" you can update to the specific class category (e.g.- replace the X with the number of the specific category: C0004 or C0002).
<script type="text/plain" class="optanon-category-C000X">
document.cookie = "TestCookie" + "=" + "Test_CookieHere!";
</script>
The action here is that when the site load with the test cookie, it will change the text/plain to text/javascript. If you have the class set to a targeting cookie, for example C0004, then if a users decides to opt out, then that will flip from text/javascript to text/plain. Then any further interaction will stop with that cookie moving forward.
Auto-blocking and Other Notes
OneTrust has and option for turning on auto-blocking when setting up the scripts to implement. This is allow you to leverage OneTrust's abilty to auto classify and append the classes to scripts that it either has identified within the cookie database or other cookies that have been categorized within your account. The premise behind this is to have OneTrust automatically find cookies within your site without the need to manually update any other scripts that could be added or changed in the future. Overall, it's a useful feature, but you need to be careful since it could start autoblocking necessary scripts (e.g. - jQuery, GTM) that could break your site. Also, since the cookie database isn't 100% correct all the time, it can also skip over some targeting cookies that may be floating around and are not being honored when a user opts out. So, it's important to run routine audits on your sites to make sure that specific cookies are categorized correctly. If you also have scripts within GTM, you might need to add some specific triggers so that they do not fire once a user opts out. This guide dives deeper into that: https://my.onetrust.com/articles/en_US/Knowledge/UUID-301b21c8-a73a-05e8-175a-36c9036728dc
