Commanders Tag Gateway (closed beta)

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

Commanders Act 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 1st party.

Une configuration, un chemin 1st party, trois usages :

Google Tag Gateway (GA4, Google Ads)
Tracking 1st-party vers toutes les destinations server-side
Hébergement 1st-party de bibliothèques 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 1st-party durable et agnostique vis-à-vis des fournisseurs, vous êtes également au bon endroit.

Pourquoi utiliser Commanders Gateway ?

1. Avantages d'utiliser 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 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 1st party, 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 d'utiliser Commanders Gateway

En plus des bénéfices de toute approche gateway, Commanders Gateway apporte 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 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 1st-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 tracking 1st‑party.
Une configuration centralisée simplifie le déploiement et la maintenance tout en restant à l'épreuve du futur face aux futures restrictions des navigateurs.

Vue d'ensemble

Commanders Gateway vous permet de déployer des tags marketing et de mesure en utilisant votre propre infrastructure 1st 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 bibliothèques Google (gtag.js / gtm.js) sont chargées directement depuis votre domaine 1st 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 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/.
D'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

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

Diagramme (conceptuel) :

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

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

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 des informations de géolocalisation. Pour compléter cette configuration, vous devrez avoir 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

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 l'Origin Rule

Dans l'onglet Onglet Rules , 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 l'Origin Rule.

Inclure des informations de géolocalisation (optionnel)

Dans l'onglet 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 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"; // Chemin d'exemple, remplacez par le chemin que vous avez choisi à l'étape précédente
const sid = "12345"; // ID d'exemple du 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 }); // Retourne 404 si le chemin de la requête ne correspond pas au prefix
}

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 correspondance : Path
- Condition : is one of
- Valeur : /metrics/*
Ajoutez un nouveau Comportement:
- 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 changements.
- ⚠️ 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 des 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

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

Operation

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 changements.
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 aussi afficher ok.

Le support Fastly pour Commanders Gateway est actuellement en beta. Les étapes ci‑dessous sont destinées aux utilisateurs techniques familiers avec Fastly Compute (Compute Services). Selon la configuration de votre compte Fastly (domaines, TLS, produits activés), certaines étapes de liaison en production peuvent varier.

Lors de l'utilisation de Fastly, la configuration diffère de Cloudflare. Vous déployez un Compute service (Wasm) et le configurez principalement via le Fastly API and CLI depuis un terminal.

Prérequis

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

export FASTLY_API_TOKEN=XXXXXXXXXXXX

Installez les prérequis :

Node.js
Fastly CLI

Étape 1 : Créer le service Compute

Créez un nouveau service Compute :

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

Ceci 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

Éditez fastly.toml et définissez le service ID :

# fastly.toml
service_id = "YOUR_SERVICE_ID"

Étape 4 : Créer le backend (origine Commanders Gateway)

Créez un backend qui pointe vers l'infrastructure Commanders Gateway (remplacez 1234 par votre workspace/site ID) :

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

Notes :

--version 1 est un point de départ typique. Si votre service a déjà des versions, utilisez la version que vous prévoyez de déployer.
L'adresse du backend doit être s1234.commander4.com (votre propre workspace/site ID).

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

const STRIP_PREFIX = true;                   // Si true, supprime le préfixe du chemin transféré
const PREPEND_PATH = "/gateway";             // Point d'entrée interne sur le côté Commanders (ne pas changer)

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

async function handleRequest(request) {

  const url = new URL(request.url);

  // Ne proxyfie que les requêtes correspondant au prefix configuré
  if (!url.pathname.startsWith(prefix)) {
    return new Response("Not Found", { status: 404 });
  }

  // Construire le chemin qui sera transféré à Commanders Gateway
  let fwdPath = url.pathname;

  // Optionnellement supprimer le préfixe client (ex. "/metrics") afin que l'origine reçoive "/"
  if (STRIP_PREFIX) {
    fwdPath = fwdPath.slice(prefix.length) || "/";
  }

  // Préfixer le point d'entrée interne de Commanders (requis)
  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 en-têtes et ajouter les infos de forwarding
  const headers = new Headers(request.headers);
  headers.set("X-Forwarded-Host", url.host);

  // Transmettre les infos géo quand 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}`);

  // Éviter les conflits d'en-tête 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 s'assurer que les hits de mesure ne sont jamais mis en cache
  const co = new CacheOverride("pass");

  // Envoyer la requête vers le backend Fastly configuré
  return fetch(originReq, { backend: BACKEND, cacheOverride: co });

}

Important :

Remplacez s1234.commander4.com par votre véritable endpoint workspace/site ID.
Conservez le même prefix que le chemin que vous réservez sur le domaine client (exemple : /metrics).
NE PAS ajouter de slash final à la fin du chemin dans les URLs côté client.

Étape 6 : Déployer

Déployez le service Compute :

npm run deploy

Étape 7 : Tester

Après le déploiement, Fastly fournit un domaine temporaire pour les tests, par exemple :

https://plainly-rested-bison.edgecompute.app/metrics/healthy

Cela devrait retourner :

ok

Liaison de production (domaine client)

À ce stade, le service Compute fonctionne sur un domaine de test fourni par Fastly. Pour passer en production sur le domaine client (exemple : https://example.com/metrics/), vous devez toujours lier le service au domaine de production et vous assurer que le TLS est en place.

Cela implique typiquement, selon la configuration du client :

Ajout du domaine client au service Fastly et configuration du TLS pour celui-ci (TLS géré ou certificat client).
Création de l'enregistrement DNS requis (souvent un CNAME) afin que example.com pointe vers Fastly.
S'assurer que le service Compute est celui qui reçoit les requêtes pour le chemin choisi (exemple : /metrics*) sur ce domaine.

Étant donné que 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 ceci comme une étape en bêta et contactez le support si vous avez besoin des commandes exactes pour votre configuration spécifique.

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

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

OneTag

Vous pouvez changer 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 le 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 1st party.
Assurez-vous que les événements 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 seul chemin (/metrics) gère tous les vendors.
Pérennité: S'adapte au 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 router la collecte de données Commanders Act via votre first party gateway path (par exemple /metrics) pour les principales fonctionnalités de Commanders Act.

Notes importantes :

Le chemin gateway montré dans les exemples (/metrics) n'est qu'un exemple. Les clients choisissent leur propre chemin lors de la configuration du gateway dans leur CDN ou outil edge (Cloudflare, Akamai, etc.).
Tous les exemples ci-dessous supposent que votre gateway est sain : https://example.com/metrics/healthy retourne ok.

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

Le tracking server-side de Commanders Act repose sur des oneTag tags. Typiquement, vous aurez un oneTag par événement que vous souhaitez collecter, par exemple :

page_view
add_to_cart
purchase

Pour router ces événements oneTag via le gateway, vous devez mettre à jour la oneTag tag configuration afin que le cact() setup utilise votre domaine et chemin 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" });

Notes :

Remplacez www.yourdomain.com/metrics avec votre propre domaine et le chemin que vous avez configuré dans votre gateway.
Ne PAS ajouter un slash final / à la fin du chemin.
Une fois cela défini, tous les événements 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 du 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 à l'intérieur de chaque tag concerné, ou
dans un global configuration tag 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éfini, la collecte pour Data Activation, Campaign Analytics, et le tracking lié au CMP sera effectuée via le gateway.
metrics n'est qu'un exemple. Les clients peuvent utiliser n'importe quel chemin qu'ils ont configuré dans leur setup 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 global configuration tag qui s'exécute avant tous les tags Commanders Act.

Checklist de vérification

Après avoir appliqué les changements ci-dessus, vérifiez :

Le endpoint de santé du gateway : https://example.com/metrics/healthy retourne ok.
Dans les DevTools du navigateur (onglet Réseau), les requêtes de collecte Commanders Act vont vers votre domaine et chemin first party (par exemple https://example.com/metrics/...).
Les événements et données apparaissent comme prévu dans :
- Les dashboards des destinations server-side (exemple : Meta Events Manager pour CAPI)
- Les flows Data Activation
- Les statistiques CMP et les rapports de preuve du consentement (lorsque applicable)
- Le reporting Campaign Analytics

PrécédentListe blanche des IP serveur 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

hashtagVue d'ensemble

hashtagArchitecture

hashtagAvant de commencer

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

hashtagÉtape 2 : Router le trafic

hashtagPrérequis

hashtagÉtape 1 : Créer le service Compute

hashtagÉtape 2 : Créer un projet Compute local (starter kit)

hashtagÉtape 3 : Configurer le service ID dans fastly.toml

hashtagÉtape 4 : Créer le backend (origine Commanders Gateway)

hashtagÉtape 5 : Implémenter la logique de routage dans src/index.js

hashtagÉtape 6 : Déployer

hashtagÉtape 7 : Tester

hashtagLiaison de production (domaine client)

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

hashtagGoogle

hashtagMeta (Facebook Pixel)

hashtagSnapchat

hashtagBing (UET)

hashtagOneTag

hashtagÉtape 4 : Vérifier 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 d'utiliser un gateway

2. Avantages d'utiliser Commanders Gateway

Vue d'ensemble

Architecture

Avant de commencer

Étape 1 : Choisir le chemin de service des tags

Étape 2 : Router le trafic

Prérequis

Étape 1 : Créer le service Compute

Étape 2 : Créer un projet Compute local (starter kit)

Étape 3 : Configurer le service ID dans fastly.toml

Étape 4 : Créer le backend (origine Commanders Gateway)

Étape 5 : Implémenter la logique de routage dans src/index.js

Étape 6 : Déployer

Étape 7 : Tester

Liaison de production (domaine client)

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

Google

Meta (Facebook Pixel)

Snapchat

Bing (UET)

OneTag

Étape 4 : Vérifier 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