When you add a domain to your Cookiebot account it will be scanned monthly. After the scan completes, your banner and instructions for the auto blocker (if you have it enabled) will be updated, and you will receive a scan report.
You can find all scan reports in the Manager: reports.
If the scanner has determined that there are compliance issues you will be notified in an email that starts with:
Please find attached your Cookie Report.
Our recent scan of your website has identified potential compliance issues where cookies are being set in your users’ browsers before their consent has been submitted. Under GDPR and other legislations, only cookies that are strictly necessary for the website to function can be set prior to the user’s consent.
Domain Group: Demo Domain Group
- https://www.example.com (25/05/2018) - Prior consent fully enabled: no
Further down there will be a few common issues and their corresponding solutions, but these may not apply to you.
To determine the actual problem you will need to consult the scan report.
The cookie scan report
The report has a short summary with details about the scanned domain, a thumbnail displaying the landing page, and the number of cookies detected.
This information will likely contain anything that might help you understand what compliance issues were detected, but if the thumbnails does not resemble your website's landing page this may indicate that a special configuration of the scanner is required. Please contact our support team if this is the case.
It is worth noting that we use "cookies" as an umbrella term for all sorts of detectable trackers, such as HTTP cookies, HTML local storage, tracking pixels, etc. The actual tracker type is listed on the individual cookie.
All cookies in the scan report are listed under one of these 5 categories:
- Necessary info
Cookies in this category are vital for the normal functioning of the website, or to provide a service the website is intended to provide. For this reason cookies in this category do not require consent.
This means that elements that exclusively set necessary cookies will be allowed to load prior consent. However, if an element sets both necessary and preferences, statistical, or marketing cookies, it will be blocked until all included categories are accepted.
Whether or not a cookie belongs in this category depends on the service a website is meant to provide, so a cookie can be necessary on one website, but not others.
Cookiebot CMP's CookieConsent cookie is an example of a necessary cookie. Without it, you would be asked for your consent on every single page load, practically rendering the website inoperable.
- Preferences info
Cookies in this category are meant to save settings.
Elements setting cookies that include this type of cookies require consent before they are allowed to load.
An example of a preferences cookie could be one that saves color schemes, personalized menus, etc. Cookiebot CMP's bulk consent cookie is also an example of a preferences cookie, it remembers a visitor's consent choices and passes it to other related domains.
- Statistics info
Also referred to as analytical or measuring cookies. These are intended to measure the performance of the website in terms of numbers of visits, retention time, etc.
Elements setting cookies that include this type require consent before they are allowed to load.
- Marketing info
Also referred to as ads cookies. These are intended to match visitors to products or services, to optimize the effectiveness of advertisement.
Elements setting cookies that include this type require consent before they are allowed to load.
- Unclassified info
This is actually not a cookie category, but reflects the lack of one. Since the actual purpose of the cookie is unknown and could in fact be vital to the normal functioning of the website, elements that exclusively set unclassified cookies will not be blocked prior consent, these cookies will however be removed at every page load.
If an element sets a combination of unclassified and cookies in other categories, the elements will be blocked until all included categories are accepted.
Every cookie found during the scan is listed individually, under the corresponding category, sorted alphabetically.
Every cookie has the following information:
- name info
The name or "key" of the tracker.
- provider info
This part is often confusing, since a provider is different things in different contexts. In the scan report, the provider is the domain on which the cookie is set. In the case of a first party cookie the provider will always be the website's domain.
For example, the CookieConsent cookie is set by the uc.js script, which is fetched from https://consent.cookiebot.com. Cookiebot is the provider of the resource that sets the cookie, but the cookie is not set on consent.cookiebot.com or cookiebot.com.
So "provider" implies the provider of the cookie, not the provider of the resource that sets it.
- type info
The Cookiebot scanner finds trackers of the following types:
HTTP : HTTP Cookie HTML : HTML Local Storage FLSO : Flash Local Shared Object SIS : Silverlight Isolated Storage Pixel : Pixel Tracker IDB : IndexedDB Audio : Ultra Sound Beacon
- expiry info
This is the lifespan of the cookie. Session means that it only lives during a visit, persistent cookies live until they are removed, and all others have a fixed number of days, weeks, months, or even years.
While this information is useful, it can not help help you identify compliance issues. The remaining information can help you in this regard though.
These issues will be indicated with red text at the bottom of each cookie listing.
There are two issue that the scanner is capable of detecting:
- Data is sent to: country name ( not adequate )
- Blocked until accepted by user: No
Here is an overview of compliancy issues and what you can do to fix these:
If data is transferred to a country that is deemed not adequate under GDPR you need to explicitly inform and ask for your visitor's consent.
Adequacy under GDPR is a difficult topic beyond the scope of this article, but please see Send personal data to adequate 3rd countries and Data transfers between EU and US.
There can be a number of reasons why a cookie is not blocked prior consent.
Before we go any further it is important to understand that Cookiebot CMP does not actually prevent cookies from being set by intercepting them, instead it disables the element that sets the cookie until the Cookiebot script determines the visitors level of consent.
Since it is quite possible that you do not know where a cookie comes from, the information in the scan report can help you identify and, if needed, manually block the resource if the auto blocking feature fails to do so.
The following information should help you identify the resource that sets the cookie:
- First found URL info
This is the first page where the cookie in question was detected. Start your search by clicking the link and visiting the page.
- Cookie purpose description info
This will not help you locate the element, but it may give you an idea what to look out for and what the appropriate category is for the cookie.
- Initiator info
This tells you what set the cookie, this can be a webserver, or and element like a script, iframe, image, etc. In the latter cases there may be a line number which helps you locate the element in question.
- Source info
In the case of third party resources, the source (src) is listed here.
- Via info
If a resource is loaded through another resource, for example a tag manager solution, it will be listed here.
If a cookie that is not blocked prior consent is loaded via a tag manager solution, you likely have not configured tags to load conditionally.
If you do not make use of the auto blocking feature, the initiator needs to manually "marked up" to disable it and to allow the Cookiebot script to enable them after consent is given. The information in the scan report will be helpful to perform this task. Manual mark up is described in detail in the Manual Markup Guide.
With auto blocking enabled, things become significantly more complex.
First, you need to determine that the auto blocker has instructions to block the element which sets the cookie. The instructions for the auto blocker are found in the configuration.js file, the link to it will always look similar to this: https://consentcdn.cookiebot.eu/consentconfig/00000000-0000-0000-0000-000000000000/domain.com/configuration.js
Inside you'll find one or more lines similar to this:
A lot of this information is not meant for human reading, so we will cover only the information that is of interest for us:
- type info
This is the type of element that the auto blocker intends to block. These can be scripts, images, or iframes.
- url / resolvedUrl info
This is the link to the resource. this should match the source from a cookie listing in the scan report.
If a cookie is listed as not blocked prior consent's source is not included in the file, then this explains why the cookie is not blocked prior consent.
If the URL incudes version numbers or a dynamic component that is prone to changes between scans, the element's URL and the URL listed in the configuration.js file will not match and the element will subsequently not be blocked.
- cat info
This will show what categories of cookies need to be accepted for the resource to be unblocked.
Here is an overview of the categories:
If a resource exclusively sets category 1, 5, or both it won't be blocked prior consent. However if a combination of cookies is set including categories 2, 3, or 4 then cookies in these categories must be accepted for a resource to be allowed to load, even if this includes category 1.
This information can be used to determined why a resource is not being blocked prior consent.
If the file is empty, then there are no instructions available for the auto blocker. In some cases performing a new scan can resolve this issue, since the configuration.js file is populated after every scan.
Empty configuration.js files can be due to a scan failing to complete or being terminated prematurely or there not being anything to block using client side scripting.
Performing a new scan may resolve the issue, but if you consistently receive scan reports that indicate unblocked cookies and determine that the configuration.js file remains unpopulated you may need to contact support to have us look into possible issues preventing the scanner to properly create instructions for the auto blocker.
If a resource exclusively sets unclassified cookies, the resource will not be blocked prior consent and the report will indicate this as a compliance issue.
Make sure that no cookies are unclassified to resolve this issue. You can assign cookies on the cookies tab in the Manager: cookies.
If a cookie name contains a dynamic component that is subject to change after every scan, or if you see a large number of similarly named cookies that are unclassified a rule may need to be set up to consolidate these cookies into a single entry that can be assigned a category. Please contact support to set up such a rule if you suspect that you have a dynamically named cookie.
If a cookie which is listed as not blocked prior consent has a source listed, try to find a reference to it in the configuration.js file. If there is no reference to the resource, a new scan may need to be performed to update the instructions file.
If there is not an exact match you may need to manually mark up the resource to ensure that the resource is consistently blocked prior consent, even if the URL to the resource is not static.
For the auto blocking feature to be able to block a resource, the Cookiebot script needs to be fully loaded before cookie setting resources start loading. If a cookie setting resource manages to load before the Cookiebot script does, cookies will be set prior consent.
If you make use of the auto blocking feature, you need to ensure that the Cookiebot script is the first script to load and that it is fully loaded before other scripts start loading. Therefore, the Cookiebot script should not be loaded asynchronously or be deferred. Make sure that the Cookiebot script doesn't have
The auto blocking feature respects manual mark up. That means that if an element has the
data-cookieconsent attribute, the auto blocker will assume that you manually marked up the resource and will not attempt to block it. If you forgot to add set the
type to text/plain for scripts or replace the
src attribute with
data-cookieblock-src for images/iframes, the element will load prior consent and be able to set cookies.
If you marked up an element with
data-cookieconsent="ignore" the auto blocker will allow it to load immediately. If the resource sets cookies, it can do so without consent.
If tags within Google Tag Manager (or a similar tag manager solution) do not have any conditional loading (based on user consent) configured, they will likely be able to set cookies prior consent.
In your cookie report you may have cookies that are set by your webserver, also known as “server-side cookies”, these are marked like this:
Cookiebot CMP, being a client side solution is not capable of blocking server side cookies. Therefore, you need to block cookie setting resources through server side code. You may need to reach out to your webhost or web solution vendor to find out more about how you can block these cookies.
See the last part of our developer documentation for server-side usage of Cookiebot.