Commanders Act Gateway

Ce document décrit comment déployer Commanders Act Gateway, une gateway first-party unifiée qui utilise une configuration unique et un seul chemin sur votre domaine pour alimenter 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 seule 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 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 first-party durable et agnostique vis-à-vis des fournisseurs, vous êtes aussi au bon endroit.

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 du navigateur (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 d’utiliser Commanders Gateway

En plus des avantages de toute approche gateway, Commanders Gateway apporte 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 (/mypath) 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 aussi 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 server-side des événements, ou les statistiques CMP anonymes. Une configuration unique alimente tout 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 tag 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 fournisseurs sont servies depuis /mypath/js/ à l’aide de 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.

Cette section est rédigée pour la vérification des prérequis du Consent Mode avec Google Tag Gateway (GTG). Elle explique ce que GTG change pour le consent, comment vérifier l’inscription, et quoi faire si un signal de consent "late" est détecté sur un domaine inscrit à GTG.

Google Tag Gateway (GTG) pour les annonceurs permet à un site web de servir des tag Google (gtag.js, gtm.js) depuis le propre domaine first-party du site au lieu de googletagmanager.com, en utilisant un CDN, un load balancer ou un web server. Commanders Act Gateway peut être utilisé pour implémenter GTG (voir Architecture ci-dessous).

GTG ne change pas ce que fait le consent mode — il change d’où le Google tag est servi et, surtout, quand il peut se charger par rapport à votre bannière de consent. C’est ce timing qui a un impact sur le consent :

Injection CDN automatisée / en un clic (la configuration dans l’interface proposée par Google pour Cloudflare, Akamai, Fastly ou un Google Cloud Load Balancer) amène Google à injecter directement la règle de routage dans la configuration de votre CDN ou load balancer, plaçant généralement le Google tag très tôt dans la page. Comme cette injection se produit en dehors de votre tag management ou du code source de la page, vous ne pouvez généralement plus contrôler l’ordre de chargement des scripts par rapport à votre bannière de consent. Si le stub de consent de votre CMP n’a pas encore été exécuté et défini les états de consent par défaut, le Google tag peut se déclencher en premier.
Configuration GTG manuelle / en self-service, où vous configurez vous-même le routage et référencez directement le script first-party dans le code source de votre page, laisse l’ordre de chargement des scripts sous votre contrôle — vous décidez si le Google tag ou le script de consent de votre CMP se charge en premier.

Lorsqu’un Google tag se déclenche avant que votre CMP ait défini un état de consent par défaut, Google appelle cela un signal de consent "late": le tag s’exécute avec un état de consent inconnu/non défini au lieu de respecter le défaut que votre CMP était censée définir. Cela peut amener les tags à se comporter comme si aucun framework de consent n’était présent, et c’est signalé par les outils de diagnostic de Google (voir Vérification ci-dessous).

Revenir en arrière sur GTG est pas la méthode recommandée pour résoudre un signal de consent late : cela fait perdre les avantages de durabilité de la mesure first-party que GTG est conçu pour offrir. Les remédiations recommandées sont décrites dans Si un signal de consent late est détecté ci-dessous.

La documentation de Google sur GTG

Vérifier si un tag est inscrit à GTG

Avant d’examiner un problème de consent lié à GTG, confirmez si le domaine est réellement inscrit. L’une des méthodes suivantes peut être utilisée :

Dans l’interface produit Google — Dans Google Tag Manager, allez à Admin → Google tag gateway. Chaque domaine est listé avec un statut : First-party (GTG est actif), Non démarré (GTG n’a pas été activé), ou Domaines activés pour les domaines configurés manuellement ou via un tag différent. Le même statut est disponible sur l’écran équivalent dans Google Ads et Google Analytics.
Google Tag Assistant — Connectez Tag Assistant au site web, déclenchez les tag pertinents, et vérifiez d’où les requêtes du Google tag sont réellement servies et vers où elles sont envoyées (Summary → Output → Hits Sent). Si les requêtes du Google tag sont routées vers votre propre domaine (par exemple example.com/mypath/ ou example.com/gtag/js) au lieu de www.googletagmanager.com ou www.google-analytics.com, GTG est actif pour cette page.
Outils de développement du navigateur — Dans l’onglet Network, vérifiez si le script et les requêtes de mesure pour gtag.js / gtm.js proviennent de votre domaine first-party plutôt que d’un domaine Google.

Un signal de consent late apparaît généralement dans les outils de débogage du consent (chronologie de consent de Tag Assistant, ou avertissement dans la console) comme le Google tag qui se déclenche avant qu’un état de consent par défaut ne soit défini, ou un état de consent signalé comme "unknown" au moment où le tag s’est déclenché.

Une fois que vous avez confirmé à la fois (a) un signal de consent late, et (b) que GTG est inscrit sur le domaine, Google recommande l’une des approches de remédiation suivantes :

Adoptez Advanced Consent Mode dans votre configuration CMP Commanders Act, et configurez Data Transmission Controls et Global Consent Defaults dans les paramètres de votre Google tag (Google Ads, GA4 ou Campaign Manager 360) selon vos besoins de conformité. C’est le mécanisme que Google recommande spécifiquement pour les tag activés avec GTG — voir pourquoi ci-dessous.
Migrez tous vos Google tag dans un seul conteneur Google Tag Manager, et déployez ce conteneur lui-même via GTG, au lieu d’injecter des tag gtag.js individuels. Cela centralise le contrôle de l’ordre de chargement dans GTM, de sorte que les vérifications de consent intégrées de GTM s’appliquent à chaque Google tag dans le conteneur, quelle que soit la manière dont le script du conteneur est routé.
Configurez GTG manuellement, afin que vous — et non une injection CDN automatisée — contrôliez l’emplacement de la référence du script GTG first-party dans le code source de votre page, par rapport au script de bannière de consent Commanders Act.

Ces trois options ne s’excluent pas mutuellement. Par exemple, une configuration GTG manuelle (option 3) peut être combinée avec Advanced Consent Mode (option 1) pour une résilience supplémentaire si l’ordre de chargement est un jour affecté par une évolution future de la page ou du CDN.

Pourquoi Advanced Consent Mode est recommandé pour GTG

Advanced Consent Mode est le mécanisme que Google recommande pour les tag activés avec GTG car, contrairement à Basic Consent Mode (qui bloque simplement le tag jusqu’à ce qu’un défaut soit défini), il est compatible avec les configurations GTG manuelles: il permet au Google tag de se charger et d’envoyer des pings sans cookie et conformes à la vie privée même lorsque le consent est refusé ou pas encore connu, puis passe à la mesure complète dès que le choix du visiteur est reçu — sans dépendre de l’ordre exact de chargement du script GTG et de la bannière de consent.

Pour l’activer avec Commanders Act :

Activer Advanced Consent Mode dans votre configuration Google Consent Mode de Commanders Act — voir Google Consent Mode in Commanders Act TMS et Google Tag Manager (GTM) – Consent Mode.
Activer Data Transmission Controls dans les paramètres de votre Google tag (Google Ads, GA4 ou Campaign Manager 360) pour restreindre indépendamment les données publicitaires, analytics et de diagnostic lorsque le consent est refusé — voir Data transmission controls.
Définir Global Consent Defaults pour votre Google tag afin qu’un état de consent de référence (refusé, sauf exigence contraire) s’applique toujours par région, même dans le rare cas où l’on ne peut pas garantir que le stub de la CMP s’exécute en premier — voir la section sur le comportement spécifique à la région du guide Google sur le consent mode et les paramètres Consent Overview de GTM.

Choisissez le bon template ! Si vous devez activer Google Consent Mode avec IAB TCF, utilisez notre TCF IAB templates de bannière (Footer ou Popin) et suivez les spécifications de configuration mentionnées ici

Architecture

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

https://example.com/mypath/

Scripts Google (gtag.js / gtm.js) sont chargés directement depuis /mypath/.
Autres scripts fournisseurs (Meta, Snapchat, Bing, Awin, etc.) sont servis depuis /mypath/js/ avec un nom de fichier obfusqué généré par Commanders Act.

Exemple :

https://example.com/mypath/js/f4558899203.js

La correspondance entre chaque fournisseur et son nom de fichier de script obfusqué est fournie dans l’ interface Commanders Act First-Party Hosting.

Schéma (conceptuel) :

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

Certaines organisations, en particulier celles ayant des politiques de confidentialité strictes, peuvent s’inquiéter de l’envoi de cookie first-party vers des partenaires externes comme Google. Commanders Gateway prend en charge la minimisation des données et fournit des mécanismes pour contrôler quels cookie peuvent transiter via le gateway. Deux approches complémentaires peuvent être utilisées :

Les clients peuvent filtrer les cookie directement au niveau du CDN ou de la couche 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) afin de supprimer des cookie spécifiques avant que la requête ne soit transmise à Commanders Gateway.

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

Commanders Gateway peut également imposer une liste blanche de cookie lors de la transmission des requêtes aux partenaires.

Par exemple, lors de la transmission de requêtes de mesure à Google, le gateway peut être configuré pour inclure uniquement les cookie liés à Google (tels que _ga ou _gcl_*). Tous les autres cookie 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 transmettre des 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 :

/mypath

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

Étape 2 : Router le trafic

Lorsque vous utilisez Cloudflare Enterprise, nous recommandons d’utiliser un Cloudflare Worker pour proxyer tout le trafic provenant du chemin choisi, par exemple /mypath, vers l’infrastructure Commanders Gateway.

Cette approche est la même que la configuration Cloudflare Free. Elle est plus fiable que d’essayer de router le chemin avec Cloudflare Origin Rules, car le Worker offre un contrôle total sur l’URL de la requête, les en-têtes, le filtrage des cookie et la transmission de la géolocalisation.

Étape 1 : Créer le Worker

Dans le Dashboard Cloudflare, allez à Workers & Pages → Créer une application → Worker.
Copiez/collez le code suivant :

const prefix = "/mypath"; // Chemin d’exemple, remplacez-le par le chemin choisi à l’étape précédente
const sid = "12345"; // ID d’espace de travail d’exemple (alias site ID), remplacez-le par votre propre ID

// Liste des noms de cookie qui ne doivent PAS être transmis à Commanders Gateway. Vous pouvez ajouter vos cookie 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 espace de travail/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 de proxyer 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");

    // Proxyer 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 });
}

Ce Worker proxy les requêtes tout en ajoutant des en-têtes supplémentaires :

X-Forwarded-Host
X-Forwarded-Country
X-Forwarded-Region
X-Forwarded-CountryRegion

Il peut aussi filtrer les cookie sensibles ou techniques avant de transmettre la requête à Commanders Gateway.

Étape 2 : Associer le Worker au chemin

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

Une fois enregistré, toutes les requêtes vers /mypath seront proxyées vers Commanders Gateway.

Étape 3 : Vérifier la configuration

Vous pouvez vérifier la configuration en accédant à :

https://example.com/mypath/g/healthy

Note : le sous-chemin google par défaut est /g/ mais il peut être personnalisé. Ce sous-chemin google se trouve immédiatement après /mypath/ .

Il devrait renvoyer :

ok

Pour vérifier la transmission de la géolocalisation, vous pouvez aussi tester :

https://example.com/mypath/g/?validate_geo=healthy

Il devrait aussi retourner :

ok

Cloudflare Snippets offrent une alternative plus légère à un Worker complet pour proxyfier le chemin Commanders Gateway. Un Snippet exécute du JavaScript à la périphérie et est associé à un règle de Snippet qui détermine quelles requêtes l’exécutent.

Cloudflare Snippets sont disponibles sur Pro, Business et Enterprise forfaits. Le nom d’hôte utilisé pour le gateway doit être proxyfié via Cloudflare.

Étape 1 : Créer le Snippet

Dans le dashboard Cloudflare, ouvrez votre domaine.
Allez à Rules → Snippets.
Créez un nouveau Snippet et donnez-lui un nom descriptif, par exemple Commanders Gateway.
Collez le code suivant :

const CONFIG = {
  prefix: "/mypath", // Remplacez par le chemin du gateway choisi pour votre site
  targetBase: "https://s1234.commander4.com", // Remplacez 1234 par l'ID de votre espace de travail/site
  blacklistedCookies: [
    "PHPSESSID",
    "JSESSIONID"
  ]
};

function filterCookieHeader(cookieHeader, blacklist) {
  if (!cookieHeader) return "";
  const blacklistSet = new Set(blacklist);
  return cookieHeader
    .split(";")
    .map(c => c.trim())
    .filter(c => {
      const name = c.split("=")[0].trim();
      return !blacklistSet.has(name);
    })
    .join("; ");
}

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (!url.pathname.startsWith(CONFIG.prefix)) {
      return new Response("Not Found", { status: 404 });
    }

    const remainingPath = url.pathname.slice(CONFIG.prefix.length) || "/";
    const targetUrl = `${CONFIG.targetBase}${CONFIG.prefix}${remainingPath}${url.search}`;

    const newHeaders = new Headers(request.headers);

    newHeaders.set("X-Forwarded-Host", url.host);
    newHeaders.set("X-Forwarded-Proto", "https");

    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}`);
    }

    const cookieHeader = newHeaders.get("Cookie");
    const filteredCookies = filterCookieHeader(cookieHeader, CONFIG.blacklistedCookies);
    if (filteredCookies) {
      newHeaders.set("Cookie", filteredCookies);
    } else {
      newHeaders.delete("Cookie");
    }

    newHeaders.delete("host");

    const proxyRequest = new Request(targetUrl, {
      method: request.method,
      headers: newHeaders,
      body: request.body,
      redirect: "manual"
    });

    const response = await fetch(proxyRequest);

    if (response.status >= 300 && response.status < 400) {
      return new Response(response.body, {
        status: response.status,
        headers: response.headers
      });
    }

    return response;
  }
};

Étape 2 : Personnaliser la configuration

Mettez à jour les valeurs en haut du Snippet :

prefix : remplacez /mypath par le chemin réservé à Commanders Gateway sur votre domaine.
targetBase : remplacez s1234.commander4.com par le point de terminaison Commanders Gateway associé à votre ID d’espace de travail/site.
blacklistedCookies : ajoutez tout cookie de session, sensible ou interne qui ne doit pas être transmis à Commanders Gateway.

Le Snippet transmet également le pays et la région du visiteur via X-Forwarded-Country, X-Forwarded-Regionet X-Forwarded-CountryRegion.

Les réponses de redirection de Commanders Gateway sont volontairement renvoyées au navigateur au lieu d’être suivies automatiquement à la périphérie.

Étape 3 : Configurer la règle du Snippet

Associez le Snippet à une règle qui ne correspond qu’au chemin de votre Commanders Gateway.

Par exemple, dans l’Expression Editor :

starts_with(http.request.uri.path, "/mypath")

Remplacez /mypath par le même chemin configuré dans CONFIG.prefix.

Gardez la règle du Snippet et CONFIG.prefix synchronisés. S’ils utilisent des chemins différents, les requêtes peuvent ne pas être proxyfiées comme prévu.

Déployez le Snippet après l’avoir testé avec les outils de prévisualisation de Cloudflare.

Étape 4 : Vérifier la configuration

Après le déploiement, vérifiez :

https://example.com/mypath/healthy → devrait retourner ok.
https://example.com/mypath/?validate_geo=healthy → devrait retourner ok lorsque le transfert de géolocalisation est correctement configuré.
Les cookies listés dans blacklistedCookies ne sont plus présents dans les requêtes reçues par Commanders Gateway, tandis que les autres cookies sont conservés.

Lors de l’utilisation de Cloudflare Free, la configuration repose sur un Worker simple qui proxyfie tout le trafic provenant du chemin choisi (par ex. /mypath) vers l’infrastructure Commanders Gateway.

Étape 1 : Créer le Worker

Dans le Dashboard Cloudflare, allez à Workers & Pages → Créer une application → Worker.
Copiez/collez le code suivant :

const prefix = "/mypath"; // Chemin d’exemple, remplacez-le par le chemin choisi à l’étape précédente
const sid = "12345"; // ID d’espace de travail d’exemple (alias site ID), remplacez-le par votre propre ID

// Liste des noms de cookie qui ne doivent PAS être transmis à Commanders Gateway. Vous pouvez ajouter vos cookie 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 ID d’espace de travail/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 de proxyer 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");

    // Proxyer 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 préfixe
}

Ce Worker proxyfie 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

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

Une fois enregistré, toutes les requêtes vers /mypath seront proxyées vers Commanders Gateway.

Commanders Gateway avec Akamai est en bêta. Si vous avez une question ou un problème avec votre configuration, contactez le support

Créer la règle de redirection

Créez une nouvelle version de votre configuration de diffusion dans Property Manager.
Dans la section Property Configuration Settings ajoutez une nouvelle Rule :
- Nommez-la : Route measurement
Ajoutez un nouveau Match:
- Type de correspondance : Path
- Condition : est l’un de
- Valeur : /mypath/*
Ajoutez un nouveau Comportement:
- Sélectionnez Standard Property Behavior et choisissez Origin Server comportement.
- Définir Origin Server Hostname à s1234.commander4.com.
- Définir Forward Host Header à Origin Hostname.
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 des scripts.

Inclure les informations de géolocalisation

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

Nom de la variable

Paramètres de sécurité

USER_REGION

Hidden

USER_COUNTRY

Hidden

Choisissez votre Redirect rule (créée ci-dessus) dans Property Configuration Settings.
Ajoutez deux nouveaux Set Variable comportements (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

Ajoutez deux nouveaux Modify Outgoing Request Header comportements :

Action

Select Header Name

Custom Header Name

Header Value

Add

Other...

X-Forwarded-Region

Add

Other...

X-Forwarded-Country

Enregistrez la nouvelle règle et déployez vos modifications.

Filtrer les cookies avant de les transmettre à Commanders Gateway

Vous pouvez empêcher des cookies spécifiques d’être transmis à Commanders Gateway. Cela peut être utile pour les cookies de session, les cookies contenant des informations sensibles ou les cookies techniques internes qui ne doivent pas quitter votre infrastructure.

La liste des cookies à exclure dépend des exigences de votre organisation.

Option 1 : utiliser les capacités de gestion des cookies d’Akamai

Si des comportements de gestion des cookies sont disponibles avec votre configuration Akamai, configurez Akamai pour supprimer les cookies concernés de la requête avant qu’elle ne soit transmise à Commanders Gateway.

Par exemple, vous pouvez vouloir exclure des cookies tels que :

PHPSESSID
JSESSIONID

Configurez le comportement de sorte que ces cookies soient supprimés de la requête client envoyée à l’origine, où l’origine est votre point de terminaison Commanders Gateway.

Le nom exact et la disponibilité des comportements de gestion des cookies Akamai peuvent varier selon les produits Akamai activés sur votre compte.

Option 2 : modifier l’en-tête Cookie sortant

Si les capacités de gestion des cookies ne sont pas disponibles, vous pouvez utiliser un Modify Outgoing Request Header comportement sur l’en-tête Cookie et supprimer les cookies sélectionnés à l’aide d’une expression régulière.

Exemple pour PHPSESSID et JSESSIONID:

(?:^|;\s*)(PHPSESSID|JSESSIONID)=[^;]*

Configurez :

En-tête : Cookie
Action : Remplacement par regex
Expression régulière : l’expression ci-dessus, adaptée à votre liste de cookies
Remplacement : vide

Testez soigneusement cette configuration avant de la déployer en production. Une expression régulière incorrecte peut entraîner un Cookie en-tête mal formé ou supprimer involontairement des cookies qui devraient être transmis.

Si vous utilisez plusieurs configurations CDN ou de périphérie pour la même implémentation, gardez la liste d’exclusion des cookies cohérente entre elles.

Vérifier la configuration

Après le déploiement de la configuration Akamai :

Accédez à https://example.com/mypath/healthy → devrait afficher ok.
Tester les en-têtes de géolocalisation : https://example.com/mypath/?validate_geo=healthy → devrait aussi afficher ok.
Vérifiez que les requêtes transmises à Commanders Gateway ne contiennent plus les noms de cookies exclus, tandis que les autres cookies sont toujours transmis normalement.

Le support Fastly pour Commanders Gateway est actuellement en bêta. Les étapes ci-dessous sont destinées aux utilisateurs techniques familiers avec Fastly Compute (Compute Services). Selon la configuration de votre compte Fastly (domaines, TLS, produits activés), certaines étapes de liaison en production peuvent varier.

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

Prérequis

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

export FASTLY_API_TOKEN=XXXXXXXXXXXX

Installez les prérequis :

Node.js
Fastly CLI

Étape 1 : Créer le service Compute

Créez un nouveau service Compute :

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

Fastly renvoie un ID de service, par exemple :

dyBxiT8wpc2c8ZQg2KRrMN

Enregistrez-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 l’ID de service dans fastly.toml

Modifiez fastly.toml et définissez l’ID de service :

# fastly.toml
service_id = "YOUR_SERVICE_ID"

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

Créez un backend qui pointe vers l’infrastructure Commanders Gateway (remplacez 1234 par votre ID d’espace de travail/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

Notes :

--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.
Le backend doit être s1234.commander4.com (votre propre ID d’espace de travail/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 : /mypath)
sid (votre ID d’espace de travail/site Commanders, exemple : s1234)

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

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

const prefix = "/PATHACHANGER";              // TODO : remplacez par le chemin gateway choisi (par ex. "/mypath")
const sid = "s123456";                       // TODO : remplacez par votre ID d’espace de travail/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 transmis
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);

  // Proxyfier uniquement les requêtes qui correspondent 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. "/mypath") pour que l’origine reçoive "/"
  if (STRIP_PREFIX) {
    fwdPath = fwdPath.slice(prefix.length) || "/";
  }

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

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

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

  // Transmettre les informations géographiques lorsqu’elles sont disponibles (facultatif 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 proxyer 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 de 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 point de terminaison de votre ID d’espace de travail/site.
Conservez la même valeur prefix que le chemin que vous réservez sur le domaine client (exemple : /mypath).
N’ajoutez PAS de slash final à la fin du chemin dans les URL côté client.

Étape 6 : Déploiement

Déployez le service Compute :

npm run deploy

Étape 7 : Test

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

https://plainly-rested-bison.edgecompute.app/mypath/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/mypath/), 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 (TLS géré ou certificat client).
Créer l’enregistrement DNS requis (souvent un CNAME) pour que example.com pointe vers Fastly.
S’assurer que le service Compute est celui qui reçoit les requêtes pour le chemin choisi (exemple : /mypath*) 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 ceci comme une étape bêta et contactez le support si vous avez besoin des commandes exactes pour votre configuration spécifique.

Étape 3 : Mettez à jour les scripts dans votre système de tag management ou votre site web

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

Exemples :

Google

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

<!-- Utilisez -->
<script async src="/mypath/"></script>

Meta (Facebook Pixel)

<!-- 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="/mypath/js/f4558899203.js"></script>

Snapchat

<script src="/mypath/js/a82b99df732.js"></script>

Bing (UET)

<script src="/mypath/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 :

cact(..., {collectionDomain: "www.youdomain.com/mypath"});

Avertissement : n’ajoutez PAS un / à la fin du chemin

Étape 4 : Vérifiez la configuration

Pour le chemin global, vérifiez le point de terminaison de santé :
- https://example.com/mypath/healthy → devrait retourner ok
Utilisez les outils de développement du navigateur pour vérifier que :
- Les scripts Google sont chargés depuis /mypath/
- Les scripts des autres fournisseurs sont chargés depuis /mypath/js/{obfuscated}.js
- Les requêtes sont envoyées à votre domaine first-party.
Assurez-vous que les événements apparaissent dans les dashboards des partenaires concernés (Google Analytics, Facebook Events Manager, etc.).

Avantages

Durabilité: Le tracking continue de fonctionner même avec Safari ITP et les restrictions liées aux Third-party cookie.
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 chemin (/mypath) gère tous les fournisseurs.
Pérenne: S’adapte à Privacy Sandbox et aux futures restrictions des navigateurs.

Configurez 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 /mypath) pour les principales fonctionnalités Commanders Act.

Notes importantes :

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

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

Le tracking server-side 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 le gateway, vous devez mettre à jour la configuration du tag oneTag afin que la cact() configuration utilise votre domaine de collecte First party et votre chemin.

Dans votre tag oneTag (ou dans le snippet partagé utilisé par vos tags oneTag), définissez collectionDomain:

cact(..., { collectionDomain: "www.yourdomain.com/mypath" });

Notes :

Remplacez www.yourdomain.com/mypath 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 configuré, tous les événements oneTag (page_view, add_to_cart, purchase, etc.) seront collectés via votre chemin de gateway First party.

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 global qui s’exécute avant tous les tags Commanders Act (recommandé).

Exemple :

tC.clientCollectDns = "www.yourdomain.com/mypath";

Comportement :

Dès que tC.clientCollectDns est défini, la collecte pour Data Activation, Campaign Analytics et le tracking lié au CMP se fera via le gateway.
mypath n’est qu’un exemple. Les clients peuvent utiliser n’importe quel chemin qu’ils ont configuré dans leur configuration du 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 global qui s’exécute avant tous les tags Commanders Act.

Liste de vérification

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

Le point de terminaison de santé du gateway : https://example.com/mypath/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/mypath/...).
Les événements et les données apparaissent comme prévu dans :
- les dashboards de destinations server-side (exemple : Meta Events Manager pour CAPI)
- les flows Data Activation
- les rapports de statistiques CMP et de preuve de consentement (le cas échéant)
- les rapports Campaign Analytics

PrécédentListe blanche des IP du serveur

SuivantConfig API

Mis à jour il y a 2 jours

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

Pourquoi utiliser Commanders Gateway ?

1. Avantages de l’utilisation d’un gateway

2. Avantages d’utiliser Commanders Gateway

Vue d’ensemble

Google Tag Gateway (GTG) et consent

Ce que Google Tag Gateway change pour le consent

La documentation de Google sur GTG

Vérifier si un tag est inscrit à GTG

Si un signal de consent "late" est détecté et que CAGT est confirmé

Architecture

Filtrage et gouvernance des cookie

Liste noire de cookie à l’edge

Liste blanche de cookie avant transmission aux partenaires

Avant de commencer

Étape 1 : Choisir le chemin de diffusion du tag

Étape 2 : Router le trafic

Étape 3 : Mettez à jour les scripts dans votre système de tag management ou votre site web

Google

Meta (Facebook Pixel)

Snapchat

Bing (UET)

OneTag

Étape 4 : Vérifiez la configuration

Avantages

Configurez la collecte de données First party pour les fonctionnalités Commanders Act (via Gateway)

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

2. Collecte CDP, Campaign Analytics et CMP via le gateway

Liste de vérification