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

Pourquoi utiliser Commanders Gateway ?

1. Avantages d'utiliser une gateway

Une configuration en 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 souvent ou bloquent les cookies third-party et certains cookies javascript 1st party, mais avec une configuration server-side first-party, la mesure reste plus fiable.
Cela garantit un suivi 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 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 proxyfie toutes les bibliothèques des fournisseurs.
Des noms de fichiers JavaScript obfusqués sont automatiquement fournis par Commanders Act, rendant leur détection par les listes de blocage bien plus difficile.
Avec ce même chemin simple, vous pouvez également activer d'autres fonctionnalités d'hébergement et de suivi 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 first‑party.
Une configuration centralisée simplifie le déploiement et la maintenance tout en restant prête 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 librairies Google (gtag.js / gtm.js) sont chargées directement depuis votre domaine first-party.
Les 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 transmises aux 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.

il stocke le titre de la page (à partir de la balise <title> html).

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

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

Diagramme (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 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 des requêtes vers des endpoints externes.

Étape 1 : Choisissez le chemin de service des tags

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

il stocke le titre de la page (à partir de la balise <title> html).

/metrics

Attention : Cette configuration redirige tout le trafic avec 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 transférer les requêtes, et créer une Transform Rule pour inclure les informations de géolocalisation. Pour compléter cette configuration, vous aurez besoin 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 Enregistrements section.
Ajoutez un nouvel enregistrement avec :
- Type: CNAME
- Nom: 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, par exemple 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 l'information de géolocalisation (optionnel)

Dans le Règles onglet, ouvrez Settings.
Activez le Add visitor location headers option.
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 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 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 votre 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 }); // 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 : 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 behavior.
- 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 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

Sélectionnez 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 :
- 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 : Mettez à jour les scripts dans votre tag management system ou votre site web

Remplacez les URLs des scripts fournisseurs 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="/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 automatiquement généré et disponible dans le 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 retourner 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 Safari ITP 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 fournisseurs.
Prête pour l'avenir : S'adapte au privacy sandbox et aux prochaines restrictions des navigateurs.

PrécédentWhitelisting IP serveur SuivantConfig API

Mis à jour il y a 2 mois

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