# Commanders Act Gateway

Ce document décrit comment déployer **Commanders Act Gateway**, un **gateway first-party unifié** 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 ne se limite **pas à 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 seul 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 tierces

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, indépendante 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 des adblockers.
* Les restrictions des navigateurs (comme l’ITP de Safari) limitent ou bloquent souvent les third-party cookies 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.
* Des noms de fichiers JavaScript obfusqués sont automatiquement fournis 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 tracking d’événements server-side ou des statistiques CMP anonymes. 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 prochaines 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.\
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 obfusqués**.
* Toutes les requêtes de mesure sont relayées via votre domaine avant d’être transmises aux endpoints des partenaires concernés.

***

## 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 autres scripts de fournisseurs** (Meta, Snapchat, Bing, Awin, etc.) sont servis depuis `/metrics/js/` avec un **nom de fichier obfusqué** généré par Commanders Act.

Exemple :

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

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

**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 des cookies et gouvernance

Certaines organisations, en particulier celles qui ont des politiques de confidentialité strictes, peuvent s’inquiéter de l’envoi de **first-party cookies à 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 via le gateway. Deux approches complémentaires peuvent être utilisées :

#### Liste noire de 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 les onglets CloudFlare free ou Faslty ci-dessous) afin de supprimer des cookies spécifiques avant que la requête soit transmise à Commanders Gateway.

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

#### Liste blanche de cookies avant transfert aux partenaires

Commanders Gateway peut également appliquer **une liste blanche de cookies lors du transfert des requêtes aux 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 tag management (Commanders Act, Google Tag Manager ou équivalent).
* Un CDN ou load balancer (Cloudflare, Akamai, Fastly, Nginx, etc.) capable de relayer des requêtes vers des endpoints externes.

***

## Étape 1 : Choisir le chemin de diffusion des tags

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

Exemple :

```
/metrics
```

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

***

## Étape 2 : Router le trafic

{% tabs %}
{% tab title="Cloudflare Enterprise" %}
Pour servir 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 devez disposer d’un plan Cloudflare Enterprise. Si vous n’avez pas de plan Enterprise, envisagez plutôt d’utiliser la configuration automatisée Cloudflare.

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

**Remarque :** 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, le nom est donc arbitraire.

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

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

**Créer l’Origin Rule**

1. Dans l’ **onglet Rules** , ouvrez **Origin Rules** et créez une nouvelle règle.
2. Entrez un nom de règle, par exemple *Router les mesures*.
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 en : `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 l’ **onglet Rules** , ouvrez **Settings**.
2. Activez l’option **Add visitor location headers** .
3. Attendez quelques minutes que la propagation se fasse.

Vous pouvez vérifier en accédant à :

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

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

{% tab title="Cloudflare Free" %}
Avec 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 Cloudflare, allez à **Workers & Pages** → **Create application** → **Worker**.
2. Copiez/collez le code suivant :

```javascript
const prefix = "/metrics"; // Exemple de chemin, remplacez-le par le chemin choisi à l’étape précédente
const sid = "12345"; // Exemple d’ID de workspace (alias site ID), 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 votre workspace/site ID 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 de relayer 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");

    // Relayer la requête vers l’infra 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 }); // Retourne 404 si le chemin de la requête ne correspond pas au préfixe
}
```

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 : Associer 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. Dans la section **Property Configuration Settings** , ajoutez une nouvelle Rule :
   * Nommez-la : *Router les mesures*
3. Ajouter une nouvelle **Match**:
   * Type de correspondance : `Path`
   * Condition : *is one of*
   * Valeur : `/metrics/*`
4. Ajouter une nouvelle **Behavior**:
   * Sélectionnez *Standard Property Behavior* et choisissez le comportement **Origin Server** .
   * Définissez **Origin Server Hostname** sur `s1234.commander4.com.`
   * Définissez **Forward Host Header** sur *Origin Hostname*.
5. Enregistrez la nouvelle règle et déployez vos modifications.
   * ⚠️ Testez la règle de redirection dans votre **environnement de staging** 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              | Créer la valeur à partir de | Obtenir les données depuis | Edgescape Field | Opération |
| --------------------- | --------------------------- | -------------------------- | --------------- | --------- |
| PMUSER\_USER\_REGION  | Extraire                    | Edgescape Data             | Region Code     | None      |
| PMUSER\_USER\_COUNTRY | Extraire                    | Edgescape Data             | Country Code    | None      |

4. Ajoutez deux nouveaux comportements **Modifier les comportements de l’en-tête de requête sortant** :

| Action  | Select Header Name | Custom Header Name  | Header Value                   |
| ------- | ------------------ | ------------------- | ------------------------------ |
| Ajouter | Autre...           | X-Forwarded-Region  | {{user.PMUSER\_USER\_REGION}}  |
| Ajouter | Autre...           | 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` → doit afficher `ok`.
   * Tester les en-têtes de géolocalisation : `https://example.com/metrics/?validate_geo=healthy` → doit é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 familiarisés avec Fastly Compute (Compute Services). Selon la configuration de votre compte Fastly (domaines, TLS, produits activés), certaines étapes d’association en production peuvent varier.
{% endhint %}

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

**Prérequis**

1. Créez un token API dans l’interface Fastly (les scopes doivent autoriser Compute, services, backends et deployments).
2. Exportez le token dans l’environnement de votre 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 renvoie un **service ID**, par exemple :

```
dyBxiT8wpc2c8ZQg2KRrMN
```

Conservez-le, vous en aurez besoin pour la création du backend et 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 le service ID dans fastly.toml**

Modifiez `fastly.toml` et définissez le service ID :

```
# 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 a déjà des versions, utilisez la version 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 workspace/site ID 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 workspace/site ID (par ex. "s1234")
const BACKEND = "commander_gateway";         // Nom du backend Fastly pointant vers sid.commander4.com

const STRIP_PREFIX = true;                   // Si true, supprime le préfixe du chemin relayé
const PREPEND_PATH = "/gateway";             // Point d’entrée interne du gateway 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);

  // Relayer uniquement les requêtes qui correspondent au préfixe configuré
  if (!url.pathname.startsWith(prefix)) {
    return new Response("Not Found", { status: 404 });
  }

  // Construire le path qui sera transféré vers Commanders Gateway
  let fwdPath = url.pathname;

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

  // Préfixer l’entrypoint interne de Commanders (obligatoire)
  if (PREPEND_PATH) {
    fwdPath = PREPEND_PATH + fwdPath;
  }

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

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

  // Transférer les informations géographiques 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 de relayer la requête.
  const cookieHeader = headers.get("Cookie");
  const filteredCookies = filterCookieHeader(cookieHeader, blacklistedCookies);

  if (filteredCookies) {
    headers.set("Cookie", filteredCookies);
  } else {
    headers.delete("Cookie"); // Supprimer entièrement le header Cookie si tous les cookies ont été filtrés
  }

  // Éviter les conflits de header 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
  });

  // Ignorer 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` par l’endpoint réel de votre workspace/site ID.
* Conservez le même `prefix` que le path que vous réservez sur le domaine client (exemple : `/metrics`).
* N’ajoutez PAS de slash final à la fin du path dans les URLs 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
```

**Binding de production (domaine client)**

À ce stade, le service Compute fonctionne 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 le TLS est en place.

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

* Ajouter le domaine client au service Fastly et configurer le 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 path 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 le TLS et le DNS, considérez ceci comme une étape beta 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 tag management ou sur votre site web

Remplacez les URLs des scripts du fournisseur par les nouveaux **first-party paths**.

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 (path 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 Commanders Act First-Party Hosting**.

### OneTag

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

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

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

***

## Étape 4 : Vérifier la configuration

* Pour le path 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 autres scripts fournisseurs sont chargés depuis `/metrics/js/{obfuscated}.js`
  * Les requêtes sont envoyées à votre **domaine first-party**.
* Assurez-vous que les événements apparaissent dans les dashboards partenaires respectifs (Google Analytics, Facebook Events Manager, etc.).

***

## Avantages

* **Durabilité**: Le tracking continue de fonctionner même avec Safari ITP et les restrictions sur les cookies tiers.
* **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 seul path (`/metrics`) gère tous les fournisseurs.
* **Pérennité**: S’adapte au privacy sandbox et aux prochaines restrictions des navigateurs.
*

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

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

Remarques importantes :

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

***

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

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

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

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

Dans votre tag oneTag (ou dans le snippet 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 path que vous avez configuré dans votre gateway.
* N’ajoutez PAS de `/` final à la fin du path.
* Une fois cela configuré, tous les événements oneTag (page\_view, add\_to\_cart, purchase, etc.) seront collectés via votre first party gateway path.

***

### 2. Collecte CDP, Campaign Analytics et CMP via le 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 le gateway, vous devez définir la variable **`tC.clientCollectDns`** soit :

* directement dans chaque tag concerné, **ou**
* dans un **tag de configuration globale** 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 tracking lié à CMP** se fera via le gateway.
* `metrics` n’est qu’un exemple. Les clients peuvent utiliser n’importe quel path qu’ils ont configuré dans leur setup gateway.

Options d’implémentation :

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

***

### Checklist de vérification

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

* L’endpoint de santé du 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 path first party (par exemple `https://example.com/metrics/...`).
* Les événements et les données apparaissent comme prévu dans :
  * Les dashboards de destination server-side (exemple : Meta Events Manager pour CAPI)
  * Les flux Data Activation
  * Les statistiques CMP et les rapports de preuve de consentement (le cas échéant)
  * Les rapports Campaign Analytics