> For the complete documentation index, see [llms.txt](https://doc.commandersact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.commandersact.com/fr/configurer/cookies/cookie-1st.md).

# 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 analytics, de mémoriser les paramètres de langue et d’effectuer d’autres fonctions utiles qui aident à offrir une bonne expérience utilisateur.
* **cookies Third-party** 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 tracking 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 poussé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 poussés vers un domaine non lié à la marque (3rd party domains).

Par conséquent, la solution de contournement pour continuer à suivre et à pousser des données des sites Web vers les partenaires consiste à utiliser un domaine appartenant à la marque, un First 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 à faire 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 que de domaines existants).\
Exemple :

[client.com](http://client1.com/) crée un sous-domaine [XYZ.client.com](http://pheonix.client1.com/) pointant vers le serveur Commanders Act.\
À partir de maintenant, 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 ensuite indiquer le sous-domaine sur notre plateforme : `Administration > Gestion des domaines.`

<figure><img src="/files/cf0efe9775ead899059203f134f1d254bdbdeaa6" alt=""><figcaption></figcaption></figure>

Le client doit décider si le chiffrement SSL sur le nouveau sous-domaine qu’il a créé est effectué 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 des domaines.

De plus, 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

<figure><img src="/files/b368f4c915bad8ab11c39c7bc458a8392ce96f68" alt=""><figcaption></figcaption></figure>

Dans l’espace réservé #CUSTOMER\_SUBDOMAIN#, vous devez saisir le sous-domaine convenu avec le client.

#### Gérer MixCommander Tracking

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

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 la migration du 3rd party vers le 1st va-t-elle se faire ?

Il existe 2 situations possibles que nous pouvons rencontrer :

* Utilisateurs avec un cookie 1st existant

C’est la configuration cible lorsque les cookies 3rd disparaîtront.

Le navigateur poussera 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 avec des domaines 1st 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 du domaine 1st party.

Le navigateur poussera les données vers le domaine 1st party, et nous demanderons au domaine 3rd party toutes les informations dont nous disposons concernant cet utilisateur (un cookie existe-t-il déjà ?). Le domaine 3rd party poussera ces informations (si elles existent). Ensuite, le domaine 1st party configurera le cookie (ou en créera un nouveau) et les données sont poussées vers notre système.

**Il est désormais 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 pendant la transition.**


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://doc.commandersact.com/fr/configurer/cookies/cookie-1st.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
