Commanders Tag Gateway (closed beta)

Ce document décrit comment déployer Commanders Act Tag Gateway, un gateway unifiée en first-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 en first-party.

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

Google Tag Gateway (GA4, Google Ads)
Tracking 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 de tracking en first-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 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 les adblockers.
Les restrictions des navigateurs (comme l'ITP de Safari) limitent ou bloquent souvent 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 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 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 reverse-proxy toutes les bibliothèques des vendors.
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 en first-party telles que : héberger vos containers de tag management, du tracking d'événements server-side, ou des statistiques anonymes CMP. Une seule configuration alimente l'ensemble de votre système d'hébergement et de tracking 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 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.
Les autres bibliothèques 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 transférées vers les endpoints 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 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  →  Endpoint du vendor

Filtrage et gouvernance des cookies

Certaines organisations, en particulier celles ayant des politiques de confidentialité strictes, peuvent craindre d'envoyer des cookies en first-party à des partenaires externes comme Google. Commanders Gateway prend en charge la minimisation des données et fournit des mécanismes pour contrôler quels cookies peuvent transiter par la gateway. Deux approches complémentaires peuvent être utilisées :

Liste noire des cookies au niveau edge

Les clients peuvent filtrer les cookies directement au niveau du CDN ou de la couche edge (Cloudflare Worker, Fastly Compute, etc.). Cela peut être fait en configurant simplement le code Worker fourni dans ce guide pour supprimer des cookies spécifiques avant que la requête soit transférée à Commanders Gateway.

Cela permet de retirer des cookies spécifiques de la requête avant qu'elle n'atteigne Commanders Gateway, en s'assurant que seuls les cookies approuvés par l'organisation quittent son infrastructure.

Liste blanche de cookies avant transfert aux partenaires

Commanders Gateway peut également appliquer une liste blanche de cookies lors du transfert des requêtes aux partenaires.

Par exemple, lors du transfert de requêtes de mesure à Google, la gateway peut être configurée pour n'inclure que les cookies liés à Google (tels que _ga ou _gcl_*). Tous les autres cookies sont automatiquement exclus de la requête envoyée à Google.

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 des 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 reroute 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 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 devrez disposer d'un plan Cloudflare Enterprise. Si vous n'avez pas de plan Enterprise, envisagez d'utiliser à la place la configuration automatisée Cloudflare.

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

Dans l'onglet 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' Host Header → Réécrire en :
(http.host eq "example.com" and starts_with(http.request.uri.path, "/metrics")) s1234.commander4.com. Enregistrement DNS → Remplacer par :.
metrics.example.com

Enregistrez l'Origin Rule.

Dans l'onglet Onglet Rules Inclure les informations de géolocalisation (optionnel).
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.

Cloudflare Free Lors de l'utilisation de Cloudflare Free, la configuration repose sur un simple Worker /metricsqui proxyfie tout le trafic depuis le chemin choisi (par ex.

) vers l'infrastructure Commanders Gateway.

Étape 1 : Créer le Worker Dans le Dashboard Cloudflare, allez dans Workers & Pages → 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 de workspace/site d'exemple, 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éfixeCe 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. Allez à.
Workers Routes
- Ajoutez une nouvelle route avec :: Pattern d'URL
- Create applicationwww.example.com/metrics*

: sélectionnez le Worker créé à l'étape 1. /metrics Une fois enregistré, toutes les requêtes vers

Akamai Commanders Gateway avec Akamai est enbeta

. 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 la section Property Configuration Settings
- , ajoutez une nouvelle Rule : Saisissez un nom de règle, tel que
Nommez-la : Ajoutez un nouveau:
- Match Type de Match :
- Path Condition :
- est l'un de Valeur :
Nommez-la : /metrics/*:
- Comportement Sélectionnez Standard Property Behavior et choisissez Origin Server
- comme comportement. Définissez Origin Server Hostname → Réécrire en :
- comme comportement. sur Origin Server Hostname Forward Host Header.
Origin Hostname
- Enregistrez la nouvelle règle et déployez vos changements. ⚠️ 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 Naviguez vers la section Property Variables

et ajoutez les variables suivantes :

Nom de la variable

Paramètres de sécurité

USER_REGION

Hidden

USER_REGION

USER_COUNTRY 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_REGION

Extract

PMUSER_USER_COUNTRY

Region Code

(créée ci‑dessus) sous Property Configuration Settings. Country Code Modify Outgoing Request Header

comportements :

Action

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

Custom Header Name

Header Value

Ajouter

X-Forwarded-Country

Other...

Header Value

Ajouter

X-Forwarded-Host

Origin Hostname
{{user.PMUSER_USER_COUNTRY}}
- Vérifiez la configuration : Vous pouvez vérifier en naviguant vers : Naviguez vers : Cela devrait retourner.
- → devrait afficher Tester les en-têtes de géolocalisation : https://example.com/metrics/?validate_geo=healthy Cela devrait retourner.

Fastly Commanders Gateway avec Akamai est enLe support Fastly pour Commanders Gateway est actuellement en

. 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 est différente de Cloudflare. Vous déployez un Compute service (Wasm) et le configurez principalement via l'API Fastly et le CLI

depuis un terminal.

Prérequis
Créez un token API dans l'interface Fastly (les scopes doivent permettre Compute, services, backends et déploiements).

Exportez le token dans l'environnement de votre 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 retourne unservice 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 (origin Commanders Gateway) 1234 Créez un backend qui pointe vers l'infrastructure Commanders Gateway (remplacez

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

Remarques : --version 1
est un point de départ typique. Si votre service a déjà des versions, utilisez la version que vous comptez 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 /metrics)
(votre chemin client, exemple : 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 que vous avez 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 côté Commanders (ne pas modifier)

event.respondWith(handleRequest(event.request));

  async function handleRequest(request) {

  addEventListener("fetch", (event) => event.respondWith(handleRequest(event.request)));
  // Ne proxyfie que les requêtes qui correspondent au préfixe 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") pour que l'origine reçoive "/"
    if (STRIP_PREFIX) {
  }

  fwdPath = fwdPath.slice(prefix.length) || "/";
  // Prépendre le point d'entrée interne de Commanders (requis)
    if (PREPEND_PATH) {
  }

  fwdPath = PREPEND_PATH + fwdPath;
  // URL finale d'origine sur l'infrastructure Commanders

  const target = `https://${sid}.commander4.com${fwdPath}${url.search}`;
  // Cloner les en-têtes et ajouter les informations de forwarding
  const headers = new Headers(request.headers);

  headers.set("X-Forwarded-Host", url.host);
  // Transférer les informations géo lorsque 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, {
    const proxyRequest = new Request(targetUrl, {
    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 au backend Fastly configuré
  return fetch(originReq, { backend: BACKEND, cacheOverride: co });

}

Important :

Remplacez L'adresse du backend doit être par votre véritable ID de workspace/site endpoint.
Conservez le même Vous devez mettre à jour : que le chemin que vous réservez sur le domaine du client (exemple : /metrics).
NE PAS ajouter une barre oblique terminale à 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 :

Cela devrait retourner

Binding 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 généralement, selon la configuration du client :

Ajouter le domaine du client au service Fastly, et configurer le TLS pour celui-ci (managed TLS ou certificat client).
Créer 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.

Parce que les étapes exactes dépendent des produits Fastly activés sur le compte et de la façon dont le client gère le TLS et le DNS, considérez ceci comme une étape 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 des vendors 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 le 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 health :
- Vous pouvez vérifier en naviguant vers : → devrait renvoyer Cela devrait retourner
Utilisez les DevTools du navigateur pour vérifier que :
- Les scripts Google sont chargés depuis /metrics/
- Les autres scripts 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 dashboards des partenaires respectifs (Google Analytics, Facebook Events Manager, etc.).

Avantages

Durabilité: Le tracking continue de fonctionner même avec ITP de Safari et les restrictions sur les third-party cookie.
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.
Préparation pour l'avenir: 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 Commanders Act.

Remarques 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 healthy : Vous pouvez vérifier en naviguant vers : retourne Cela devrait retourner.

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

Le tracking server-side de Commanders Act repose sur 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 de sorte 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" });

--ssl-sni-hostname s1234.commander4.com

Remplacez www.yourdomain.com/metrics avec votre propre domaine et le chemin que vous avez configuré dans votre gateway.
NE PAS ajouter une barre oblique terminale / à la fin du chemin.
Une fois ceci défini, tous les événements oneTag (page_view, add_to_cart, purchase, etc.) seront collectés via votre chemin gateway first party.

2. CDP, Campaign Analytics et collecte CMP via le gateway

(Data Activation, Campaign Analytics, statistiques CMP et preuve de 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 fourni qu'à titre d'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 à l'intérieur du 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 :

L'endpoint de santé du gateway : Vous pouvez vérifier en naviguant vers : retourne Cela devrait retourner.
Dans les DevTools du navigateur (onglet Network), 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 les données apparaissent comme prévu dans :
- Les dashboards des destinations server-side (exemple : Meta Events Manager pour CAPI)
- Les flux Data Activation
- Les statistiques CMP et les rapports de preuve de consentement (le cas échéant)
- Les rapports Campaign Analytics

PrécédentWhitelisting IP serveur SuivantConfig API

Mis à jour il y a 5 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

hashtagFiltrage et gouvernance des cookies

hashtagListe noire des cookies au niveau edge

hashtagListe blanche de cookies avant transfert aux partenaires

hashtagAvant de commencer

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

hashtagÉtape 2 : Router le trafic

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

Aperçu

Architecture

Filtrage et gouvernance des cookies

Liste noire des cookies au niveau edge

Liste blanche de cookies avant transfert aux partenaires

Avant de commencer

Étape 1 : Choisir le chemin de service des tags

Étape 2 : Router le trafic

É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