Commanders Tag Gateway (closed beta)

Ce document décrit comment déployer Commanders Tag Gateway, un unified first-party gateway qui utilise une seule configuration 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 First party.

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

Google Tag Gateway (GA4, Google Ads)
Suivi First-party vers toutes les destinations server-side
Hébergement First-party de bibliothèques third-party

Si votre objectif est d’implémenter Google Tag Gateway, vous êtes au bon endroit. Si votre objectif est de construire une architecture de suivi First-party durable et agnostique vis-à-vis des vendors, 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 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 les adblockers.
Les restrictions des navigateurs (comme l’ITP de Safari) limitent souvent ou bloquent les cookie third-party et certains cookie javascript 1st party, mais avec une configuration server-side First-party, la mesure reste plus fiable.
Ceci 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

Au-delà des bénéfices 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 single path (/metrics) sert et proxy toutes les bibliothèques vendor.
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 first-party hosting and tracking features telles que : héberger vos conteneurs de tag management, le tracking d’événements server-side, ou des statistiques CMP anonymes. Une seule configuration alimente tout votre système d’hébergement et de suivi First‑party.
Une configuration centralisée simplifie le déploiement et la maintenance tout en restant future-proof face aux prochaines restrictions des navigateurs.

Aperçu

Commanders Gateway vous permet de déployer des tags marketing et de measurement 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 first-party domain.
D’autres bibliothèques vendor 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 endpoints des partenaires respectifs.

Architecture

Avec Commanders Gateway, vous réservez un single path sur votre domaine, par exemple :

https://example.com/metrics/

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

Diagramme (conceptuel) :

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

Avant de commencer

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

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

Étape 1 : Choisir le chemin de serving des tags

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

Exemple :

/metrics

Attention : Cette configuration redirige tout le trafic comportant le chemin choisi. Pour éviter d’impacter 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 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 plutôt le setup automatisé de Cloudflare.

Créer une 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
- : CNAMENom
- : metricsCible
- : s1234.commander4.com => remplacez 1234 par l’ID de votre site (aka workspace)Enregistrez l’enregistrement CNAME.
Créer l’Origin Rule

Onglet

Dans l’onglet Rules 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 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 Enregistrement DNS → Remplacer par : metrics.example.com.
Enregistrez l’Origin Rule.

Inclure les informations de géolocalisation (optionnel)

Dans l’onglet Rules ouvrez 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 retourner ok.

Lors de l’utilisation de 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 de workspace (aka 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");

    // Proxy 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.
Naviguez vers Workers Routes.
Ajoutez une nouvelle route avec :
- Pattern 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 match : Path
- Condition : is one of
- Valeur : /metrics/*
Ajoutez un nouveau Behavior:
- Sélectionnez Standard Property Behavior et choisissez Origin Server comme comportement.
- 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 staging environment avant de 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

Caché

USER_COUNTRY

Caché

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 :
- 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.

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

Remplacez les URLs des scripts vendor 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 (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 la Commanders Act First-Party Hosting interface.

Étape 4 : Vérifier la configuration

Pour le chemin 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 vendor sont chargés depuis /metrics/js/{obfuscated}.js
- Les requêtes sont effectuées vers votre first-party domain.
Assurez-vous que les événements apparaissent dans les Dashboards respectifs des partenaires (Google Analytics, Facebook Events Manager, etc.).

Avantages

Durabilité: Le tracking continue de fonctionner même avec l’ITP de Safari et les restrictions sur les cookie 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.
Future-proof: S’adapte au privacy sandbox et aux prochaines restrictions des navigateurs.

PrécédentWhitelistage IP serveur SuivantConfig API

Mis à jour il y a 17 jours

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