# Cookie 1st
## Qu’est-ce que cookie first ?
* **First-party cookies** sont stockés par le domaine (site web) que vous visitez directement. Ils permettent aux propriétaires de sites web de collecter des données d’analyse, de mémoriser les paramètres de langue et d’effectuer d’autres fonctions utiles qui contribuent à offrir une bonne expérience utilisateur.
* **cookie third-party** Ils 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 cross-site, 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 qui ne viennent 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 non lié à la marque (3rd party domains).
Par conséquent, la solution pour continuer à suivre et à envoyer des données des sites web vers les partenaires consiste à utiliser un domaine appartenant à la marque, un domaine First party. Et les cookies doivent être définis par ce domaine ; c’est ce que l’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 à mettre en place pour initialiser ce suivi 1st party (d’abord au niveau du domaine, puis au niveau du cookie).
## Quelle configuration doit être mise en place ?
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 qu'il existe de domaines).\
Exemple :
[client.com](http://client1.com/) crée un sous-domaine [XYZ.client.com](http://pheonix.client1.com/) pointant vers le serveur Commanders Act.\
Désormais, nos tags appelleront [XYZ.client.com](http://pheonix.client1.com/) au lieu de notre domaine 3rd party (commander1) et la réponse définira un cookie sur le domaine principal .[client.com](http://client1.com/) ce qui est autorisé par les principaux navigateurs web.
Veuillez donc indiquer le sous-domaine sur notre plateforme : `Administration > Domain Management.`
Le client doit décider si le chiffrement SSL sur le nouveau sous-domaine qu’il a créé se fait avec ‘Let’s Encrypt’ ou avec son propre certificat. Dans le premier cas, rien à faire ; dans le second cas, suivez les instructions sur la page de gestion du domaine.
Par ailleurs, modifiez sur chaque tag l’URL pour préciser le domaine 1st party.
### Gérer MixCommander
#### Gérer les tags MixCommander
Mettez en place les tags Mixcommander comme vous le faites 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 celle de MixCo habituelle.
avant, c’était : http\://**client.commander1.com**/c3/?tcs=13\&chn=sem\&src=google\&url=
Maintenant, c’est : https\://**client.subdomain.com**/mix/c3/?tcs=13\&chn=sem\&src=google\&url=
## Comment se fera la migration de 3rd party vers 1st ?
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 enverra le cookie vers le domaine 1st party, 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 et 3rd party pour assurer 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 enverra les données au 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 enverra ces informations (si elles existent). 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 désormais possible d’utiliser une combinaison de first et third party cookies (créez un ticket pour demander à l’équipe MIX d’activer cette option) - disponible uniquement pour la transition.**
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://doc.commandersact.com/fr/configure/cookies/cookie-1st.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.