# Commanders Act Gateway

Ce document décrit comment déployer **Commanders Act Gateway**, un **gateway unified first-party** qui utilise **une seule configuration et un seul chemin sur votre domaine** pour prendre en charge plusieurs cas d’usage de tracking et d’hébergement.

Commanders Act Gateway inclut **Google Tag Gateway**, mais n’est **pas limité à Google**.\
Il est conçu pour servir et collecter des données pour **tous vos partenaires marketing et analytics**, en utilisant la même infrastructure first-party.

Une configuration, un chemin first-party, trois usages :

* Google Tag Gateway (GA4, Google Ads)
* Tracking first-party vers toutes les destinations server-side
* Hébergement first-party de bibliothèques Third-party

Si votre objectif est d’implémenter Google Tag Gateway, vous êtes au bon endroit.\
Si votre objectif est de construire une architecture de tracking first-party durable et agnostique vis-à-vis des fournisseurs, vous êtes également au bon endroit.

<figure><img src="https://3282103337-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Mk6XpTQ2LaRLcr2tA-d%2Fuploads%2Fgit-blob-5c269a1cb309c24a7504446eef7a53b7aafd97d9%2Fschema_google_ads%20(4).png?alt=media" alt=""><figcaption></figcaption></figure>

***

## Pourquoi utiliser Commanders Gateway ?

### 1. Avantages de l’utilisation d’un gateway

Une configuration gateway améliore **la qualité et l’exhaustivité de la collecte de données** sur l’ensemble de votre stack marketing.

* Les scripts des fournisseurs sont servis depuis votre propre domaine, ce qui réduit la probabilité qu’ils soient bloqués par les bloqueurs de publicité.
* Les restrictions des navigateurs (comme l’ITP de Safari) limitent ou bloquent souvent les cookies Third-party et certains cookies javascript 1st party, mais avec une configuration first-party server-side, la mesure reste plus fiable.
* Cela garantit **un tracking plus précis**, en fournissant aux partenaires des signaux de meilleure qualité pour la mesure, l’attribution et l’optimisation.

### 2. Avantages de l’utilisation de Commanders Gateway

En plus des avantages de toute approche gateway, **Commanders Gateway** ajoute des avantages uniques :

* Pas limité à Google Tag Gateway — la même configuration durable s’applique à **tous vos partenaires** (Meta, Snapchat, Bing, Awin, etc.).
* Configuration unifiée : un **chemin unique** (`/metrics`) sert et relaie toutes les bibliothèques des fournisseurs.
* Les noms de fichiers JavaScript obscurcis sont fournis automatiquement par Commanders Act, ce qui rend leur détection par les listes de blocage bien plus difficile.
* Avec le même chemin simple, vous pouvez également activer d’autres **fonctionnalités d’hébergement et de tracking first-party** telles que : l’hébergement de vos conteneurs de tag management, le suivi d’événements server-side ou les statistiques anonymes du CMP. Une seule configuration alimente l’ensemble de votre système d’hébergement et de tracking first-party.
* Une configuration centralisée simplifie le déploiement et la maintenance tout en restant **pérenne** face aux futures restrictions des navigateurs.

***

## Vue d’ensemble

**Commanders Gateway** vous permet de déployer des tags marketing et de mesure en utilisant votre **propre infrastructure first-party**, hébergée sur le domaine de votre site web.\
Cette infrastructure se situe entre votre site web et les services de vos partenaires (Google, Meta, Bing, Snapchat, Awin, etc.).

Avec Commanders Gateway :

* Les bibliothèques Google (gtag.js / gtm.js) sont chargées directement depuis votre **domaine first-party**.
* Les autres bibliothèques de fournisseurs sont servies depuis `/metrics/js/` en utilisant des **noms de fichiers obscurcis**.
* Toutes les requêtes de mesure sont relayées via votre domaine avant d’être transmises aux endpoints respectifs des partenaires.

***

## Architecture

Avec **Commanders Gateway**, vous réservez un **chemin unique** sur votre domaine, par exemple :

```
https://example.com/metrics/
```

* **Les scripts Google** (gtag.js / gtm.js) sont chargés directement depuis `/metrics/`.
* **Les scripts d’autres fournisseurs** (Meta, Snapchat, Bing, Awin, etc.) sont servis depuis `/metrics/js/` avec un **nom de fichier obscurci** généré par Commanders Act.

Exemple :

```
https://example.com/metrics/js/f4558899203.js
```

Le mappage entre chaque fournisseur et son nom de fichier de script obscurci est fourni dans l’ **interface First-Party Hosting de Commanders Act**.

**Schéma (conceptuel) :**

```
Site web  →  example.com/metrics/ (Google tags)
         →  example.com/metrics/js/f4558899203.js (Meta, Snap, Bing…)
         →  Commanders Gateway  →  endpoint du fournisseur
```

***

## Filtrage et gouvernance des cookies

Certaines organisations, en particulier celles qui ont des politiques de confidentialité strictes, peuvent avoir des inquiétudes à l’idée d’envoyer **des cookies first-party à des partenaires externes** comme Google. Commanders Gateway prend en charge **la minimisation des données** et fournit des mécanismes pour contrôler quels cookies peuvent transiter par le gateway. Deux approches complémentaires peuvent être utilisées :

#### Liste noire des cookies à l’edge

Les clients peuvent filtrer les cookies **directement au niveau du CDN ou de l’edge** (Cloudflare Worker, Fastly Compute, etc.). Cela peut être fait en **configurant simplement le code Worker fourni dans ce guide** (voir l’onglet CloudFlare free ou Faslty ci-dessous) pour supprimer certains cookies avant que la requête ne soit transmise à Commanders Gateway.

Cela permet de retirer des cookies spécifiques de la requête **avant qu’elle n’atteigne Commanders Gateway**, garantissant ainsi que seuls les cookies approuvés par l’organisation quittent son infrastructure.

#### Liste blanche des cookies avant transfert vers les partenaires

Commanders Gateway peut également appliquer **une liste blanche de cookies lors du transfert des requêtes vers les partenaires**.

Par exemple, lors du transfert des requêtes de mesure vers Google, le gateway peut être configuré pour **inclure uniquement les cookies liés à Google** (tels que `_ga` ou `_gcl_*`).\
Tous les autres cookies sont automatiquement exclus de la requête envoyée à Google.

## Avant de commencer

Ce guide suppose que votre site web est déjà configuré avec :

* Un système de gestion des tags (Commanders Act, Google Tag Manager, ou équivalent).
* Un CDN ou un load balancer (Cloudflare, Akamai, Fastly, Nginx, etc.) capable de transférer les requêtes vers des endpoints externes.

***

## Étape 1 : Choisir le chemin de diffusion du tag

Vous devez réserver **un chemin** sur le domaine de votre site web.

Exemple :

```
/metrics
```

Attention : cette configuration redirige tout le trafic utilisant le chemin choisi. Pour éviter d’affecter votre site web, choisissez un chemin qui n’est pas déjà utilisé.

***

## Étape 2 : Router le trafic

{% tabs %}
{% tab title="Cloudflare Enterprise" %}
Pour diffuser votre tag dans Commanders Gateway, vous allez créer une entrée CNAME pour un nouveau sous-domaine, créer une [Origin Rule](https://developers.cloudflare.com/rules/origin-rules/) pour transférer les requêtes, et créer une [Transform Rule](https://developers.cloudflare.com/rules/transform/) pour inclure les informations de géolocalisation. Pour finaliser cette configuration, vous devrez disposer d’un plan Cloudflare Enterprise. Si vous n’avez pas de plan Enterprise, envisagez plutôt d’utiliser la configuration automatisée de Cloudflare.

**Créer l’entrée CNAME**

**Note :** Les tags n’utiliseront pas cette entrée CNAME ; Cloudflare s’en sert pour router les requêtes en interne.

Choisissez un sous-domaine à réserver pour l’entrée CNAME. Ce CNAME n’est jamais exposé en dehors de votre configuration Cloudflare, donc le nom est arbitraire.

```
Sous-domaine CNAME : metrics
Cible : s1234.commander4.com
```

1. Dans la fenêtre **DNS** onglet, ouvrez la **Records** section.
2. Ajoutez un nouvel enregistrement avec :
   * **Type**: CNAME
   * **Nom**: metrics
   * **Cible**: s1234.commander4.com => remplacez 1234 par l’ID de votre site (ou workspace)
3. Enregistrez l’enregistrement CNAME.

**Créer l’Origin Rule**

1. Dans la fenêtre **Rules** onglet, ouvrez les **Origin Rules** et créez une nouvelle règle.
2. Entrez un nom de règle, tel que *Acheminer la mesure*.
3. Faites correspondre les requêtes entrantes à l’aide d’une expression de filtre personnalisée :

```
(http.host eq "example.com" and starts_with(http.request.uri.path, "/metrics"))
```

4. Mettez à jour le **Host Header** → Réécrire vers : `s1234.commander4.com.`
5. Mettez à jour le **DNS Record** → Remplacer par : `metrics.example.com`.
6. Enregistrez l’Origin Rule.

**Inclure les informations de géolocalisation (optionnel)**

1. Dans la fenêtre **Rules** onglet, ouvrez les **Paramètres**.
2. Activez l’ **Add visitor location headers** option.
3. Attendez quelques minutes la propagation.

Vous pouvez vérifier en naviguant vers :

```
https://example.com/metrics/healthy
```

Cela devrait renvoyer `ok`.
{% endtab %}

{% tab title="Cloudflare Free" %}
Lors de l’utilisation de Cloudflare Free, la configuration repose sur un **Worker simple** qui relaie tout le trafic depuis le chemin choisi (par ex. `/metrics`) vers l’infrastructure Commanders Gateway.

**Étape 1 : Créer le Worker**

1. Dans le **Dashboard** → **Workers & Pages** → **Worker**.
2. Copiez/collez le code suivant :

```javascript
const prefix = "/metrics"; // Chemin d’exemple, remplacez-le par le chemin que vous choisissez à l’étape précédente
const sid = "12345"; // ID de workspace d’exemple (ou ID de site), remplacez-le par votre propre ID

// Liste des noms de cookies qui ne doivent PAS être transmis à Commanders Gateway. Vous pouvez ajouter vos cookies techniques si nécessaire
const blacklistedCookies = [
  "PHPSESSID",
  "JSESSIONID"
];

addEventListener("fetch", event => {
  event.respondWith(handleRequest(event.request));
});

function filterCookieHeader(cookieHeader, blacklist) {
  if (!cookieHeader) return "";

  const blacklistSet = new Set(blacklist);

  const filteredCookies = cookieHeader
    .split(";")
    .map(cookie => cookie.trim())
    .filter(cookie => {
      const cookieName = cookie.split("=")[0];
      return !blacklistSet.has(cookieName);
    });

  return filteredCookies.join("; ");
}

async function handleRequest(request) {
  const url = new URL(request.url);
  if (url.pathname.startsWith(prefix)) {
    // Construire l’URL cible (elle remplace ${sid} par l’ID de votre workspace/site ci-dessus)
    const targetUrl = `https://s${sid}.commander4.com${url.pathname}${url.search}`;

    // Cloner les en-têtes de la requête
    const newHeaders = new Headers(request.headers);
    newHeaders.set("X-Forwarded-Host", url.host);

    const country = request.cf?.country || "";
    const region = request.cf?.region || "";
    if (country) newHeaders.set("X-Forwarded-Country", country);
    if (region) newHeaders.set("X-Forwarded-Region", region);
    if (country && region) {
      newHeaders.set("X-Forwarded-CountryRegion", `${country}-${region}`);
    }

    // Filtrer l’en-tête Cookie avant le proxy de la requête.
    const cookieHeader = newHeaders.get("Cookie");
    const filteredCookies = filterCookieHeader(cookieHeader, blacklistedCookies);

    if (filteredCookies) {
      newHeaders.set("Cookie", filteredCookies);
    } else {
      newHeaders.delete("Cookie");
    }

    // Supprimer l’en-tête Host pour éviter les conflits
    newHeaders.delete("host");

    // Proxy de la requête vers l’infrastructure Commanders Gateway
    const proxyRequest = new Request(targetUrl, {
      method: request.method,
      headers: newHeaders,
      body: request.body,
      redirect: "follow"
    });
    return fetch(proxyRequest);
  }
  return new Response("Not Found", { status: 404 }); // Retourner 404 si le chemin de la requête ne correspond pas au prefix
}
```

Ce Worker relaie les requêtes tout en ajoutant des en-têtes supplémentaires (`X-Forwarded-Host`, `X-Forwarded-Country`, `X-Forwarded-Region`).

**Étape 2 : Lier le Worker au chemin**

1. Dans Cloudflare, ouvrez les paramètres de votre domaine.
2. Accédez à **Workers Routes**.
3. Ajoutez une nouvelle route avec :
   * **Motif d’URL**: `www.example.com/metrics*`
   * **Worker**: sélectionnez le Worker créé à l’étape 1.

Une fois enregistré, toutes les requêtes vers `/metrics` seront relayées vers Commanders Gateway.
{% endtab %}

{% tab title="Akamai" %}
{% hint style="warning" %}
Commanders Gateway avec Akamai est actuellement en **beta**. Si vous avez une question ou un problème avec votre configuration, contactez le support
{% endhint %}

**Créer la règle de redirection**

1. Créez une nouvelle version de votre configuration de livraison dans **Property Manager**.
2. Sous le **Property Configuration Settings** section, ajoutez une nouvelle Rule :
   * Nommez-la : *Acheminer la mesure*
3. Ajoutez un nouveau **Match**:
   * Type de correspondance : `Path`
   * Condition : *est l’un des*
   * Valeur : `/metrics/*`
4. Ajoutez un nouveau **Comportement**:
   * Sélectionnez *Standard Property Behavior* et choisissez le comportement **Origin Server** .
   * Définissez **Origin Server Hostname** pour `s1234.commander4.com.`
   * Définissez **Forward Host Header** pour *Origin Hostname*.
5. Enregistrez la nouvelle règle et déployez vos modifications.
   * ⚠️ Testez la règle de redirection dans votre **environnement de préproduction** avant de la déployer en production.
   * Assurez-vous qu’aucune autre règle ne modifie/supprime les en-têtes de réponse sortants (par ex. *Content-Type*) car cela peut casser les scripts.

***

**Inclure les informations de géolocalisation**

1. Accédez à la section **Property Variables** et ajoutez les variables suivantes :

| Nom de la variable | Paramètres de sécurité |
| ------------------ | ---------------------- |
| USER\_REGION       | Masqué                 |
| USER\_COUNTRY      | Masqué                 |

2. Choisissez votre **Redirect rule** (créée ci-dessus) dans Property Configuration Settings.
3. Ajoutez deux nouveaux comportements **Set Variable** (un par variable) :

| Variable              | Create Value From | Get Data From  | Edgescape Field | Operation |
| --------------------- | ----------------- | -------------- | --------------- | --------- |
| PMUSER\_USER\_REGION  | Extract           | Edgescape Data | Region Code     | None      |
| PMUSER\_USER\_COUNTRY | Extract           | Edgescape Data | Country Code    | None      |

4. Ajoutez deux nouveaux comportements **Modify Outgoing Request Header** comportements :

| Action | Select Header Name | Custom Header Name  | Header Value                   |
| ------ | ------------------ | ------------------- | ------------------------------ |
| Add    | Other...           | X-Forwarded-Region  | {{user.PMUSER\_USER\_REGION}}  |
| Add    | Other...           | X-Forwarded-Country | {{user.PMUSER\_USER\_COUNTRY}} |

5. Enregistrez la nouvelle règle et déployez vos modifications.
6. Vérifiez la configuration :
   * Accédez à : `https://example.com/metrics/healthy` → devrait afficher `ok`.
   * Tester les en-têtes de géolocalisation : `https://example.com/metrics/?validate_geo=healthy` → devrait également afficher `ok`.
     {% endtab %}

{% tab title="Fastly" %}
{% hint style="warning" %}
La prise en charge de Fastly pour Commanders Gateway est actuellement en **beta**. Les étapes ci-dessous sont destinées aux utilisateurs techniques familiers de Fastly Compute (Compute Services). Selon la configuration de votre compte Fastly (domaines, TLS, produits activés), certaines étapes de liaison en production peuvent varier.
{% endhint %}

Lors de l’utilisation de Fastly, la configuration est différente de celle de Cloudflare. Vous déployez un **Compute service** (Wasm) et le configurez principalement via **Fastly API et CLI** depuis un terminal.

**Prérequis**

1. Créez un jeton API dans l’interface Fastly (les scopes doivent autoriser Compute, services, backends et deployments).
2. Exportez le jeton dans votre environnement de terminal :

```
export FASTLY_API_TOKEN=XXXXXXXXXXXX
```

3. Installez les prérequis :

* Node.js
* Fastly CLI

**Étape 1 : Créer le Compute service**

Créez un nouveau Compute service :

```
fastly service create --name "CA Gateway" --type wasm
```

Fastly retourne un **service ID**, par exemple :

```
dyBxiT8wpc2c8ZQg2KRrMN
```

Enregistrez-le, vous en aurez besoin pour créer le backend et pour les déploiements.

**Étape 2 : Créer un projet Compute local (starter kit)**

Générez un projet local à partir du starter kit JavaScript par défaut :

```
npm create @fastly/compute@latest -- --language=javascript --default-starter-kit
```

Cela crée une structure de projet similaire à :

```
.
├── README.md
├── fastly.toml
├── package.json
└── src
    ├── index.js
    └── welcome-to-compute.html
```

**Étape 3 : Configurer l’ID du service dans fastly.toml**

Edit `fastly.toml` et définissez l’ID du service :

```
# fastly.toml
service_id = "YOUR_SERVICE_ID"
```

**Étape 4 : Créer le backend (origin Commanders Gateway)**

Créez un backend qui pointe vers l’infrastructure Commanders Gateway (remplacez `1234` par l’ID de votre workspace/site) :

```
fastly backend create \
  --service-id YOUR_SERVICE_ID \
  --version 1 \
  --name commander_gateway \
  --address s1234.commander4.com \
  --use-ssl \
  --port 443 \
  --ssl-sni-hostname s1234.commander4.com
```

Remarques :

* `--version 1` est un point de départ typique. Si votre service possède déjà des versions, utilisez celle que vous souhaitez déployer.
* L’adresse du backend doit être `s1234.commander4.com` (votre propre ID de workspace/site).

**Étape 5 : Implémenter la logique de routage dans src/index.js**

Remplacez le contenu de `src/index.js` par le code Worker suivant.

Vous devez mettre à jour :

* `prefix` (votre chemin client, exemple : `/metrics`)
* `sid` (votre ID de workspace/site Commanders, exemple : `s1234`)

```javascript
/// <reference types="@fastly/js-compute" />

import { env } from "fastly:env";
import { includeBytes } from "fastly:experimental";

const prefix = "/PATHACHANGER";              // TODO : remplacez par le chemin gateway que vous avez choisi (par ex. "/metrics")
const sid = "s123456";                       // TODO : remplacez par votre ID de workspace/site (par ex. "s1234")
const BACKEND = "commander_gateway";         // Nom du backend Fastly pointant vers sid.commander4.com

const STRIP_PREFIX = true;                   // Si vrai, supprime le prefix du chemin relayé
const PREPEND_PATH = "/gateway";             // Point d’entrée gateway interne côté Commanders (ne pas modifier)

// Liste des noms de cookies qui ne doivent PAS être transmis à Commanders Gateway. Ajoutez vos cookies techniques si nécessaire
const blacklistedCookies = [
  "PHPSESSID",
  "JSESSIONID"
];

addEventListener("fetch", (event) => event.respondWith(handleRequest(event.request)));

function filterCookieHeader(cookieHeader, blacklist) {
  if (!cookieHeader) return "";

  const blacklistSet = new Set(blacklist);

  const filteredCookies = cookieHeader
    .split(";")
    .map(cookie => cookie.trim())
    .filter(cookie => {
      const cookieName = cookie.split("=")[0];
      return !blacklistSet.has(cookieName);
    });

  return filteredCookies.join("; ");
}

async function handleRequest(request) {

  const url = new URL(request.url);

  // Ne relayer que les requêtes correspondant au prefix configuré
  if (!url.pathname.startsWith(prefix)) {
    return new Response("Not Found", { status: 404 });
  }

  // Construire le chemin qui sera transmis à Commanders Gateway
  let fwdPath = url.pathname;

  // Supprimer éventuellement le prefix client (par ex. "/metrics") afin que l’origin reçoive "/"
  if (STRIP_PREFIX) {
    fwdPath = fwdPath.slice(prefix.length) || "/";
  }

  // Préfixer avec le point d’entrée interne Commanders (obligatoire)
  if (PREPEND_PATH) {
    fwdPath = PREPEND_PATH + fwdPath;
  }

  // URL d’origin finale sur l’infrastructure Commanders
  const target = `https://${sid}.commander4.com${fwdPath}${url.search}`;

  // Cloner les en-têtes et ajouter les informations de forwarding
  const headers = new Headers(request.headers);
  headers.set("X-Forwarded-Host", url.host);

  // Transmettre les informations de géolocalisation lorsqu’elles sont disponibles (optionnel mais recommandé)
  const country = (request.geo && request.geo.country_code) ? request.geo.country_code.toUpperCase() : "";
  const region  = (request.geo && request.geo.region) ? request.geo.region : "";
  if (country) headers.set("X-Forwarded-Country", country);
  if (region)  headers.set("X-Forwarded-Region", region);
  if (country && region) headers.set("X-Forwarded-CountryRegion", `${country}-${region}`);

  // Filtrer l’en-tête Cookie avant le proxy de la requête.
  const cookieHeader = headers.get("Cookie");
  const filteredCookies = filterCookieHeader(cookieHeader, blacklistedCookies);

  if (filteredCookies) {
    headers.set("Cookie", filteredCookies);
  } else {
    headers.delete("Cookie"); // Supprimer complètement l’en-tête Cookie si tous les cookies ont été filtrés
  }

  // Éviter les conflits avec l’en-tête Host à l’origine
  headers.delete("host");

  // Reconstruire la requête pour l’origine
  const originReq = new Request(target, {
    method: request.method,
    headers,
    body: request.body
  });

  // Contourner le cache pour garantir que les hits de mesure ne soient jamais mis en cache
  const co = new CacheOverride("pass");

  // Envoyer la requête au backend Fastly configuré
  return fetch(originReq, { backend: BACKEND, cacheOverride: co });

}
```

Important :

* Remplacez `s1234.commander4.com` avec le véritable endpoint de votre workspace/site ID.
* Conservez le même `prefix` que le chemin que vous réservez sur le domaine client (exemple : `/metrics`).
* N’ajoutez PAS de slash final à la fin du chemin dans les URL côté client.

**Étape 6 : Déployer**

Déployez le service Compute :

```
npm run deploy
```

**Étape 7 : Tester**

Après le déploiement, Fastly fournit un domaine temporaire pour les tests, par exemple :

```
https://plainly-rested-bison.edgecompute.app/metrics/healthy
```

Il devrait renvoyer :

```
ok
```

**Liaison de production (domaine client)**

À ce stade, le service Compute s’exécute sur un domaine de test fourni par Fastly. Pour passer en production sur le domaine client (exemple : `https://example.com/metrics/`), vous devez encore lier le service au domaine de production et vous assurer que TLS est en place.

Cela implique généralement, selon la configuration du client :

* Ajouter le domaine client au service Fastly et configurer TLS pour celui-ci (managed TLS ou certificat client).
* Créer l’enregistrement DNS requis (souvent un CNAME) afin que `example.com` pointe vers Fastly.
* S’assurer que le service Compute est bien celui qui reçoit les requêtes pour le chemin choisi (exemple : `/metrics*`) sur ce domaine.

Comme les étapes exactes dépendent des produits Fastly activés sur le compte et de la manière dont le client gère TLS et DNS, considérez cela comme une étape bêta et contactez le support si vous avez besoin des commandes exactes pour votre configuration spécifique.
{% endtab %}
{% endtabs %}

***

## Étape 3 : Mettre à jour les scripts dans votre système de gestion de tags ou sur votre site web

Remplacez les URL des scripts du fournisseur par les nouveaux **chemins first-party**.

Exemples :

### Google

```html
<!-- Au lieu de -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-12345"></script>

<!-- Utilisez -->
<script async src="/metrics/"></script>
```

### Meta (Facebook Pixel)

```html
<!-- Au lieu de -->
<script src="https://connect.facebook.net/en_US/fbevents.js"></script>

<!-- Utilisez (chemin obfusqué fourni dans l’interface Commanders Act) -->
<script src="/metrics/js/f4558899203.js"></script>
```

### Snapchat

```html
<script src="/metrics/js/a82b99df732.js"></script>
```

### Bing (UET)

```html
<script src="/metrics/js/c77ac91be11.js"></script>
```

Chaque nom de fichier obfusqué est généré automatiquement et disponible dans le **interface First-Party Hosting de Commanders Act**.

### OneTag

Vous pouvez modifier manuellement le domaine de votre configuration cact() avec le `collectionDomain` propriété Exemple :

```javascript
cact(..., {collectionDomain: "www.youdomain.com/metrics"});
```

Attention : n’ajoutez PAS de `/` à la fin du chemin

***

## Étape 4 : Vérifier la configuration

* Pour le chemin global, vérifiez l’endpoint de santé :
  * `https://example.com/metrics/healthy` → devrait renvoyer `ok`
* Utilisez les DevTools du navigateur pour vérifier que :
  * Les scripts Google sont chargés depuis `/metrics/`
  * Les scripts des autres fournisseurs sont chargés depuis `/metrics/js/{obfuscated}.js`
  * Les requêtes sont effectuées vers votre **domaine first-party**.
* Assurez-vous que les événements apparaissent dans les tableaux de bord partenaires respectifs (Google Analytics, Facebook Events Manager, etc.).

***

## Avantages

* **Durabilité**: Le suivi continue de fonctionner même avec ITP de Safari et les restrictions liées aux cookies third-party.
* **Résilience**: Servir les scripts depuis votre domaine avec des noms de fichiers obfusqués rend plus difficile l’interférence des règles de blocage.
* **Configuration centralisée**: Un chemin unique (`/metrics`) gère tous les fournisseurs.
* **À l’épreuve du futur**: S’adapte à privacy sandbox et aux futures restrictions des navigateurs.
*

## Configurer la collecte de données first party pour les fonctionnalités Commanders Act (via Gateway)

Ce chapitre explique comment acheminer la collecte de données Commanders Act via votre **chemin gateway first party** (par exemple `/metrics`) pour les principales fonctionnalités Commanders Act.

Notes importantes :

* Le chemin gateway affiché dans les exemples (`/metrics`) n’est qu’un exemple. Les clients choisissent leur propre chemin lors de la configuration de la gateway dans leur CDN ou outil edge (Cloudflare, Akamai, etc.).
* Tous les exemples ci-dessous supposent que votre gateway est saine : `https://example.com/metrics/healthy` renvoie `ok`.

***

### 1. Destinations server-side via la gateway (exemple : Meta Facebook CAPI)

Le suivi server-side de Commanders Act repose sur **oneTag** tags. En général, vous aurez un oneTag par événement que vous souhaitez collecter, par exemple :

* `page_view`
* `add_to_cart`
* `purchase`

Pour acheminer ces événements oneTag via la gateway, vous devez mettre à jour la **configuration du tag oneTag** afin que la `cact()` configuration utilise votre domaine et votre chemin de collecte first party.

Dans votre tag oneTag (ou dans l’extrait partagé utilisé par vos tags oneTag), définissez `collectionDomain`:

```javascript
cact(..., { collectionDomain: "www.yourdomain.com/metrics" });
```

Remarques :

* Remplacez `www.yourdomain.com/metrics` avec votre propre domaine et le chemin que vous avez configuré dans votre gateway.
* N’ajoutez PAS de `/` à la fin du chemin.
* Une fois cela défini, tous les événements oneTag (page\_view, add\_to\_cart, purchase, etc.) seront collectés via votre chemin gateway first party.

***

### 2. Collecte CDP, Campaign Analytics et CMP via la gateway

*(Data Activation, Campaign Analytics, statistiques CMP et preuve de consentement)*

Ces trois fonctionnalités reposent sur le même mécanisme de routage. Pour envoyer leurs données via la gateway, vous devez définir la variable **`tC.clientCollectDns`** soit :

* directement dans chaque tag concerné, **ou**
* dans un **tag de configuration global** qui s’exécute avant tous les tags Commanders Act (recommandé).

Exemple :

```javascript
tC.clientCollectDns = "www.yourdomain.com/metrics";
```

Comportement :

* Dès que `tC.clientCollectDns` est définie, la collecte pour **Data Activation, Campaign Analytics et le suivi lié au CMP** sera effectuée via la gateway.
* `metrics` n’est qu’un exemple. Les clients peuvent utiliser n’importe quel chemin qu’ils ont configuré dans leur gateway.

Options d’implémentation :

* **Option A (simple) :** ajoutez la ligne directement dans le tag Data Activation / Campaign Analytics / CMP.
* **Option B (recommandée) :** ajoutez-la dans un tag de configuration global qui s’exécute avant tous les tags Commanders Act.

***

### Checklist de vérification

Après avoir appliqué les changements ci-dessus, vérifiez :

* L’endpoint de santé de la gateway : `https://example.com/metrics/healthy` renvoie `ok`.
* Dans les DevTools du navigateur (onglet Network), les requêtes de collecte Commanders Act vont vers votre domaine et votre chemin first party (par exemple `https://example.com/metrics/...`).
* Les événements et les données apparaissent comme prévu dans :
  * Les tableaux de bord des destinations server-side (exemple : Meta Events Manager pour CAPI)
  * Les flux Data Activation
  * Les statistiques CMP et le reporting de preuve de consentement (le cas échéant)
  * Le reporting Campaign Analytics