Fonctionnalités
Routeur d’événements côté serveur
Envoyez chaque conversion une seule fois et laissez chaque plateforme la recevoir de la façon qui compte le mieux pour elle — navigateur, serveur ou les deux — sans double comptage.
Santé des destinations
Données d’exemple: État d’exemple statique — pas de trafic réel, aucune donnée client réelle.| Destination | Mode | Santé | Dernière transmission | File d’attente |
|---|---|---|---|---|
| Meta | navigateur + serveur | opérationnelle | il y a 12 s | 0 nouvelle tentative |
| Google Ads | serveur | opérationnelle | il y a 40 s | 0 nouvelle tentative |
| TikTok | navigateur + serveur | dégradée, circuit breaker ouvert | il y a 6 min | 3 dans la dead-letter queue |
| serveur | en pause par kill switch | il y a 2 h | retenue |
Santé, mode et file d’attente par destination ; les échecs sont gérés, pas cachés.
Exemple de santé des destinations : deux destinations opérationnelles, une panne de fournisseur gérée par le circuit breaker, une destination mise en pause par un kill switch.
Navigateur et serveur partagent un seul ID d’événement
Track reçoit les événements du SDK navigateur, de votre serveur, des plateformes e-commerce et des réseaux d’affiliation, les normalise dans un schéma unique, applique le consentement et les route vers 22 types de destinations avec nouvelles tentatives, circuit breakers, dead-letter queue et rejeu.
Le SDK navigateur et votre serveur (ou le webhook de votre boutique) envoient le même achat avec le même ID d’événement. Track normalise les deux, évalue le consentement par destination et les transmet ; Meta, TikTok, Pinterest, Snapchat, Microsoft, LinkedIn et les autres dédupliquent sur cet ID, Google Ads sur l’ID de commande.
Comment c’est construit
Les décisions techniques derrière la fonctionnalité — la preuve après le bénéfice.
01
Hybride par défaut
Chaque destination peut fonctionner via tag navigateur, API serveur ou les deux. Les deux chemins partagent un seul ID d’événement, si bien que Meta, TikTok, Pinterest, Snapchat, Microsoft, LinkedIn et les autres dédupliquent de façon fiable.
02
Durable et observable
Une file d’attente durable avec des messages idempotents, des nouvelles tentatives par destination avec backoff et jitter, des circuit breakers sur les fournisseurs défaillants, un stockage dead-letter et le rejeu. Chaque tentative est enregistrée avec un aperçu masqué de la charge utile.
03
First-party dès la conception
Le tracker est servi depuis votre hôte CDN, les événements vont vers votre hôte d’ingestion, les bundles de configuration sont signés en Ed25519 et vérifiés dans le navigateur avant tout chargement.
Tags navigateur seuls contre routeur hybride
Pourquoi un événement passé par Track vaut plus que le même pixel déclenché deux fois.
| Tags navigateur seuls contre routeur hybride | Tags navigateur seuls | Navigateur + serveur avec Track |
|---|---|---|
| Événements perdus | Scripts bloqués et onglets fermés font simplement disparaître la conversion | Le chemin serveur la transmet quand même ; le chemin navigateur ajoute les données de correspondance quand elles sont disponibles |
| Doublons | Le pixel et l’API serveur comptent la même commande deux fois | ID d’événement et ID de commande communs ; les fournisseurs dédupliquent |
| Panne du fournisseur | Échec silencieux, aucune nouvelle tentative | Nouvelles tentatives avec backoff, circuit breaker, dead-letter queue et rejeu |
| Où vont les données | Des points de terminaison tiers appelés depuis la page | Hôte d’ingestion first-party ; les fournisseurs ne reçoivent que les champs mappés |
Ce que vous pouvez vérifier
Des faits produit que vous retrouverez dans le tableau de bord, la documentation et le journal d’audit.
- SDK navigateur maintenu sous 30 Ko gzip par un budget CI, avec stockage conditionné au consentement
- API serveur avec clés de source pour le CRM et les conversions hors ligne
- Kill switches par site et par organisation
- Data plane UE avec isolation des tenants au niveau des lignes
Questions
- Le tracking côté serveur contourne-t-il le consentement ?
- Non. Le consentement est évalué pour chaque événement et chaque destination ; sans la finalité requise, rien n’est stocké, envoyé ni rejoué plus tard.
- Que se passe-t-il quand un fournisseur est en panne ?
- Les transmissions sont retentées avec backoff, le circuit breaker met la destination en pause, les événements en échec atterrissent dans la dead-letter queue et peuvent être rejoués une fois le fournisseur rétabli.
Autres fonctionnalités
Construites sur la même configuration signée et le même schéma d’événements.
- Configuration guidée par l’IA
Décrivez votre site, confirmez chaque étape, publiez une configuration signé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.