Comment créer un agent IA de tracking Analytics avec n8n ?

Le tracking analytics est l’une des rares briques d’infrastructure critique d’une entreprise qui n’a historiquement aucun test automatisé, aucune alerte, aucune preuve de son propre bon fonctionnement au jour le jour. On lui fait confiance parce qu’on n’a pas le choix, pas parce qu’elle le mérite.

Ce guide construit le système qui corrige ça : un agent de tracking qui audite en continu, génère les événements depuis la source de vérité métier (les commandes réelles, pas une supposition côté navigateur), écrit dans Google Tag Manager et Google Analytics 4 sous contrôle humain strict, vérifie dans un vrai navigateur que ce qui est censé partir part réellement, et produit chaque semaine un rapport qui dit honnêtement si les chiffres sont fiables avant de dire ce qu’ils signifient.

1. Architecture de référence et principes non négociables

Avant tout code, fixez ces cinq règles. Elles ne sont pas des recommandations — ce sont les garde-fous qui rendent le reste du document sûr à suivre sans supervision constante.

Règle 1 — Séparation stricte lecture/écriture par credential. Un credential Google ou Shopify n’obtient jamais plus de scope que ce que son sous-workflow fait réellement. Pas de credential « admin général » réutilisé partout.

Découvrez égalementQuelles tâches automatiser avec n8n et l’IA ?

Règle 2 — Aucune publication automatique, jamais. Ni GTM (versions.publish), ni GA4 (rien n’empêche techniquement, mais aucune écriture destructive). La publication est un acte humain, quel que soit le niveau de confiance atteint après des mois de fonctionnement correct.

Règle 3 — Le contrat de taggage est la seule source de vérité sur les schémas. L’agent lit le contrat, ne l’écrit jamais directement. Toute proposition de modification passe par une revue humaine.

Règle 4 — Le tracking transactionnel critique (purchase, refund) est server-side, pas client-side. La partie 3 explique en détail pourquoi ce n’est pas un choix d’architecture parmi d’autres sur Shopify, mais une nécessité empirique.

Règle 5 — Chaque composant écrit un résultat structuré, jamais une erreur brute. Un sous-workflow qui échoue silencieusement ou qui plante l’appelant casse la capacité de l’agent à décider quoi faire ensuite.

Le schéma d’ensemble, avec les flux de données explicites

                    ┌─────────────────────────────────────────┐
                    │   ORCHESTRATEUR (workflow n8n, AI Agent)  │
                    │   Anthropic Claude · Memory · Tools       │
                    └───────────────┬───────────────────────────┘
                                    │ appelle (Execute Workflow)
        ┌───────────┬───────────┬──┴────────┬────────────┬────────────┐
        ▼           ▼           ▼            ▼            ▼            ▼
   [Contrat]   [Shopify RO] [GTM write] [GA4 Admin] [QA browser] [GA4 Data]
   Postgres    Admin API    workspace   customDim   Playwright   runReport
   lecture     REST API     API v2      API v1alpha  micro-svc   API v1beta
        │           │           │            │            │            │
        └───────────┴───────────┴────────────┴────────────┴────────────┘
                                    │
                    ┌───────────────▼───────────────┐
                    │   Postgres : source de vérité   │
                    │   contract / hits / reconcile   │
                    └───────────────┬───────────────┘
                                    │
        ┌───────────┬───────────┬──┴────────┬────────────┐
        ▼           ▼           ▼            ▼            
    [Canari]  [Réconciliation] [Dérive]  [Rapport hebdo]
    quotidien    quotidien      quotidien    lundi 8h

Ce schéma répond à une question qu’on me pose souvent : « pourquoi autant de composants pour tracker un simple événement d’achat ? » Réponse : parce que « tracker un achat » se décompose en réalité en cinq responsabilités indépendantes — générer l’événement, vérifier qu’il respecte un contrat, l’écrire dans les bons outils, vérifier qu’il arrive vraiment, et le documenter dans le temps. Un système qui fusionne ces responsabilités dans un seul script devient impossible à déboguer au premier incident.

2. Le contrat de taggage : modèle de données complet

Concept : versionner un contrat comme on versionne un schéma de base de données

Un contrat de taggage change dans le temps — un nouveau paramètre, un renommage, un changement de scope. Traitez ça exactement comme une migration de base de données : chaque changement est un incrément versionné, jamais une modification silencieuse de l’existant.

Action : le schéma complet, avec gestion de version

CREATE TABLE tagging_contract (
  id              BIGSERIAL PRIMARY KEY,
  event_name      TEXT NOT NULL,
  version         INT NOT NULL,
  status          TEXT NOT NULL DEFAULT 'draft',  -- draft | active | deprecated
  schema          JSONB NOT NULL,
  assertions      JSONB NOT NULL,
  emitted_by      TEXT NOT NULL,      -- 'server_webhook' | 'client_pixel' | 'gtm_tag'
  requires_consent TEXT[],            -- ex: ARRAY['analytics_storage']
  created_by      TEXT NOT NULL,      -- 'human' | 'agent_proposal'
  approved_by     TEXT,               -- login de l'humain qui a validé
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
  UNIQUE (event_name, version)
);

CREATE TABLE tagging_contract_proposals (
  id              BIGSERIAL PRIMARY KEY,
  event_name      TEXT NOT NULL,
  proposed_schema JSONB NOT NULL,
  rationale       TEXT NOT NULL,       -- pourquoi l'agent propose ce changement
  status          TEXT NOT NULL DEFAULT 'pending', -- pending | approved | rejected
  created_at      TIMESTAMPTZ NOT NULL DEFAULT now(),
  reviewed_at     TIMESTAMPTZ,
  reviewed_by     TEXT
);

Seule status = 'active' est lue par les sous-workflows en production. draft sert à préparer un changement, deprecated garde l’historique pour les hits déjà collectés avec l’ancienne version — indispensable si vous devez expliquer un mois plus tard pourquoi un rapport de mars ne compte pas le paramètre coupon de la même façon qu’un rapport de juin.

Action : le contrat complet de l’événement purchase, avec tous les cas limites

Découvrez égalementAnthropic Agents, n8n ou Trigger.dev lequel choisir ?

C’est la version enrichie de celle vue dans le tutoriel précédent — celle-ci gère explicitement les remboursements, le multi-devises et les commandes partiellement annulées, trois cas qui cassent un contrat naïf en production.

INSERT INTO tagging_contract (event_name, version, status, schema, assertions, emitted_by, requires_consent, created_by)
VALUES (
  'purchase', 2, 'active',
  '{
    "transaction_id":   {"type": "string",  "required": true, "unique": true},
    "value":            {"type": "number",  "required": true, "min": 0},
    "currency":         {"type": "string",  "required": true, "pattern": "^[A-Z]{3}$"},
    "shipping":         {"type": "number",  "required": false, "default": 0},
    "tax":               {"type": "number",  "required": false, "default": 0},
    "coupon":           {"type": "string",  "required": false, "ga4_scope": "EVENT"},
    "financial_status": {"type": "string",  "required": true, "enum": ["paid", "partially_refunded", "refunded"]},
    "items": {
      "type": "array", "min_length": 1,
      "fields": {
        "item_id":       {"type": "string",  "required": true},
        "item_name":     {"type": "string",  "required": true},
        "price":         {"type": "number",  "required": true, "min": 0},
        "quantity":      {"type": "integer", "required": true, "min": 1},
        "discount":      {"type": "number",  "required": false, "default": 0}
      }
    }
  }'::jsonb,
  '[
    "count(hits WHERE transaction_id = X) == 1",
    "abs(sum(items[].price * items[].quantity) - (value - shipping - tax)) <= 0.02",
    "currency correspond à la devise de la boutique au moment de la commande, pas à une devise de présentation",
    "si financial_status != paid alors un événement refund correspondant doit exister sous 24h"
  ]'::jsonb,
  'server_webhook',
  ARRAY['analytics_storage'],
  'human'
);

Deux choix qui méritent explication :

• financial_status fait partie du contrat de purchase, pas seulement d’un événement séparé. Sans ce champ, une commande annulée deux minutes après paiement génère un purchase qui reste indéfiniment dans vos rapports de revenu comme si elle avait abouti.
• L’assertion sur la devise n’est pas automatisable simplement — c’est volontaire. Certaines assertions du contrat sont des rappels pour la revue humaine, pas des règles que le sous-workflow Contrat peut vérifier mécaniquement. Distinguez les deux catégories dans votre documentation d’équipe, sans quoi vous attendrez d’un Code node qu’il fasse un jugement métier qu’il ne peut pas faire.

Action : l’événement refund, souvent oublié

INSERT INTO tagging_contract (event_name, version, status, schema, assertions, emitted_by, requires_consent, created_by)
VALUES (
  'refund', 1, 'active',
  '{
    "transaction_id": {"type": "string", "required": true},
    "value":           {"type": "number", "required": true, "min": 0},
    "currency":        {"type": "string", "required": true, "pattern": "^[A-Z]{3}$"},
    "items":           {"type": "array",  "required": false}
  }'::jsonb,
  '["value du refund <= value du purchase original pour le même transaction_id"]'::jsonb,
  'server_webhook',
  ARRAY['analytics_storage'],
  'human'
);

Sans cet événement, votre réconciliation (partie 13) affichera un delta permanent et inexpliqué : Shopify décompte les remboursements de son chiffre d’affaires net, GA4 ne les voit jamais si vous ne les envoyez pas explicitement.

3. Shopify réel : pourquoi le client-side ne suffit pas

C’est la section la plus importante de tout ce document. Si vous ne lisez qu’une seule partie avant de commencer à coder, lisez celle-ci.

Concept : le sandbox des Web Pixels

Depuis le passage à la « Checkout Extensibility », Shopify a retiré la possibilité d’injecter du JavaScript arbitraire dans le tunnel de commande (checkout.liquid est déprécié). Le seul mécanisme supporté pour observer des événements côté navigateur pendant le checkout est la Web Pixels API, et elle impose des contraintes lourdes :

• le code d’un pixel personnalisé s’exécute dans un iframe sandboxé, sans accès direct au DOM de la page ni à la possibilité de charger des scripts externes librement ;
• le mode preview de GTM ne fonctionne pas dans ce sandbox — vous ne pouvez pas déboguer un tag comme d’habitude, il faut inspecter la frame web-pixel-sandbox-* manuellement dans les DevTools ;
• les données de commande sont accessibles via data.checkout.lineItems et l’objet init, pas via un dataLayer classique que vous construiriez vous-même — c’est Shopify qui pousse les données, dans sa propre structure.

Ce ne sont pas des détails cosmétiques. Un retour de terrain documenté publiquement lors d’un AMA d’agence sur la migration Checkout Extensibility rapporte jusqu’à 30 % d’événements checkout_completed manquants sur des boutiques utilisant plusieurs pixels simultanément, avec des délais de déclenchement de 3 à 7 secondes qui créent des trous de tracking quand l’utilisateur quitte la page de confirmation rapidement.

Conséquence directe pour votre architecture

Découvrez égalementComment déboguer un agent IA n8n sans perdre trop d’heures ?

Ne construisez jamais votre événement purchase à partir d’un Web Pixel. C’est un mécanisme conçu pour du tracking marketing best-effort (pixels publicitaires, remarketing), pas pour un événement de revenu qui doit être exact au centime. L’architecture de ce guide contourne entièrement le problème : l’événement purchase part du webhook serveur orders/create, jamais du navigateur du client. Vous n’avez donc ni sandbox, ni iframe, ni délai de 3 à 7 secondes, ni dépendance à ce que le navigateur du client reste ouvert assez longtemps.

Là où le Web Pixel garde un rôle légitime dans votre système : les événements de funnel amont — product_viewed, add_to_cart, checkout_started — pour lesquels un peu de perte est acceptable et où il n’existe pas d’alternative serveur (Shopify n’envoie pas de webhook quand quelqu’un consulte une fiche produit). Pour ces événements, un Custom Pixel classique reste la bonne solution :

// Custom Pixel Shopify — Settings > Customer events > Add custom pixel
// S'exécute dans le sandbox : pas d'accès DOM, seulement l'API d'événements Shopify
analytics.subscribe('product_viewed', (event) => {
  const { productVariant } = event.data;
  // Transmission au conteneur GTM server-side plutôt qu'au dataLayer client :
  // évite la dépendance au preview mode cassé et centralise la logique de mapping
  fetch('https://sgtm.votre-domaine.example.com/pixel-event', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      event: 'view_item',
      item_id: productVariant.sku || productVariant.id,
      item_name: productVariant.product.title,
      price: productVariant.price.amount,
      currency: productVariant.price.currencyCode,
      client_id: init.clientId, // fourni par l'objet init du Web Pixels API
    }),
  });
});

Notez le choix d’envoyer vers un conteneur GTM server-side plutôt que de pousser dans un dataLayer — c’est délibéré : dans un sandbox sans accès au DOM parent, il n’y a de toute façon pas de dataLayer classique à alimenter facilement, et centraliser la logique de mapping côté serveur évite de dupliquer le code de transformation entre le pixel et le webhook.

Checkpoint

Avant de continuer, vérifiez dans votre Admin Shopify (Paramètres → Notifications clients → Customer events) qu’aucun ancien snippet checkout.liquid n’est encore actif — s’il l’est, la date limite de dépréciation communiquée par Shopify signifie qu’il cessera de fonctionner sans préavis supplémentaire, et vous découvririez la panne au pire moment.

4. Fondations n8n : au-delà du simple docker compose up

Concept : trois environnements, pas un seul

Un système qui écrit dans GTM et GA4 a besoin d’un environnement de test qui ne touche jamais la production. Créez, dès le départ, une propriété GA4 de test et un workspace GTM dédié aux essais distincts de vos identifiants de production — et répliquez cette distinction dans n8n avec deux jeux de credentials nommés explicitement (GTM - PROD, GTM - STAGING).

Action : configuration Docker Compose complète, avec gestion des secrets

L’exemple précédent stockait les secrets en variables d’environnement du shell — correct pour apprendre, insuffisant pour une mise en production réelle. Utilisez un fichier .env chargé automatiquement par Docker Compose, exclu de tout dépôt Git :

# .env — jamais commité, permissions 600
N8N_ENCRYPTION_KEY=...
POSTGRES_PASSWORD=...
SHOPIFY_APP_CLIENT_SECRET=...
GA4_MP_API_SECRET_PROD=...
GA4_MP_API_SECRET_STAGING=...

# docker-compose.yml, extrait pertinent
services:
  n8n:
    image: n8nio/n8n:latest
    env_file: .env
    environment:
      - N8N_HOST=votre-domaine.example.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://votre-domaine.example.com/
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=336   # 14 jours, en heures — voir partie 15 sur la rétention
      - N8N_LOG_LEVEL=info

EXECUTIONS_DATA_PRUNE et EXECUTIONS_DATA_MAX_AGE évitent que la base interne de n8n grossisse indéfiniment avec l’historique des exécutions — sans ça, une instance qui tourne un an avec des workflows planifiés quotidiens accumule des dizaines de milliers d’enregistrements, ce qui ralentit progressivement l’interface.

Action : gestion des utilisateurs et RBAC

Si plusieurs personnes de votre équipe interviennent sur ce système, n’utilisez pas un compte admin partagé. Dans Settings → Users, créez un compte par personne, et si votre édition de n8n le permet, restreignez les rôles : un profil qui peut exécuter et consulter les workflows de QA n’a pas besoin des droits d’édition sur le workflow orchestrateur ou sur les credentials à privilèges élevés. C’est la même logique de moindre privilège que sur les credentials Google et Shopify, appliquée cette fois à l’accès humain à n8n lui-même.

Checkpoint 4

Vérifiez que docker compose config n’affiche aucun secret en clair dans un fichier versionné — lancez git status dans votre dossier de travail et confirmez que .env apparaît bien dans .gitignore, pas dans la liste des fichiers suivis.

5. Credentials Google en profondeur : scopes, quotas, résilience

Les scopes, réellement, un par un

Le credential GTM de l’agent combine donc tagmanager.edit.containers + tagmanager.edit.containerversions + tagmanager.readonly — jamais publish, jamais manage.accounts.

Concept : les quotas réels de l’API GTM, et pourquoi ils changent votre design

L’API Tag Manager applique une limite de 10 000 requêtes par jour et 0,25 requête par seconde par projet, indépendamment de tout paramétrage que vous feriez côté console — dépasser ce seuil retourne une erreur 403. 0,25 QPS signifie concrètement une requête toutes les 4 secondes maximum en continu. Un audit qui boucle sur 200 tags avec un appel par tag sans throttling grille ce budget en quelques minutes et bloque le reste de votre journée d’automatisation.

Action : implémenter le backoff exponentiel recommandé par Google

Google documente explicitement la formule à utiliser en cas d’erreur 403/429 sur cette API : un délai de (2^n) + un nombre aléatoire de millisecondes, n incrémentant à chaque tentative jusqu’à 5, avec abandon après un délai total d’environ 32 secondes. Implémentez-la dans un nœud Code placé juste après chaque appel HTTP Request vers l’API GTM, en position de gestion d’erreur :

// Nœud Code — "Backoff GTM", branché sur la sortie d'erreur du HTTP Request
const attempt = $json.attempt_number || 0;
if (attempt >= 5) {
  return [{ json: { success: false, error: 'Backoff épuisé après 5 tentatives', retryable: false } }];
}
const delayMs = Math.pow(2, attempt) * 1000 + Math.floor(Math.random() * 1000);
await new Promise(resolve => setTimeout(resolve, delayMs));
return [{ json: { attempt_number: attempt + 1, retry: true } }];

Reboucler ce nœud vers le HTTP Request d’origine (avec une boucle If qui teste retry === true) donne à votre sous-workflow GTM une vraie résilience aux pics de charge, plutôt qu’un échec sec à la première contention.

Concept : les quotas de l’API GA4 Data, et ce qu’ils signifient pour vos rapports

Une propriété GA4 standard dispose de 200 000 tokens par jour, 40 000 par heure, et 10 requêtes concurrentes maximum ; la plupart des requêtes simples consomment moins de 10 tokens. En pratique, pour ce système (quelques dizaines d’appels par jour entre réconciliation, détection de dérive et rapport hebdomadaire), vous êtes très loin de ces plafonds — sauf si vous laissez l’AI Agent appeler runReport en boucle exploratoire sans limite. Fixez une limite explicite d’itérations d’outils par run de l’agent (paramètre disponible sur le nœud AI Agent) pour éviter qu’un raisonnement qui tourne en rond ne consomme un quota entier en une seule session de débogage interactif.

Checkpoint 5

Testez volontairement le dépassement de quota GTM en environnement de staging : lancez 20 appels consécutifs sans délai vers l’API depuis un nœud Code en boucle. Vous devez observer une erreur 403 après quelques secondes, et votre nœud de backoff doit la rattraper. C’est le test le plus souvent sauté, et le premier incident réel en production si vous le sautez.

6. Base de données : schéma complet et rétention

Reprenez le schéma (tagging_contract, captured_hits, reconciliation_log, agent_actions) et ajoutez ces deux tables, nécessaires pour les cas approfondis de ce guide :

-- Cache des collections/catégories produit, pour éviter un appel API par ligne de commande
CREATE TABLE product_collection_cache (
  product_id      TEXT PRIMARY KEY,
  collection_name TEXT NOT NULL,
  updated_at      TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Journal des quotas consommés, pour surveiller votre marge avant d'atteindre les plafonds documentés en partie 5
CREATE TABLE api_quota_log (
  id              BIGSERIAL PRIMARY KEY,
  api_name        TEXT NOT NULL,       -- 'gtm' | 'ga4_data' | 'ga4_admin' | 'shopify'
  calls_count     INT NOT NULL,
  window_start    TIMESTAMPTZ NOT NULL,
  window_end      TIMESTAMPTZ NOT NULL,
  recorded_at     TIMESTAMPTZ NOT NULL DEFAULT now()
);

Politique de rétention, par table

• captured_hits : conservez 90 jours en détail, puis agrégez en résumé quotidien avant purge — vous avez rarement besoin du détail ligne par ligne au-delà d’un trimestre, mais vous voulez garder la tendance.
• reconciliation_log : conservez indéfiniment. C’est un historique léger (une ligne par jour) et c’est votre meilleure preuve en cas de litige sur la fiabilité passée des chiffres.
• agent_actions : conservez 1 an minimum — c’est votre journal d’audit, en particulier utile si une question se pose sur une décision de tracking prise plusieurs mois auparavant.

7. Sous-workflow Contrat : validation complète

Reprenez la version du tutoriel précédent et enrichissez-la pour gérer les types, les valeurs par défaut et les énumérations — pas seulement la présence ou l’absence d’un champ.

// Nœud Code — validation enrichie
const contract = $input.first().json.schema;
const observed = $('Execute Workflow Trigger').first().json.observed_params;
const errors = [];

for (const [key, rule] of Object.entries(contract)) {
  const value = observed[key];
  if (rule.required && value === undefined) {
    errors.push(`${key} manquant (requis)`);
    continue;
  }
  if (value === undefined) continue; // optionnel et absent : conforme

  if (rule.type === 'number' && typeof value !== 'number') {
    errors.push(`${key} devrait être un nombre, reçu ${typeof value}`);
  }
  if (rule.pattern && !new RegExp(rule.pattern).test(value)) {
    errors.push(`${key} ne respecte pas le format attendu (${rule.pattern})`);
  }
  if (rule.enum && !rule.enum.includes(value)) {
    errors.push(`${key} = "${value}" hors de l'énumération autorisée [${rule.enum.join(', ')}]`);
  }
  if (rule.min !== undefined && value < rule.min) {
    errors.push(`${key} = ${value} sous le minimum autorisé (${rule.min})`);
  }
}

const undeclared = Object.keys(observed).filter(key => !(key in contract));

return [{
  json: {
    is_compliant: errors.length === 0 && undeclared.length === 0,
    errors,
    undeclared_params: undeclared,
  },
}];

Cette version détecte des erreurs qu’une simple vérification de présence laisse passer : un currency envoyé en minuscules, un value négatif suite à un bug de calcul de remise, un financial_status mal orthographié qui ne matche aucune valeur de l’énumération.

8. Sous-workflow Shopify : au-delà du webhook simple

Action : gérer les commandes modifiées, pas seulement créées

Un abonnement webhook unique sur orders/create ne suffit pas : une commande peut être annulée, remboursée partiellement, ou voir son adresse de livraison corrigée après création — chacun de ces cas doit mettre à jour votre vision du revenu réel. Ajoutez trois abonnements webhook supplémentaires côté Shopify Admin, chacun pointant vers son propre nœud Webhook n8n :

• orders/cancelled → marque la commande comme annulée dans captured_hits, sans renvoyer de purchase négatif (GA4 gère mal les valeurs négatives sur cette métrique) — préférez un événement refund dédié.
• refunds/create → génère l’événement refund du contrat vu en partie 2.
• orders/updated → à filtrer soigneusement : cet événement se déclenche pour des changements mineurs (note interne, tag) qui ne doivent surtout pas régénérer un hit. Un nœud IF en tête de ce sous-workflow doit vérifier explicitement que le changement concerne financial_status ou total_price avant de continuer.

Action : le filtre anti-bruit sur orders/updated

// Nœud Code — juste après la vérification HMAC du webhook orders/updated
const payload = $input.first().json.body;
const previousStatus = $input.first().json.body.previous_financial_status; // si fourni par votre app
const relevant = payload.financial_status !== previousStatus;

if (!relevant) {
  return []; // arrête la branche : aucun changement pertinent pour le tracking
}
return [{ json: payload }];

Sans ce filtre, chaque modification anodine d’une commande (un opérateur qui ajoute une note de suivi) déclenche une exécution complète de votre pipeline de génération de hit — inoffensif en soi, mais qui pollue vos logs et complique le débogage le jour où vous cherchez un vrai incident dans l’historique des exécutions.

9. Sous-workflow GTM écriture : Consent Mode v2 et GTM server-side

Concept : le Consent Mode n’est pas optionnel dans un contrat de taggage sérieux

Depuis l’entrée en vigueur du Consent Mode v2 de Google, un tag GA4 qui se déclenche sans tenir compte de l’état de consentement de l’utilisateur peut voir ses données modélisées, dégradées, ou refusées par Google selon la configuration. Votre contrat de taggage (partie 2) porte déjà un champ requires_consent — il doit se traduire en configuration réelle du tag GTM, pas rester une intention documentée.

Action : créer un tag avec configuration de consentement explicite

POST .../workspaces/{workspaceId}/tags
Body :
{
  "name": "GA4 - Event - purchase",
  "type": "gaawe",
  "parameter": [
    { "type": "template", "key": "eventName", "value": "purchase" }
  ],
  "consentSettings": {
    "consentStatus": "NEEDED",
    "consentType": [{ "type": "template", "value": "analytics_storage" }]
  },
  "firingTriggerId": ["{{ $('Créer le trigger').item.json.triggerId }}"]
}

Le champ consentSettings.consentStatus: "NEEDED" force GTM à vérifier l’état de analytics_storage avant de déclencher le tag — cohérent avec le requires_consent du contrat. Faites de la présence de ce bloc une vérification automatique de votre sous-workflow avant tout appel de création : si le contrat déclare requires_consent non vide et que le payload de création de tag ne porte pas consentSettings, refusez la création et remontez l’incohérence à l’agent plutôt que de créer un tag non conforme.

Concept : GTM server-side comme destination alternative

Si votre organisation utilise déjà un conteneur GTM server-side (recommandé dès que vous avez plusieurs destinations — GA4, Meta CAPI, Google Ads — à partir des mêmes événements), le sous-workflow Shopify de la partie 8 n’envoie pas directement au Measurement Protocol GA4, mais à l’endpoint de votre conteneur serveur, qui se charge ensuite de la distribution vers chaque plateforme avec sa propre logique de transformation et de déduplication. L’avantage pour ce système : un seul point d’entrée à sécuriser et à faire respecter le contrat, quel que soit le nombre de destinations publicitaires en aval.

// Nœud HTTP Request — envoi vers le conteneur GTM server-side plutôt qu'au Measurement Protocol direct
// URL : https://sgtm.votre-domaine.example.com/mp/collect (endpoint du conteneur serveur GTM)

Le corps de la requête reste identique à celui du Measurement Protocol standard — c’est le conteneur serveur qui absorbe cette structure et la redistribue, ce qui rend ce changement transparent pour le reste de votre sous-workflow.

10. Sous-workflow GA4 Admin : quotas et cardinalité

Concept : la cardinalité, le piège invisible des dimensions personnalisées

Une dimension personnalisée avec trop de valeurs distinctes (un item_id de plusieurs milliers de SKU, par exemple, utilisé comme dimension au lieu de rester un simple paramètre d’item) fait que GA4 agrège silencieusement les valeurs les moins fréquentes sous (other). Ce n’est pas une erreur au sens API — la création réussit, la dimension existe — mais elle devient inutilisable en rapport dès que le volume grossit.

Action : garde-fou avant création

// Nœud Code — avant tout appel customDimensions.create
const proposedDimension = $json;
const HIGH_CARDINALITY_RISK = ['item_id', 'sku', 'transaction_id', 'customer_email'];

if (HIGH_CARDINALITY_RISK.some(risky => proposedDimension.parameterName.includes(risky))) {
  return [{
    json: {
      blocked: true,
      reason: `${proposedDimension.parameterName} présente un risque de cardinalité élevée — ` +
              `ce paramètre appartient déjà à la structure "items" native de GA4 ecommerce, ` +
              `il n'a pas besoin d'une dimension personnalisée dédiée.`,
    },
  }];
}
return [{ json: { blocked: false } }];

Ce garde-fou capture une erreur de conception fréquente : demander à l’agent de « suivre le SKU en dimension personnalisée » alors que le SKU circule déjà nativement dans le tableau items de l’événement purchase, sans avoir besoin d’une dimension séparée pour être exploitable en rapport.

11. Micro-service Playwright : la matrice de test complète

Voici la matrice réelle à couvrir pour qu’un canari mérite ce nom.

Ne testez pas les 5 × 2 × 4 × 4 × 2 combinaisons chaque nuit — ce serait 320 parcours, disproportionné. Structurez plutôt en deux niveaux :

• canari quotidien : 1 seul scénario, le plus représentatif (desktop, consentement accepté, produit simple) — détecte une casse totale en moins de deux minutes d’exécution ;
• matrice hebdomadaire complète : les combinaisons pertinentes pour votre boutique réelle (retirez les cases qui ne s’appliquent pas — pas de multi-devises si vous ne vendez que dans une zone, par exemple), exécutée une fois par semaine, dont le résultat alimente le rapport du lundi.

Action : paramétrer le micro-service pour recevoir une matrice

// server.js — extension pour accepter un tableau de scénarios en une seule requête
app.post('/run-matrix', async (req, res) => {
  const { scenarios, base_url } = req.body; // tableau d'objets { consent, device, product_type, cart_type }
  const results = [];

  for (const scenario of scenarios) {
    // réutilise la logique de /run-journey vue précédemment, paramétrée par scenario
    const result = await runSingleJourney(scenario, base_url);
    results.push({ scenario, ...result });
    await new Promise(r => setTimeout(r, 500)); // espacement, pour ne pas saturer le serveur de la boutique
  }

  res.json({ results, run_at: new Date().toISOString() });
});

Le setTimeout entre chaque scénario n’est pas cosmétique : lancer 15 sessions Playwright en rafale contre votre propre boutique peut déclencher des protections anti-bot ou du rate limiting côté Shopify, faussant vos résultats de test avec des faux positifs qui n’ont rien à voir avec votre tracking.

12. L’orchestrateur AI Agent : prompt complet et maîtrise des coûts

Concept : chaque appel d’outil a un coût, en tokens et en argent

Un run d’audit qui enchaîne quinze appels d’outils avec de longues réponses JSON en contexte peut représenter plusieurs dizaines de milliers de tokens. Sur un rythme quotidien, ça se chiffre. Deux leviers de maîtrise : limiter le nombre maximal d’itérations d’outils par run (paramètre du nœud AI Agent), et réserver les runs avec agent aux tâches qui en ont réellement besoin — l’essentiel de la QA continue (partie 13) reste mécanique, sans agent.

Action : le prompt système complet, avec gestion explicite des erreurs et des limites

Tu es l'agent de tracking analytics pour [nom du site]. Ton rôle : auditer,
détecter les écarts, proposer des corrections. Tu ne publies et ne décides
jamais seul.

CONTEXTE DE CE RUN
Type de run : {{ audit_quotidien | investigation_manuelle | preparation_rapport }}
Environnement cible : {{ staging | production }} — ne mélange jamais les deux
dans un même raisonnement, vérifie toujours quel credential un outil utilise
avant de l'appeler si le choix t'est laissé.

RÈGLES STRICTES, NON NÉGOCIABLES

1. Le contrat de taggage (table tagging_contract, status='active') est la
   seule source de vérité sur les schémas d'événements. Tu ne modifies
   jamais un schéma toi-même — tu proposes, dans la table
   tagging_contract_proposals, avec une justification (`rationale`)
   explicite et vérifiable.

2. Aucun outil de publication n'existe dans ta liste. Si on te demande de
   publier une version GTM ou d'activer un changement en production,
   explique que cette action requiert une validation humaine hors de ton
   périmètre — ne cherche pas de contournement via un autre outil.

3. Si un outil retourne success: false, tu ne réessaies jamais de ta propre
   initiative avec des paramètres différents. Tu consignes l'échec avec
   son message d'erreur complet dans ton rapport et tu passes à l'élément
   suivant.

4. Tu ne calcules jamais toi-même un delta de réconciliation, un
   pourcentage, ou une somme à partir de données brutes retournées par un
   outil — utilise exclusivement les valeurs déjà calculées. Un chiffre
   que tu inventes ou recalcules mentalement est une erreur grave, même si
   le calcul te semble trivial.

5. Avant toute proposition d'écriture GTM ou GA4 Admin, appelle
   systématiquement l'outil Contrat pour vérifier la conformité du schéma
   proposé. Ne saute jamais cette étape même si tu es certain du résultat.

6. Limite : maximum 12 appels d'outils par run. Si tu approches cette
   limite sans avoir conclu, résume ce que tu as trouvé jusque-là plutôt
   que de continuer à explorer.

7. Distingue explicitement dans ton rapport final ce qui est vérifié
   mécaniquement (via un outil) de ce qui relève de ton interprétation.
   Une phrase comme "le volume semble anormal" doit toujours être
   accompagnée du chiffre exact et de sa source.

FORMAT DE SORTIE
1. État de santé (une phrase, avec le delta de réconciliation le plus
   récent disponible)
2. Écarts détectés (liste, avec la source de détection pour chacun)
3. Actions proposées, en attente d'approbation humaine (liste priorisée)
4. Rien d'autre — pas de recommandations générales hors de ce périmètre.

Les ajouts — le contexte de run, la limite explicite d’itérations, et la règle 7 sur la distinction entre fait vérifié et interprétation — répondent chacun à un mode de défaillance observé en pratique : l’agent qui mélange staging et production faute de le vérifier, le run qui part en boucle exploratoire coûteuse, et le rapport qui affirme des choses avec une confiance que les données sous-jacentes ne justifient pas.

13. QA continue : les quatre workflows planifiés, en détail

Le canari quotidien — logique complète avec gestion des faux positifs

Un canari qui alerte au moindre échec, y compris ceux causés par une panne temporaire de votre propre boutique (déploiement en cours, maintenance planifiée), génère de la fatigue d’alerte qui pousse à ignorer les vraies pannes. Ajoutez une règle de confirmation :

// Nœud Code, après réception du résultat du sous-workflow QA navigateur
const result = $input.first().json;
if (!result.assertions_failed || result.assertions_failed.length === 0) {
  return [{ json: { alert: false } }];
}

// Requête le nombre d'échecs consécutifs des 3 derniers runs avant d'alerter

Suivi d’un nœud Postgres qui compte les échecs des trois derniers jours pour le même scénario, et d’un IF qui n’alerte que si au moins deux des trois derniers runs ont échoué — un run isolé en échec se contente d’un enregistrement silencieux, pas d’une alerte Slack à 3h du matin.

La réconciliation — avec gestion des remboursements

Reprenez la logique et intégrez l’événement refund de la partie 2 : le revenu GA4 à comparer n’est plus seulement la somme des purchase, mais somme(purchase) - somme(refund) sur la même fenêtre, pour matcher la logique de revenu net que Shopify applique déjà côté source.

La détection de dérive — avec seuil adaptatif

Un seuil fixe de « alerte si nouveau paramètre détecté » génère du bruit lors de changements volontaires (vous avez ajouté un paramètre au contrat cette semaine). Faites vérifier au workflow, avant d’alerter, que le paramètre détecté n’est pas déjà présent dans une version draft ou récemment passée active du contrat — un changement délibéré ne doit jamais déclencher la même alerte qu’une dérive non intentionnelle.

14. Rapport hebdomadaire : ce qui distingue un bon rapport d’un rapport ignoré

Au-delà de la structure déjà vue (santé, changements, corrections, décisions en attente), deux ajouts qui font la différence sur la durée :

• une tendance sur 4 semaines pour le delta de réconciliation, pas seulement le chiffre de la semaine — un delta de −3 % en isolation ne dit rien ; un delta qui glisse de −2 % à −3 % à −5 % sur trois semaines consécutives est un signal, même si aucune semaine individuelle ne dépasse un seuil d’alerte.
• un lien direct vers l’exécution n8n concernée pour chaque anomalie mentionnée, pas seulement une description textuelle — la première question d’un humain qui lit une anomalie est toujours « je regarde où pour comprendre ce qui s’est passé ».

-- Requête pour la tendance 4 semaines, à intégrer dans le workflow de rapport
SELECT date_trunc('week', report_date) AS week, avg(delta_pct) AS avg_delta
FROM reconciliation_log
WHERE report_date >= now() - interval '28 days'
GROUP BY 1 ORDER BY 1;

15. Observabilité, sécurité, gouvernance

Observabilité : au-delà du journal d’exécution n8n

Le journal d’exécution natif de n8n suffit pour déboguer un run individuel, mais pas pour répondre à une question comme « combien d’écritures GTM l’agent a-t-il proposées ce trimestre, et quel pourcentage a été approuvé sans modification ? ». C’est exactement ce que la table agent_actions capture — traitez-la comme votre tableau de bord de gouvernance, pas seulement comme un journal technique.

-- Taux d'approbation des propositions de l'agent, votre meilleur indicateur de maturité
SELECT
  date_trunc('month', created_at) AS month,
  count(*) FILTER (WHERE status = 'success') AS approved,
  count(*) FILTER (WHERE status = 'failed') AS rejected_or_failed,
  round(100.0 * count(*) FILTER (WHERE status = 'success') / count(*), 1) AS approval_rate_pct
FROM agent_actions
WHERE action_type IN ('gtm_write', 'ga4_admin_write')
GROUP BY 1 ORDER BY 1;

Un taux d’approbation qui grimpe régulièrement sur plusieurs mois est votre signal légitime pour envisager d’élargir l’autonomie du système — pas une intuition, une mesure.

Sécurité : rotation des secrets

Planifiez, dès la construction initiale, une rotation trimestrielle : jeton d’accès Shopify, secret de webhook Shopify, api_secret du Measurement Protocol, clé API Anthropic. Un système qui tourne sans jamais faire tourner ses secrets pendant des années est un système où une fuite ancienne et oubliée reste exploitable indéfiniment.

Gouvernance : la revue trimestrielle du contrat

Une fois par trimestre, indépendamment de toute alerte, un humain relit l’intégralité du contrat de taggage actif — pas seulement les propositions récentes de l’agent. C’est le moment de repérer les événements devenus obsolètes (une promotion terminée dont le paramètre coupon spécifique traîne encore), et de vérifier que requires_consent reste aligné avec votre politique de confidentialité actuelle, qui peut avoir changé sans que personne ne pense à répercuter le changement jusqu’au contrat technique.

16. Checklist de mise en production

Reprend et enrichit celle du tutoriel précédent :

• [ ] credentials GTM sans publish ni manage.accounts, testés en staging avant toute connexion à un container de production
• [ ] credential Shopify en lecture seule stricte
• [ ] HMAC vérifié avec Raw Body actif, testé avec une signature invalide
• [ ] idempotence testée en rejouant deux fois le même webhook orders/create
• [ ] webhooks orders/cancelled, refunds/create et orders/updated (filtré) configurés, pas seulement orders/create
• [ ] backoff exponentiel implémenté sur les appels GTM, testé sous charge volontaire
• [ ] tags GTM créés par l’agent portent systématiquement consentSettings cohérent avec le contrat
• [ ] garde-fou de cardinalité actif sur le sous-workflow GA4 Admin
• [ ] chaque sous-workflow outil retourne un objet structuré même en échec
• [ ] approbation humaine active sur tous les outils d’écriture
• [ ] Error Trigger branché sur chacun des workflows planifiés
• [ ] limite d’itérations d’outils configurée sur le nœud AI Agent
• [ ] rétention des données définie et appliquée table par table (partie 6)
• [ ] rotation trimestrielle des secrets planifiée dans un calendrier, pas seulement documentée
• [ ] premier trimestre de revue de gouvernance planifié dès le jour du lancement

17. Dépannage exhaustif

Ressources citées

Documentation n8n, nœud AI Agent — docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.agent

Tag Manager API, limites et quotas — developers.google.com/tag-platform/tag-manager/api/v2/limits-quotas

Tag Manager API, gestion des erreurs et backoff — developers.google.com/tag-platform/tag-manager/api/v2/errors

Google Analytics Data API, quotas par propriété — documentation des classes PropertyQuota, Google Cloud

Shopify, Web Pixels API et Checkout Extensibility — shopify.dev/docs/api/web-pixels-api

Shopify, création de pixel personnalisé — help.shopify.com/en/manual/promoting-marketing/pixels/custom-pixels/code

Playwright — playwright.dev

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.