Commanders Tag Gateway

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

Commanders Act Tag 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 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 libraries 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 et indépendante des fournisseurs, vous êtes également 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 des 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é d’être bloqué par les adblockers.
Les restrictions des navigateurs (comme l’ITP de Safari) limitent ou bloquent souvent les cookies tierces parties 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, 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 seul chemin (/metrics) sert et proxy toutes les libraries des fournisseurs.
Des noms de fichiers JavaScript obfusqués sont automatiquement fournis par Commanders Act, rendant la détection par les listes de blocage beaucoup plus difficile.
Avec le même chemin simple, vous pouvez aussi activer d’autres fonctionnalités d’hébergement et de tracking first-party comme : héberger vos containers 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 futures restrictions des navigateurs.

Aperçu

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 et les services de vos partenaires (Google, Meta, Bing, Snapchat, Awin, etc.).

Avec Commanders Gateway :

Les libraries Google (gtag.js / gtm.js) sont chargées directement depuis votre domaine first-party.
Les autres libraries des fournisseurs sont servies depuis /metrics/js/ en utilisant des noms de fichiers obfusqués.
Toutes les requêtes de mesure sont proxyées via votre domaine avant d’être transmises aux endpoints des partenaires concernés.

Architecture

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

https://example.com/metrics/

Les scripts Google (gtag.js / gtm.js) sont chargés directement depuis /metrics/.
Les scripts des autres 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/ (tags Google)
         →  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 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 :

Blacklisting des cookies en edge

Les clients peuvent filtrer les cookies 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 les onglets CloudFlare free ou Faslty ci-dessous) pour supprimer des cookies spécifiques avant que la requête ne soit transmise à Commanders Gateway.

Cela permet de supprimer 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.

Whitelisting des cookies avant l’envoi aux partenaires

Commanders Gateway peut également imposer une whitelist de cookies 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 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 est déjà configuré avec :

Un système de tag management (Commanders Act, Google Tag Manager, ou équivalent).
Un CDN ou un load balancer (Cloudflare, Akamai, Fastly, Nginx, etc.) capable de proxy des requêtes vers des endpoints externes.

Étape 1 : Choisir le chemin de diffusion du tag

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

Exemple :

/metrics

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

Étape 2 : Router le trafic

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 pour rediriger les requêtes, et créer une Transform Rule 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 d’utiliser la configuration automatisée Cloudflare à la place.

Créer une entrée CNAME

Note : Les tags n’utiliseront pas cette entrée CNAME ; Cloudflare l’utilise 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

Dans l’ DNS onglet, ouvrez la section Records .
Ajoutez un nouvel enregistrement avec :
- Type: CNAME
- Name: metrics
- Target: s1234.commander4.com => remplacez 1234 par l’ID de votre site (alias workspace)
Enregistrez l’enregistrement CNAME.

Créer la Origin Rule

Dans l’ Rules onglet, ouvrez Origin Rules et créez une nouvelle règle.
Saisissez un nom de règle, tel que Route measurement.
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"))

Mettez à jour le Host Header → Réécrire vers : s1234.commander4.com.
Mettez à jour le DNS Record → Remplacer par : metrics.example.com.
Enregistrez la Origin Rule.

Inclure les informations de géolocalisation (optionnel)

Dans l’ Rules onglet, ouvrez Settings.
Activez l’option Add visitor location headers .
Attendez quelques minutes pour la propagation.

Vous pouvez vérifier en naviguant vers :

https://example.com/metrics/healthy

Cela devrait renvoyer ok.

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

Étape 1 : Créer le Worker

Dans le Dashboard Cloudflare, allez dans Workers & Pages → Create application → Worker.
Copiez/collez le code suivant :

const prefix = "/metrics"; // Chemin d’exemple, remplacez-le par le chemin choisi à l’étape précédente
const sid = "12345"; // ID de workspace d’exemple (alias 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 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 proxy 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 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 proxy 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.
Naviguez vers Workers Routes.
Ajoutez une nouvelle route avec :
- URL pattern: www.example.com/metrics*
- Worker: sélectionnez le Worker créé à l’étape 1.

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

Commanders Gateway avec Akamai est actuellement en beta. 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.
Sous la section Property Configuration Settings , ajoutez une nouvelle Rule :
- Nommez-la : Route measurement
Ajoutez un nouveau Match:
- Type de correspondance : Path
- Condition : is one of
- Valeur : /metrics/*
Ajoutez un nouveau 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.
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 pourrait casser les scripts.

Inclure les informations de géolocalisation

Naviguez vers la section Property Variables et ajoutez les variables suivantes :

Nom de la variable

Paramètres de sécurité

USER_REGION

Masqué

USER_COUNTRY

Masqué

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

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

Add

Other...

X-Forwarded-Region

Add

Other...

X-Forwarded-Country

Enregistrez la nouvelle règle et déployez vos modifications.
Vérifiez la configuration :
- Naviguez vers : 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.

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 (domains, 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 Compute service (Wasm) et le configurez principalement via l’ Fastly API et CLI depuis un terminal.

Prérequis

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

export FASTLY_API_TOKEN=XXXXXXXXXXXX

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

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 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 (l’ID de votre propre 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 (l’ID de votre workspace/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 que vous avez choisi (par ex. "/metrics")
const sid = "s123456";                       // TODO : remplacez par l’ID de votre workspace/site (par ex. "s1234")
const BACKEND = "commander_gateway";         // Nom du backend Fastly pointant vers sid.commander4.com

const STRIP_PREFIX = true;                   // Si true, 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);

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

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

  // Optionnellement supprimer 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 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}`;

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

  // Transmettre les informations géo lorsque 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 proxy 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 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
  });

  // 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 par le véritable endpoint 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é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/metrics/healthy

Il devrait retourner :

ok

Liaison 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 le TLS est en place.

Cela implique généralement, selon la configuration 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 cela 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 sur votre site web

Remplacez les URLs des scripts éditeur par les nouveaux first-party paths.

Exemples :

Google

<!-- 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)

<!-- 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

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

Bing (UET)

<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 le collectionDomain propriété Exemple :

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

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

Étape 4 : Vérifiez la configuration

Pour le path global, vérifiez l’endpoint de santé :
- https://example.com/metrics/healthy → devrait retourner ok
Utilisez les DevTools du navigateur pour vérifier que :
- Les scripts Google sont chargés depuis /metrics/
- Les autres scripts éditeurs sont chargés depuis /metrics/js/{obfuscated}.js
- Les requêtes sont effectuées vers votre domaine first-party.
Assurez-vous que les events 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 path unique (/metrics) gère tous les éditeurs.
À l’épreuve du temps: 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 faire passer la collecte de données Commanders Act via votre first party gateway path (par exemple /metrics) pour les principales fonctionnalités Commanders Act.

Notes importantes :

Le gateway path montré dans les exemples (/metrics) n’est qu’un exemple. Les clients choisissent leur propre path 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/metrics/healthy renvoie ok.

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

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

page_view
add_to_cart
purchase

Pour faire passer ces events oneTag via le gateway, vous devez mettre à jour la configuration du tag oneTag afin que la cact() configuration utilise votre domaine et votre path de collecte first party.

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

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 events oneTag (page_view, add_to_cart, purchase, etc.) seront collectés via votre first party gateway path.

2. CDP, Campaign Analytics et collecte 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/metrics";

Comportement :

Dès que tC.clientCollectDns est définie, la collecte pour Data Activation, Campaign Analytics et le tracking lié à CMP sera effectuée via le gateway.
metrics n’est qu’un exemple. Les clients peuvent utiliser n’importe quel path 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é 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 events et les données apparaissent comme prévu dans :
- Les dashboards de 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

PrécédentServer IP Whitelisting SuivantConfig API

Mis à jour il y a 7 heures

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

hashtagPourquoi utiliser Commanders Gateway ?

hashtag1. Avantages de l’utilisation d’un gateway

hashtag2. Avantages de l’utilisation de Commanders Gateway

hashtagAperçu

hashtagArchitecture

hashtagFiltrage des cookies et gouvernance

hashtagBlacklisting des cookies en edge

hashtagWhitelisting des cookies avant l’envoi aux partenaires

hashtagAvant de commencer

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

hashtagÉtape 2 : Router le trafic

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

hashtagGoogle

hashtagMeta (Facebook Pixel)

hashtagSnapchat

hashtagBing (UET)

hashtagOneTag

hashtagÉtape 4 : Vérifiez la configuration

hashtagAvantages

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

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

hashtag2. CDP, Campaign Analytics et collecte CMP via le gateway

hashtagChecklist de vérification

Pourquoi utiliser Commanders Gateway ?

1. Avantages de l’utilisation d’un gateway

2. Avantages de l’utilisation de Commanders Gateway

Aperçu

Architecture

Filtrage des cookies et gouvernance

Blacklisting des cookies en edge

Whitelisting des cookies avant l’envoi 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 sur votre site web

Google

Meta (Facebook Pixel)

Snapchat

Bing (UET)

OneTag

Étape 4 : Vérifiez la configuration

Avantages

Configurer 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. CDP, Campaign Analytics et collecte CMP via le gateway

Checklist de vérification