For the complete documentation index, see llms.txt. This page is also available as Markdown.

Cookie 1st

  • First-party cookies sont stockés par le domaine (site web) que vous visitez directement. Ils permettent aux propriétaires du site web de collecter des données analytics, de mémoriser les paramètres de langue et d'effectuer d'autres fonctions utiles qui aident à offrir une bonne expérience utilisateur.

  • Third-party cookies sont créés par des domaines autres que celui que vous visitez directement, d'où le nom third-party. Ils sont utilisés pour le suivi inter-sites, le retargeting et l'ad-serving.

Jusqu'à présent, toutes les données collectées sur un site web l'étaient principalement par des tags, des 3rd party tags, car les données sont envoyées vers des serveurs externes (qui n'appartiennent pas à la marque mais à certains partenaires).

Les principaux navigateurs, tels que Safari ou Google Chrome, ont décidé de ne plus autoriser les 3rd party cookies. Cela signifie qu'ils bloqueront les cookies ne provenant pas de la marque elle-même mais de partenaires (tels que Commanders Act). Ils détecteront tous les flux de données envoyés vers un domaine sans lien avec la marque (3rd party domains).

Par conséquent, la solution de contournement pour continuer à suivre et à envoyer des données des sites web vers des partenaires consiste à utiliser un domaine appartenant à la marque, un 1st party domain. Et les cookies doivent être définis par ce domaine, c'est ce qu'on appelle un '1st party cookie' car il semble être généré par la marque elle-même et non par des partenaires.

Il y a une configuration technique à réaliser pour initialiser ce tracking 1st party (d'abord au niveau du domaine puis au niveau du cookie).

Quelle configuration doit être réalisée ?

Dans le DNS du client, l'utilisation d'un CNAME pointant vers un serveur Commanders Act permet de définir cookie comme First party.

Le client doit créer un sous-domaine et configurer des entrées CNAME pour pointer vers notre serveur (et créer autant de sous-domaines que de domaines existants). Exemple :

client.com crée un sous-domaine XYZ.client.com pointant vers le serveur Commanders Act. Désormais, nos tags appelleront XYZ.client.com à la place de notre domaine 3rd party (commander1) et la réponse définira un cookie sur le domaine principal.client.com ce qui est autorisé par les principaux navigateurs web.

Merci ensuite d'indiquer le sous-domaine sur notre plateforme : Administration > Gestion des domaines.

Le client doit décider si le chiffrement SSL sur le nouveau sous-domaine créé est effectué avec 'Let’s Encrypt' ou avec son propre certificat. Dans le premier cas, rien à faire ; dans le second, suivre les instructions sur la page de gestion des domaines.

De plus, modifiez sur chaque tag l'URL pour spécifier le domaine 1st party.

Gérer MixCommander

Gérer les tags MixCommander

Mettez en place les tags MixCommander comme vous le feriez normalement, mais cette fois utilisez les tags marqués COOKIE 1ST V1.0

Dans l'espace réservé #CUSTOMER_SUBDOMAIN#, vous devez saisir le sous-domaine convenu avec le client.

Gérer le suivi MixCommander

À ce stade, il est temps de tester les hits. ATTENTION, la structure de l'URL de redirection est différente de la MixCo habituelle.

avant, c'était : http://client.commander1.com/c3/?tcs=13&chn=sem&src=google&url=https://domain.client.com/en/13/campaign/trafficking

Maintenant, c'est : https://client.subdomain.com/mix/c3/?tcs=13&chn=sem&src=google&url=https://domain.client.com/en/13/campaign/trafficking

Comment se déroulera la migration de 3rd party vers 1st party ?

Il existe 2 situations possibles que nous pouvons rencontrer :

  • Utilisateurs avec un cookie 1st existant

C'est la configuration cible lorsque les cookies 3rd auront disparu.

Le navigateur poussera le cookie vers le 1st party domain, celui-ci reconnaîtra le cookie, le mettra à jour puis le renverra au navigateur. Ensuite, les données liées au cookie sont envoyées à notre système.

  • Utilisateurs sans cookie 1st existant

Ce cas est hybride, car nous travaillerons à la fois avec des domaines 1st party et 3rd party afin de maintenir une continuité des informations partagées entre les 2 serveurs.

Dans ce cas, nous avons des utilisateurs sans cookies connus par le domaine 1st party.

Le navigateur poussera les données vers le domaine 1st party, et nous demanderons sur le domaine 3rd party toutes les informations que nous avons concernant cet utilisateur (un cookie existe-t-il déjà ?). Le domaine 3rd party poussera cette information (si elle existe). Ensuite, le domaine 1st party configurera le cookie (ou en créera un nouveau) et les données seront envoyées à notre système.

Il est maintenant possible d'utiliser une combinaison de cookies First-party et Third-party (créez un ticket pour demander à l'équipe MIX d'activer cette option) - disponible uniquement pour la transition.

Mis à jour

Ce contenu vous a-t-il été utile ?