As internet users, we often face cookie consent banners when visiting a website. This is a legal obligation, and these devices offer users the choice to share or not share their browsing information, which is good. However, this repeated solicitation can lead to fatigue and cause users to make mechanical choices out of habit. Worse, it could cause irritated visitors to refuse cookie deposits in their browsers automatically. This phenomenon is called consent fatigue.
The General Data Protection Regulation (GDPR) sets the maximum cookie lifespan to 13 months from the day they are deposited.
This means the cookie should not be extended when visitors return to your site. Cookies are often associated with advertising or analytical purposes. Still, they also save user actions, such as the cart on your favorite e-commerce site, login information for your streaming platform, and cookie choices. Theoretically, when you give or withhold your consent on a site, your choice is saved for 13 months.
However, the cookie banners are collateral damage of Safari’s ITP (Intelligent Tracking Prevention)
In 2019, Safari announced an update to its ITP, which restricts the lifespan of first-party cookies depending on the referral source. If the referring domain is a known tracker (or the URL contains UTMs), cookies deposited in the browser will have a maximum lifespan of 24 hours. In other cases, cookies will be deleted after seven days of Safari use without a visit to your site. Since the consent banners themselves rely on cookies to save the user’s choice, they are affected by these restrictions.
A Safari user visiting your site once a day from an advertising campaign would be asked for their consent on each visit. There is a high likelihood that a user who previously gave their consent will eventually stop doing so.
Fortunately, there is a solution that won’t disturb your visitors every time they come to your site: rewriting the cookies from your Google Tag Manager Server-Side container. The benefit? Safari does not restrict cookies to one or seven days if they are written from a subdomain of the main domain (such as measure.mydomain.com for the site http://www.mydomain.com).
So, the solution is rewriting the Axeptio cookie to extend it and not tire out your visitors.
The Axeptio module writes three cookies in the user’s browser: axeptio_authorized_vendors, axeptio_cookies, and axeptio_all_vendors. In the example below, all three cookies are deposited by the subdomain http://www.domain.com. This is problematic because the cookie must be placed on the main domain domain.com, not on the subdomain www, to be sent with the server transfer request.
Rewriting cookies from your Google Tag Manager Server-Side container allows you to avoid disturbing your visitors whenever they visit your site!
The benefit of this approach is that Safari does not restrict cookies to 1 or 7 days if they are written from a subdomain of the main domain (for example, measure.mymaindomain.com for the site http://www.mymaindomain.com).
Enough theory; let’s see how to implement this!
Rewrite the Axeptio cookie to extend it and not wear out your visitors. Our Axeptio module writes three cookies in the visitor’s browser:
- axeptio_authorized_vendors
- axeptio_cookies
- axeptio_all_vendors
In the example below, all three cookies are deposited by the subdomain http://www.domain.com. This is problematic because for the cookie to be sent with the transfer request to the server, it must be placed on the main domain domain.com, not the subdomain www.
We will download the Axeptio cookies template from the GTM tag templates community gallery to solve this issue.
This tag will replace the HTML installation code for the Axeptio module. This template allows you to define the cookie domain. Therefore, you can choose domain.com instead of http://www.domain.com.
Now, the three Axeptio cookies are correctly sent to the server with the request. This can be seen in the debug mode of Google Tag Manager Server-Side, in the incoming request within the Cookie section.
Now that we are sure the three Axeptio cookies are correctly sent to our tracking server, we can protect them from Safari’s restrictions.
To do so, download the Cookie Extender tag template from the community gallery.
We can then configure the tag by adding the parameters shown below:
We set the lifetime of the three cookies to 34187400 seconds, which corresponds to 13 months (remember, it’s the limit set by the GDPR 🙂 )
We also check the box to create a backup cookie. This would restore the main cookie if it were to be deleted by Safari’s ITP.
Finally, let’s trigger this tag on every server event.
And voilà! Our Axeptio cookies are extended to 13 months, even on Safari!
Although this process may seem somewhat complex, it is essential not to tire your visitors and cause this consent fatigue.
