Comment ça fonctionne
De votre domaine à des conversions vérifiées sur chaque plateforme
Un snippet sur votre site, une session guidée avec l’assistant, une configuration signée que vous approuvez. Track prend les événements en charge à partir de là — avec un consentement évalué pour chaque destination et un débogueur qui vous montre ce qui s’est passé.
Quatre étapes clés, une seule session
C’est le point de vue du client. Les contrôles techniques derrière chaque étape sont détaillés plus bas.
Créez votre site
Inscrivez-vous avec votre domaine. Track crée le site, un ID de tracking public à six caractères et le snippet d’une ligne.
- Vous
- saisissez le domaine et collez le snippet — ou installez l’application Shopify, WooCommerce ou Shopware
- Vous obtenez
- une installation vérifiée : Track voit la première page vue et confirme la propriété par DNS, fichier ou balise meta
Le snippethtml<script async src="https://cdn.track.site/v1/tracker.js" data-site-id="TRACKING_ID"></script>Servi depuis un hôte CDN first-party ; la configuration qu’il charge est signée en Ed25519 et vérifiée avant toute exécution.
Laissez l’assistant proposer la configuration
L’assistant détecte la plateforme et l’outil de consentement, propose un plan d’événements pour votre type d’activité et demande les ID publics des plateformes que vous utilisez.
- Vous
- répondez à quelques questions et saisissez les ID de pixel dans le chat, les jetons d’accès dans la carte coffre-fort
- Vous obtenez
- un brouillon de configuration avec des événements mappés et un véritable événement de test accepté par le fournisseur
Configuration guidée
Données d’exemple: État d’exemple statique — pas de trafic réel, aucune donnée client réelle.Track AI
example-shop.test fonctionne sur Shopify avec Cookiebot comme outil de consentement (confiance élevée). Pour une boutique, je suggère view_item, add_to_cart, begin_checkout et purchase. Dois-je rédiger le plan pour Meta et Google Ads ?
Vous
Oui, Meta d’abord.
Track AI
ID de pixel validé. La Conversions API a besoin d’un jeton d’accès — veuillez le saisir dans la carte coffre-fort ci-dessous ; il n’apparaît jamais dans ce chat.
Carte coffre-fort · jeton d’accès Meta
Stocké chiffré ; visible par personne, pas même par le modèle.
stockéÉvénement de test · purchase
Envoyé dans le vrai pipeline avec le code d’événement de test du fournisseur.
accepté par Metaen attente de votre approbationPublier la version 13
Liée exactement à ce diff et à vous en tant qu’approbateur.
- + destination meta: browser + server
- + mapping purchase → Purchase (event id, order id)
- ~ consent: marketing required for meta
Approuver et publierL’assistant propose, les outils valident, vous approuvez.
Approuvez et publiez
Vous voyez le diff, les destinataires et l’exigence de consentement de chaque destination. Une approbation publie un bundle signé et versionné.
- Vous
- lisez le diff et cliquez sur approuver
- Vous obtenez
- une configuration en ligne avec son numéro de version, rollback disponible en un clic
Configuration · version 13
Données d’exemple: État d’exemple statique — pas de trafic réel, aucune donnée client réelle.en ligne- Approuvée par
- vous, liée au diff que vous avez lu
- Signature
- Ed25519, vérifiée par le SDK
- Destinations
- Meta (navigateur + serveur), Google Ads (serveur)
- Rollback
- version 12, un clic
Observez et améliorez
Le débogueur montre chaque événement avec sa décision, le score de santé indique quoi corriger, et l’assistant propose la correction.
- Vous
- consultez le score lorsqu’il change ; approuvez les améliorations
- Vous obtenez
- des conversions vérifiées sur chaque plateforme, avec des preuves pour chaque événement
Santé du tracking
Données d’exemple: État d’exemple statique — pas de trafic réel, aucune donnée client réelle.Score
86 / 100
Composantes
- Couverture du consentement91 · 20 % de pondération
91 % des événements portent un signal de consentement explicite
- Événements critiques78 · 25 % de pondération
7 des 9 événements critiques planifiés observés
- Qualité du schéma74 · 15 % de pondération
74 % des événements passent les contrôles de schéma et de données personnelles
- Doublons96 · 10 % de pondération
1,0 % de doublons
- Transmission88 · 20 % de pondération
94 % transmis, 1 intégration avec des problèmes d’identifiants d’accès
- Fraîcheur100 · 10 % de pondération
Dernier événement navigateur il y a 4 min
Problèmes ouverts
- purchase sans currencySolution : mettre à jour le mapping de l’événement
12 événements au cours des dernières 24 h n’ont pas le paramètre obligatoire
- Signal de consentement manquantSolution : connecter l’adaptateur CMP
9 % des événements sont arrivés sans état de consentement explicite
Composantes pondérées ; un score plus bas pointe toujours vers sa cause.
D’où viennent vos événements
Passez d’un mode de transmission à l’autre. Chaque destination peut fonctionner en navigateur seul, en serveur seul ou avec les deux ; le mode hybride est le réglage par défaut, parce que les deux chemins couvrent mutuellement leurs lacunes.
Événements depuis le SDK navigateur
Le snippet collecte les pages vues, les vues de produits et les événements de panier dans le navigateur du visiteur et les envoie à l’hôte d’ingestion de Track. Les tags des fournisseurs ne se chargent qu’après consentement. Ce mode s’installe vite mais dépend du navigateur : scripts bloqués et onglets fermés perdent des événements.
- Installation : un snippet
- Consentement : évalué dans le navigateur, puis à nouveau sur le serveur
- Lacune : aucun événement si le script est bloqué ou si l’onglet se ferme trop tôt
Événements depuis votre serveur ou votre boutique
Votre plateforme e-commerce, votre backend ou votre CRM envoie les conversions à l’API serveur avec une clé de source. Achats, remboursements et conversions hors ligne arrivent de façon fiable et ne sont jamais bloqués dans le navigateur. Les données de correspondance se limitent à ce que votre serveur connaît.
- Installation : application de boutique ou requête signée depuis votre backend
- Fiable pour les achats, les remboursements, les leads issus de votre CRM
- Lacune : moins de signaux navigateur pour la correspondance
Les deux chemins, un seul ID d’événement
Le navigateur et le serveur envoient la même conversion avec le même ID d’événement. Track normalise les deux, applique la décision de consentement par destination et les transmet ; les fournisseurs dédupliquent sur l’ID d’événement ou l’ID de commande. Vous obtenez la portée du chemin serveur avec la qualité de correspondance du chemin navigateur.
- Mode par défaut pour chaque destination qui prend en charge les deux
- Déduplication : ID d’événement (Meta, TikTok, Pinterest, Snapchat, Microsoft, LinkedIn …), ID de commande (Google Ads)
- Consentement : une décision par événement et par destination pour les deux chemins
Ce que Track vérifie en chemin
Afficher les contrôles techniques derrière les quatre étapes clés
Ces contrôles s’exécutent pendant la session guidée, puis dans le worker. C’est grâce à eux que les quatre étapes clés suffisent — vous n’avez pas à les vérifier à la main.
Site et installation
- Format du domaine et accessibilité
- Propriété par enregistrement DNS, fichier de vérification ou balise meta
- Snippet présent et signature de la configuration vérifiée dans le navigateur
- Première page vue reçue sur l’hôte d’ingestion
Plateforme, outil de consentement et plan d’événements
- Plateforme e-commerce ou CMS détectée avec un niveau de confiance
- Outil de consentement détecté (TCF 2.2, GPP, Cookiebot, OneTrust, Usercentrics ou API de consentement)
- Modèle de plan d’événements choisi selon le type d’activité (boutique, génération de leads, SaaS, éditeur)
- Paramètres obligatoires par événement standard, règles de nommage pour les événements personnalisés, données personnelles bloquées dans les propriétés
Destinations et identifiants d’accès
- ID publics validés selon le format du fournisseur
- Jetons d’accès stockés dans le coffre-fort via une carte ou OAuth ; jamais dans la transcription
- Finalité de consentement requise par chaque destination enregistrée
- Matrice des ID de clic vérifiée : chaque ID transmis uniquement à sa plateforme
Test, relecture et publication
- Événement de test envoyé dans la vraie file d’attente et le vrai worker ; verdict du fournisseur enregistré
- Diff, liste des destinataires et approbateur liés à un seul jeton d’approbation
- Bundle signé en Ed25519, versionné et immuable
- Entrée d’audit pour chaque appel d’outil et chaque approbation
Après la mise en ligne
- Score de santé : couverture du consentement, événements critiques, qualité du schéma, doublons, transmission, fraîcheur
- Nouvelles tentatives avec backoff, circuit breaker et dead-letter queue par destination
- Problèmes regroupés par empreinte, chacun nommant l’outil qui le corrige
- Rollback vers n’importe quelle version antérieure
Deux plans, une configuration signée
Un control plane pour les personnes et l’assistant, un data plane pour les événements. Ils ne partagent rien d’autre que la configuration signée — une preuve technique après les étapes clés, pas un prérequis pour utiliser Track.
| Composant | Responsabilité |
|---|---|
| SDK navigateur | Stockage conditionné au consentement, adaptateurs CMP, transport par lots, tracking des SPA, chargeurs de fournisseurs avec ID de déduplication communs. Maintenu sous 30 Ko gzip par un budget CI. |
| Collecteur | Liste d’autorisation des origines, limites de débit, requêtes serveur signées HMAC, kill switches, remise à la file d’attente durable avant le renvoi du 202. |
| Worker | Normalisation, analyse des données personnelles, règles de consentement, stockage des événements, déduplication des conversions, registre d’usage, fan-out, transmission avec nouvelles tentatives et DLQ. |
| Control plane | Tableau de bord et assistant : outils typés, approbations, journal d’audit, RBAC, facturation, centre de confidentialité — séparés du data plane. |
Questions
- Ai-je besoin d’un tag manager ?
- Non. Le tracker charge lui-même les tags des fournisseurs après consentement. Les configurations GTM existantes peuvent coexister pendant la migration.
- Où les données sont-elles traitées ?
- Dans l’UE. Les API des fournisseurs ne reçoivent que ce que vous avez configuré, sur la base de transfert documentée affichée pour chaque destination.
- Comment la configuration est-elle protégée ?
- Les bundles sont immuables, versionnés et signés en Ed25519 ; le SDK vérifie la signature avant d’appliquer toute configuration.
- Et si le fournisseur d’IA est indisponible ?
- Les mêmes états de configuration existent sous forme d’assistant à base de règles. Rien dans le pipeline ne dépend de la disponibilité d’un modèle.
Prêt quand vous l’êtes
Créez votre site, collez le snippet et laissez l’assistant configurer la première destination.