How cookie categories are assigned

The cookie repository

Usercentrics maintains a so-called cookie repository. This is essentially a library of sorts containing thousands of trackers with a default category and a purpose description.
The cookie repository is maintained by a research team that continuously investigates cookies that are found across multiple domains.

To determine the appropriate category and purpose the team often reaches out to the provider of the tracker in question.
In other cases the name and the value stored in the tracker can reveal its purpose and thus the appropriate category. For example, if a cookie is found named "mode" and has the value "dark", we can assume that this cookie saves the color scheme preference of the user and thus should be in the "preferences" category.

However, if neither the name nor the value provides any clue to the purpose of the tracker, but the tracker in question is always set by the same service provider (for example Google, or Meta), then the team can reach out to the provider and ask them if they would be willing to provide this information.
Service providers are often more than happy to provide this information and it also is the best guarantee that this information is accurate.

Dynamically named trackers

It's fairly common to see a tracker that has a (partially) dynamically generated key. This can cause our scanner find what is essentially the same tracker over and over, resulting in a large number of unclassified cookies.

To ensure only a single instance of this cookie is listed, and can be assigned a category we can consolidate trackers.

For example, let's say we have a cookie which name starts with "cookie", followed by 6 hexadecimal numbers. For example; "cookie-12ab34", "cookie-df456a", "cookie-1cbe93", etc.
Furthermore, these 6 hexadecimal numbers will be different on every page.

If we don't do anything and a website has 200 pages, the banner will list 200 unclassified cookies.
This is both inaccurate and makes it look as if you're using far more trackers than you actually are.

To avoid this, we can create a rule that essentially says: "If you see a tracker of a certain type, which name starts with 'cookie' followed by a dash and 6 hexadecimal characters (^cookie-[\da-f]{6}$), this is actually the cookie we call 'cookie-#' in the cookie repository".
So instead of seeing "cookie-12ab34", "cookie-df456a", "cookie-1cbe93", etc. you will actually only see a single mention of "cookie-#", where the "#" symbol represents the dynamic component.

(Re)assigning categories

There will often be cases where either a cookie isn't listed in our repository, or where our research team hasn't been able to determine the purpose of a cookie (yet).
In such cases you will see unclassified cookies. Since you can't provide informed consent if you have no way of knowing what exactly you are consenting to, an appropriate category should be assigned at your earliest convenience. You can read more about assigning categories to unclassified cookies in this guide.

It's also possible that the default category, which is suitable for most websites, isn't suitable in your specific case.

An example would be cookies associated with YouTube, they would not be strictly necessary on a website that sells dress shoes, but they would be necessary on a website that streams for example a podcast.

You can therefore change the default category that a tracker was assigned.