Fonctionnalités
Configuration guidée par l’IA
Votre première destination est en ligne en une seule session guidée — sans écrire un tag, et sans renoncer au contrôle de ce qui est publié.
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 MetaPublier 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
L’assistant propose, les outils valident, vous approuvez.
Exemple de session : plateforme détectée, plan d’événements proposé, jeton stocké dans le coffre-fort, un véritable événement de test accepté, publication en attente de votre approbation.
Chaque action est un appel d’outil typé que vous pouvez voir
L’assistant transforme un domaine en dispositif de mesure opérationnel : il détecte la plateforme et l’outil de consentement, propose un plan d’événements adapté à votre type d’activité, collecte les identifiants publics dans le chat et les secrets dans une carte coffre-fort, envoie un véritable événement de test et prépare un diff de publication que vous approuvez.
L’assistant n’exécute jamais de code libre. Il appelle des outils validés côté serveur : détecter la plateforme, rédiger le plan d’événements, valider un ID de pixel, envoyer un événement de test, préparer un diff. Tout ce qui est irréversible — publication, rollback, rotation des identifiants d’accès — s’arrête à une carte d’approbation liée à la modification exacte que vous avez sous les yeux.
Comment c’est construit
Les décisions techniques derrière la fonctionnalité — la preuve après le bénéfice.
01
Des outils typés plutôt que des actions libres
Chaque action de l’assistant est un appel d’outil validé côté serveur, avec contrôle des rôles, entrée d’audit et, pour tout ce qui est irréversible, un jeton d’approbation lié au diff exact que vous avez vu.
02
Les secrets n’atteignent jamais le modèle
Les jetons d’accès vont directement dans le coffre-fort chiffré via une carte dédiée ou OAuth. La transcription, le modèle et le navigateur ne les voient jamais ; une couche DLP masque les secrets et les données personnelles collés dans le chat.
03
Machine à états déterministe
La configuration suit une machine à états explicite, avec des prérequis et des preuves pour chaque état. Les mêmes états existent sous forme d’assistant à base de règles lorsque le fournisseur d’IA est indisponible — rien ne dépend de la disponibilité d’un modèle.
Configuration manuelle contre session guidée
Ce qui change quand l’assistant pilote la configuration et que vous gardez la main sur les approbations.
| Configuration manuelle contre session guidée | Configuration manuelle du conteneur | Configuration guidée avec Track |
|---|---|---|
| Plan d’événements | Écrit de mémoire, un tag à la fois | Proposé pour votre type d’activité, modifié dans le chat, validé avant publication |
| Identifiants d’accès | Collés dans les champs des tags et visibles par quiconque a accès au conteneur | Saisis dans une carte coffre-fort ou via OAuth ; jamais affichés dans la transcription |
| Vérification | Espérer que le fournisseur a reçu quelque chose | Un véritable événement de test dans le vrai pipeline, avec le verdict du fournisseur |
| Publication | Publier, puis découvrir ce qui a changé | D’abord le diff, les destinataires et l’approbation ; ensuite un bundle signé et versionné |
Ce que vous pouvez vérifier
Des faits produit que vous retrouverez dans le tableau de bord, la documentation et le journal d’audit.
- Détection du type d’activité et de la plateforme avec un niveau de confiance
- Modèles de plan d’événements pour les boutiques, la génération de leads, le SaaS et les éditeurs
- ID publics validés selon les formats des fournisseurs
- Publication uniquement après un diff, une liste de destinataires et une confirmation explicite
Questions
- L’assistant peut-il publier sans moi ?
- Non. La publication, les rollbacks, la rotation des identifiants d’accès et l’activation des destinations exigent toujours votre clic sur une carte d’approbation liée à la modification exacte.
- Quel modèle est utilisé ?
- OpenAI Responses API avec Structured Outputs et Function Calling strict. Les noms de modèles sont configurés côté serveur et vérifiés au démarrage ; l’interface ne les code jamais en dur.
Autres fonctionnalités
Construites sur la même configuration signée et le même schéma d’événements.
- Routeur d’événements côté serveur
Un événement, toutes les plateformes : transmission navigateur et serveur avec déduplication partagée.
- Event Debugger et traçabilité
Voyez chaque événement avec son instantané de consentement, sa décision de routage et la réponse du fournisseur.
- Qualité des données et score de santé
Un score unique aux composantes explicables, et des problèmes qui renvoient vers leur solution.
- Respectueux du consentement par construction
Opt-in strict par défaut, Consent Mode v2, destinations par finalité, aucun rejeu après consentement.
- ID de clic et attribution bien faits
Capturez uniquement les ID dont la destination a besoin, uniquement avec consentement, uniquement pour la fenêtre documentée.
Essayez-le sur votre domaine
Créez un site, installez un snippet et laissez l’assistant configurer la première destination en quelques minutes.