Cookie Deletion Upon Consent Rejection
Management Summary
Since the introduction of the GDPR on May 25, 2018, cookie banners have become an integral part of websites in the EU. Almost every page has them: Agree, Reject, Further settings – these three options are usually displayed when you first open a website. As an EU user, a selection is forced. Clicking away is usually not possible.
But what happens if consent is first given and then withdrawn? Are all traces of trackers and 3rd parties on the visited site deleted, or do these traces remain until consent is given to the site again?
This is how cookies are set, source: e-dialog
Cookies are not deleted
If consent is first granted for all or just individual services and then withdrawn again,… nothing happens.
The website may then simply no longer use third-party services on the website. This means that pixels such as GA4, Google Ads, the Meta/Facebook Pixel and everything that can somehow be loaded by third parties can no longer be used on the website. But when consent is granted for the first time, cookies are set by these tracking tools.
The setting of cookies is differentiated into
- 1st party context
- 3rd party context
When setting cookies in the 3rd party context, a cookie is not set under e.g. e-dialog.group, but under the domain of the tracking pixel, for example google-analytics.com. The setting of cookies in the 3rd party context is being blocked by more and more browsers and will almost certainly be completely deactivated in the future.
The reason for the data protection problem with 3rd party cookies is the widespread availability of these cookies, which makes user profiling very easy to implement. A 3rd party cookie, which would be set under google-analytics.com, could be read and used on any other site every time GA4 is accessed.
This is one of the reasons why GA4 only uses 1st party cookies.
When setting cookies in the 1st party context, we are talking about cookies that are set directly under the domain of the page visited, i.e. in the context of e.g. e-dialog.group.
When granting consent on a website, consent is given that content from third-party providers can be loaded on the website. Pixels are loaded and they in turn set cookies.
If consent is later withdrawn, these cookies remain stored on the machine/device (desktop, tablet, cell phone, smart TV, smart car screen, smartwatch, etc.) but are no longer sent to third-party providers.
What happens if consent is rejected after prior approval?, Source: e-dialog
Cookies remain when rejected – what effect does this have?
It can now be assumed that these cookies can be declared “dead” because the values (e.g. IDs, identifiers, keys) that are used to identify users can no longer be forwarded to the various tools.
However, the cookies are still there and the nature of the HTTP(S) protocol means that every time there is communication with the website server, all cookies that have been set in the browser must be exchanged. Every time a website is accessed, every time a resource on a website is accessed, all stored cookies are automatically transmitted by the browser to the web server.
What resources does a website have?
- The page itself consists of HTML, which is provided by the server when it is initially accessed
- Multimedia, images, videos
- JavaScript files
- Fonts
- HTML content that is loaded into IFrames
Every time a resource is called up, the server is informed via the HTTP header which cookies are present in the 1st party context, e.g. e-dialog.group.
How do leftover cookies behave? All cookies are transmitted for all HTTP resources (HTML, images, JS). Source: e-dialog
Now our web server in the background can continue to use this information, send it to server-side tracking and thereby restore the tracking even though the consent was rejected via the Consent Management Platform (CMP).
Why don’t the CMPs delete the cookies?
From the perspective of a consent management platform (i.e. a CMP provider), this can have several reasons:
1. Different pixels set many different cookies
It could prove difficult to reliably delete all cookies from every pixel without removing important, technically necessary cookies. For example, the Google Analytics 4 pixel sets the “ga” and “_gid” pixels, which would be easy to delete. However, it sets 3-4 other cookies such as “_ga_27YEXKDRRJ”, “_ga_4JV80G7R91”. These cookies could also be recognized by the prefix “_ga_*”. However, there is a risk that too much could be deleted.
2. trivialization, trivialization
Some CMP providers are of the opinion that consent for the setting of cookies was granted in the past and deletion after a subsequent rejection is unnecessary, as the website owner must ensure that the third-party pixels are no longer allowed to be loaded, thereby making these cookies obsolete.
The CMP provider assumes that the cookies are “dead” and are no longer used.
3. Keep cookies, collect more data
If the cookies are not deleted after rejection, it is possible that a user will give their consent again at some point in the future. Something exciting happens here: All IDs in all cookies wake up from their deep sleep and come to life again – the user is simply continued to be recorded with the previous IDs, as if there were no interruption in tracking.
Can the cookies be deleted if they are rejected?
Yes. This can be set up using Google Tag Manager.
In order to delete the cookies when consent is rejected, the following conditions must be met:
- List of all cookies set by pixels that need to be deleted
1.a. The list needs to be continually maintained as new pixels are added or removed - The Google Tag Manager must be loaded on the page where the consent is rejected.
- The Consent Management Platform (CMP) must push a corresponding signal into the dataLayer so that a trigger in the GTM can listen to the signal
- Appropriate logic must be built in the GTM that becomes active when the signal from the CMP is received. All cookies must then be deleted one after the other.
Can cookies be deleted after rejection even with server-side tracking?
Yes. Even with server-side tracking, all cookies can be completely removed. Here the logic for deleting the cookies would then be carried out by the server-side tag manager in order to also delete cookies that are not accessible via JavaScript. An example of such a cookie would be the “FPID” = First Person ID cookie, which is set by default when using the server-side Google Tag Manager.
The “FPID” cookie is set as “httpOnly = true”, which makes deletion via JavaScript code in the client-side GTM not possible. The deletion must therefore take place in the server side GTM.
With its custom client templates, the Server Side GTM offers so-called sandboxed scripts that can be built and used for exactly this purpose.
Conclusion
If cookies remain stored after accepting and subsequently rejecting consent, they will continue to be transmitted in communication when further website visits are made. This can raise data protection issues. In this case, we recommend deleting cookies if you decline consent.
