Commanders Tag Gateway (closed beta)

Ce document décrit comment déployer Commanders Tag Gateway, un gateway unifié en first-party qui utilise une configuration unique et un seul chemin sur votre domaine pour alimenter plusieurs cas d'utilisation de suivi et d'hébergement.

Commanders Tag 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 en first-party.

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

Google Tag Gateway (GA4, Google Ads)
Suivi en first-party vers toutes les destinations server-side
Hébergement en 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 durable de suivi en first-party, indépendante des vendors, vous êtes également au bon endroit.

Pourquoi utiliser Commanders Gateway ?

1. Avantages d'utiliser un gateway

Une configuration de gateway améliore la qualité et l'exhaustivité de la collecte de données à travers votre stack marketing.

Les scripts des vendors sont servis depuis votre propre domaine, ce qui réduit la probabilité d'être bloqués par des adblockers.
Les restrictions des navigateurs (comme l'ITP de Safari) limitent souvent ou bloquent les cookies third-party et certains cookies javascript 1st party, mais avec une configuration server-side en first-party, la mesure reste plus fiable.
Cela garantit un suivi plus précis, 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 bénéfices de toute approche de 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 fait proxy pour toutes les bibliothèques des vendors.
Des noms de fichiers JavaScript obfusqués sont fournis automatiquement 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 suivi en first-party telles que : héberger vos containers de tag management, le suivi d'événements server-side, ou des statistiques anonymes de CMP. Une seule configuration alimente l'ensemble de votre système d'hébergement et de suivi en first‑party.
Une configuration centralisée simplifie le déploiement et la maintenance tout en restant pérenne face aux prochaines restrictions des navigateurs.

Aperçu

Commanders Gateway vous permet de déployer des tags marketing et de mesure en utilisant votre propre infrastructure en 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 en first-party.
D'autres bibliothèques de vendors sont servies depuis /metrics/js/ en utilisant des noms de fichiers obfusqués.
Toutes les requêtes de mesure sont proxyfiées via votre domaine avant d'être transmises aux points de terminaison des partenaires respectifs.

Architecture

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

https://example.com/metrics/

Scripts Google (gtag.js / gtm.js) sont chargés directement depuis /metrics/.
Autres scripts de vendors (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

La correspondance entre chaque vendor et son nom de fichier script obfusqué est fournie 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  →  point de terminaison du vendor

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 load balancer (Cloudflare, Akamai, Fastly, Nginx, etc.) capable de transférer les requêtes vers des endpoints externes.

Étape 1 : Choisir le chemin de service des tags

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

Exemple :

/metrics

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

Étape 2 : Routage du 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 transférer les requêtes, et créer une Transform Rule pour inclure des informations de géolocalisation. Pour compléter 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 de Cloudflare à la place.

Créer l'entrée CNAME

Remarque : 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'onglet DNS 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'onglet Onglet Rules Origin Rules et créez une nouvelle règle.
Saisissez un nom de règle, comme Route measurement.
Faites correspondre les requêtes entrantes en fonction d'une expression de filtre personnalisée :

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

Mettez à jour l'en-tête Host Header → Réécrire en : s1234.commander4.com.
Mettez à jour l'en-tête DNS Record → Remplacer par : metrics.example.com.
Enregistrez l'Origin Rule.

Inclure les informations de géolocalisation (optionnel)

Dans l'onglet Onglet Rules Paramètres.
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.

Lorsque vous utilisez Cloudflare Free, la configuration repose sur un simple Worker qui proxyfie tout le trafic depuis le chemin choisi (par ex. /metrics) vers l'infrastructure Commanders Gateway.

Étape 1 : Créer le Worker

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

const prefix = "/metrics"; // Exemple de chemin, remplacez par le chemin que vous avez choisi à l'étape précédente
const sid = "12345"; // Exemple d'ID workspace (alias site ID), remplacez par votre propre ID

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

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 workspace/site ci-dessus)
    const targetUrl = `https://s${sid}.commander4.com${url.pathname}${url.search}`;

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

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

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

    // Proxyfier 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 proxyfie les requêtes tout en ajoutant des en-têtes supplémentaires (X-Forwarded-Host, X-Forwarded-Country, X-Forwarded-Region).

Étape 2 : Lier le Worker au chemin

Dans Cloudflare, ouvrez les paramètres de votre domaine.
Accédez à Workers Routes.
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 proxyfiées vers Commanders Gateway.

Commanders Gateway avec Akamai est 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 delivery 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 : est un de
- Valeur : /metrics/*
Ajoutez un nouveau Comportement:
- Sélectionnez Standard Property Behavior et choisissez Origin Server comme comportement.
- Définissez Origin Server Hostname à s1234.commander4.com.
- Définissez 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 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

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) sous Property Configuration Settings.
Ajoutez deux nouveaux Set Variable comportements (un par variable) :

Variable

Create Value From

Get Data From

Edgescape Field

Opération

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

Ajouter

Other...

X-Forwarded-Region

Ajouter

Other...

X-Forwarded-Country

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

Étape 3 : Mettre à jour les scripts dans votre tag management system ou sur votre site

Remplacez les URLs des scripts des vendors par les nouveaux chemins en first-party.

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 (chemin 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 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/metrics"});

Attention : ne PAS ajouter un / à la fin du chemin

Étape 4 : Vérifier la configuration

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

Bénéfices

Durabilité: Le suivi continue de fonctionner même avec l'ITP de Safari et les restrictions sur les cookies third-party.
Résilience: Servir des scripts depuis votre domaine avec des noms de fichiers obfusqués rend plus difficile l'intervention des règles de blocage.
Configuration centralisée: Un seul chemin (/metrics) gère tous les vendors.
Pérennité: S'adapte au privacy sandbox et aux prochaines restrictions des navigateurs.

PrécédentServer IP Whitelisting SuivantConfig API

Mis à jour il y a 10 jours

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

hashtagPourquoi utiliser Commanders Gateway ?

hashtag1. Avantages d'utiliser un gateway

hashtag2. Avantages d'utiliser Commanders Gateway

hashtagAperçu

hashtagArchitecture

hashtagAvant de commencer

hashtagÉtape 1 : Choisir le chemin de service des tags

hashtagÉtape 2 : Routage du trafic

hashtagÉtape 3 : Mettre à jour les scripts dans votre tag management system ou sur votre site

hashtagGoogle

hashtagMeta (Facebook Pixel)

hashtagSnapchat

hashtagBing (UET)

hashtagOneTag

hashtagÉtape 4 : Vérifier la configuration

hashtagBénéfices

Pourquoi utiliser Commanders Gateway ?

1. Avantages d'utiliser un gateway

2. Avantages d'utiliser Commanders Gateway

Aperçu

Architecture

Avant de commencer

Étape 1 : Choisir le chemin de service des tags

Étape 2 : Routage du trafic

Étape 3 : Mettre à jour les scripts dans votre tag management system ou sur votre site

Google

Meta (Facebook Pixel)

Snapchat

Bing (UET)

OneTag

Étape 4 : Vérifier la configuration

Bénéfices