En tant qu'internautes, nous sommes souvent confrontés aux bannières de consentementcookie lorsque nous visitons un site web. Il s'agit d'une obligation légale, et ces dispositifs offrent aux utilisateurs le choix de partager ou non leurs informations de navigation, ce qui est une bonne chose. Cependant, cette sollicitation répétée peut entraîner une certaine lassitude et pousser les utilisateurs à faire des choix mécaniques par habitude. Pire, elle pourrait amener les visiteurs irrités à refuser automatiquement les dépôts de cookie dans leur navigateur. Ce phénomène est appelé fatigue du consentement.
Le règlement général sur la protection des données ( RGPD ) fixe le maximum cookie durée de vie à 13 mois à compter du jour de leur dépôt.
Cela signifie que le site cookie ne doit pas être prolongé lorsque les visiteurs reviennent sur votre site. Les cookies sont souvent associés à des fins publicitaires ou analytiques. Pourtant, ils sauvegardent aussi les actions des utilisateurs, comme le panier sur votre site de commerce électronique préféré, les informations de connexion à ta plateforme de streaming, et les choix de cookie . En théorie, lorsque tu donnes ou refuses votre consentement sur un site, votre choix est sauvegardé pendant 13 mois.
Cependant, le cookie les bannières sont des dommages collatéraux de l'ITP de Safari ( Intelligent Tracking Prevention )
En 2019, Safari a annoncé une mise à jour de son PTI, qui restreint la durée de vie des cookies de première partie en fonction de la source de référence. Si le domaine de référence est un tracker connu (ou si l'URL contient des UTM), les cookies déposés dans le navigateur auront une durée de vie maximale de 24 heures. Dans les autres cas, les cookies seront supprimés après sept jours d'utilisation de Safari sans visite sur votre site. Comme les bannières de consentement elles-mêmes s'appuient sur les cookies pour enregistrer le choix de l'utilisateur, elles sont concernées par ces restrictions.
Un utilisateur de Safari visitant votre site une fois par jour à partir d'une campagne publicitaire se verrait demander son consentement à chaque visite. Il est fort probable qu'un utilisateur ayant déjà donné son consentement finisse par ne plus le faire.
Heureusement, il existe une solution qui ne perturbera pas tes visiteurs à chaque fois qu'ils viennent sur votre site : réécrire les cookies de votre Google Tag Manager. Server-Side conteneur. L'avantage ? Safari ne limite pas les cookies à un ou sept jours s'ils sont écrits à partir d'un sous-domaine du domaine principal (comme measure.mydomain.com pour le site http://www.mydomain.com).
Donc, la solution est de réécrire le Axeptio cookie pour le prolonger et ne pas fatiguer vos visiteurs.
Le Axeptio module écrit trois cookies dans le navigateur de l'utilisateur : axeptio _fournisseurs_autorisés, axeptio _cookies, et axeptio _tous_les_fournisseurs. Dans l'exemple ci-dessous, les trois cookies sont déposés par le sous-domaine http://www.domain.com . Ceci est problématique car le cookie doit être placé sur le domaine principal domaine.com, et non sur le sous-domaine www, à envoyer avec la demande de transfert de serveur.
La réécriture des cookies de votre conteneur Google Tag Manager Server-Side te permet d'éviter de déranger tes visiteurs à chaque fois qu'ils visitent votre site !
L'avantage de cette approche est que Safari ne limite pas les cookies à 1 ou 7 jours s'ils sont écrits depuis un sous-domaine du domaine principal (par exemple, measure.mymaindomain.com pour le site http://www.mymaindomain.com ) .
Assez de théorie ; Voyons comment mettre cela en œuvre !
Réecrit le Axeptio cookie pour le prolonger et ne pas épuiser vos visiteurs. Notre Axeptio module écrit trois cookies dans le navigateur du visiteur :
- axeptio _authorized_vendors
- axeptio _cookies
- axeptio _tous_les_fournisseurs
Dans l'exemple ci-dessous, les trois cookies sont déposés par le sous-domaine http://www.domain.com . Ceci est problématique car pour le cookie pour être envoyé avec la demande de transfert au serveur, il doit être placé sur le domaine principal domain.com, et non sur le sous-domaine www.
Nous allons télécharger le Axeptio modèle de cookies de la galerie communautaire de modèles de balises GTM pour résoudre ce problème.
Cette balise remplacera le code d'installation HTML pour le Axeptio module. Ce modèle vous permet de définir le cookie domaine. Par conséquent, vous pouvez choisir domain.com au lieu de http://www.domain.com .
Maintenant, les trois Axeptio les cookies sont correctement envoyés au serveur avec la requête. Cela peut être vu dans le mode débogage de Google Tag Manager Server-Side , dans la demande entrante dans le Cookie section.
Maintenant que nous sommes sûrs que les trois Axeptio les cookies sont correctement envoyés à notre serveur de suivi, nous pouvons les protéger des restrictions de Safari.
Pour cela, téléchargez le Cookie Modèle de balise d'extendeur de la galerie de la communauté.
Nous pouvons ensuite configurer la balise en ajoutant les paramètres indiqués ci-dessous :
Nous fixons la durée de vie des trois cookies à 34187400 secondes, ce qui correspond à 13 mois (rappelez-vous, c'est la limite fixée par le RGPD 🙂 )
Nous cochons également la case pour créer une sauvegarde cookie . Cela restaurerait l'essentiel cookie s'il devait être supprimé par l'ITP de Safari.
Enfin, déclenchons cette balise sur chaque événement serveur.
Et voilà ! Notre Axeptio les cookies sont prolongés à 13 mois, même sur Safari !
Bien que ce processus puisse sembler quelque peu complexe, il est essentiel de ne pas fatiguer vos visiteurs et provoquer cette fatigue du consentement.
