Commanders Tag Gateway (closed beta)

Ce document s'adresse aux utilisateurs qui souhaitent déployer Google Tag Gateway (via Commanders Act) ou son équivalent pour d'autres partenaires (Meta, Bing, Snapchat, Awin, etc.).

Si votre objectif est d'implémenter Google Tag Gateway, vous êtes au bon endroit : Commanders Gateway suit exactement les mêmes principes de configuration que Google Tag Gateway, mais les étend à tous les principaux partenaires publicitaires et d'analyse.

Pourquoi utiliser Commanders Gateway ?

1. Avantages d'utiliser une gateway

Une configuration gateway améliore la qualité et l'exhaustivité de la collecte de données dans 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és par les adblockers.
Les restrictions des navigateurs (comme l'ITP de Safari) limitent ou bloquent souvent les cookies tiers 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 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 office de proxy pour toutes les bibliothèques fournisseurs.
Des noms de fichiers JavaScript obfusqués sont automatiquement fournis par Commanders Act, rendant leur détection par les listes de blocage beaucoup plus difficile.
Avec le même chemin simple, vous pouvez également activer d'autres fonctionnalités d'hébergement et de suivi en first-party telles que : 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 suivi en first‑party.
Une configuration centralisée simplifie le déploiement et la maintenance tout en restant préparée pour l'avenir 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 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.
D'autres bibliothèques fournisseurs 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 transférées vers les endpoints respectifs des partenaires.

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 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 script obfusqué est fourni dans l'interface Commanders Act First-Party Hosting.

Schéma (conceptuel) :

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

Before you begin

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 un load balancer (Cloudflare, Akamai, Fastly, Nginx, etc.) capable de rediriger 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 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 créerez une entrée CNAME pour un nouveau sous-domaine, créerez une Origin Rule pour transférer les requêtes, et créerez une Transform Rule pour inclure les 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 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 le DNS onglet, ouvrez les Records section.
Ajoutez un nouvel enregistrement avec :
- TypeType : CNAME
- NomNom : metrics
- Cible: s1234.commander4.com => remplacez 1234 par l'ID de votre site (alias workspace)
Enregistrez l'enregistrement CNAME.

Créer la Origin Rule

Dans le Règles 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 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' Host Header → Réécrire vers : s1234.commander4.com.
Mettez à jour l' Enregistrement DNS → Remplacer par : metrics.example.com.
Enregistrez la Origin Rule.

Inclure les informations de géolocalisation (optionnel)

Dans le Règles onglet, ouvrez Settings.
Activez le Add visitor location headers option.
Attendez quelques minutes 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 dans 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 (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 votre 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.
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 livraison dans Property Manager.
Sous le Property Configuration Settings section, ajoutez une nouvelle Rule :
- Nommez-la : Route measurement
Ajoutez un nouveau Match:
- Type de correspondance : Path
- Condition : est l'un de
- Valeur : /metrics/*
Ajoutez un nouveau Comportement:
- Sélectionnez Standard Property Behavior et choisissez Origin Server comportement.
- Définissez Origin Server Hostname de s1234.commander4.com.
- Définissez Forward Host Header de Origin Hostname.
Enregistrez la nouvelle règle et déployez vos modifications.
- ⚠️ Testez la règle de redirection dans votre environnement 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

Allez dans 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

Sélectionner le nom de l'en-tête

Nom d'en-tête personnalisé

Valeur de l'en-tête

Ajouter

Autre...

X-Forwarded-Region

Ajouter

Autre...

X-Forwarded-Country

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

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

Remplacez les URL des scripts fournisseurs 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 la Commanders Act First-Party Hosting.

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

Avantages

Durabilité : Le suivi continue de fonctionner même avec les restrictions Safari ITP et les cookies tiers.
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 fournisseurs.
Préparée pour l'avenir : S'adapte au privacy sandbox et aux prochaines restrictions des navigateurs.

PrécédentWhitelisting des IPs serveur SuivantConfig API

Mis à jour il y a 1 mois

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