Track

Intégration · destination

Generic webhook

Webhooks JSON signés vers vos propres systèmes avec des champs sur liste d’autorisation.

ServeurImplémentée · vérifiée par rapport à la documentation du fournisseur · vérifiée le 2026-09-02

Comment les événements atteignent Webhook

Chaque chemin aboutit au même endroit : le moteur de règles vérifie la finalité de consentement requise par cette destination, retire ce qui ne doit pas sortir, et le worker livre avec l’identifiant d’événement partagé.

  • API serveur — livraison par le worker avec nouvelles tentatives, contrôles d’état, classification des erreurs et un aperçu masqué du payload pour chaque tentative.
Flux de données de votre site web et de vos systèmes vers Webhook, via TrackChaque chemin aboutit au même endroit : le moteur de règles vérifie la finalité de consentement requise par cette destination, retire ce qui ne doit pas sortir, et le worker livre avec l’identifiant d’événement partagé.Votre serveurAPI serveurserveurTrackrègles · dédupConsentement: NécessaireWebhook
Chemins pris en charge uniquement. Les modes non pris en charge ne sont pas dessinés — ni revendiqués.

Ce qui est envoyé

Uniquement ce que vous configurez dans le mapping des événements, et uniquement après que le moteur de règles a autorisé l’événement pour cette destination.

  • Nom et horodatage de l’événement, mappés des événements standard de Track vers les noms d’événements de la plateforme.
  • L’identifiant d’événement partagé dans le champ id de la plateforme, afin que les livraisons navigateur et serveur ne soient comptées qu’une fois.
  • Aucun identifiant de clic de fournisseur — cette destination est votre propre système, l’attribution reste donc chez vous.
  • Identifiant de commande, valeur, devise et articles pour les événements de type achat.
  • Identifiants hachés en SHA-256 (e-mail, téléphone, identifiant externe) pour la correspondance — uniquement avec le consentement requis et uniquement s’ils ont été capturés.
  • L’état du consentement sous lequel l’événement a été collecté, lorsque la plateforme accepte des signaux de consentement.

Jamais envoyé

  • Adresses e-mail, numéros de téléphone ou noms en clair — les identifiants sont hachés à l’ingestion.
  • Valeurs déduites : l’inconnu reste inconnu, rien n’est deviné.
  • Événements collectés sans la finalité requise par cette destination.
  • Secrets : les jetons résident dans le coffre-fort chiffré et n’atteignent jamais le navigateur, l’assistant ni un journal.

Données techniques

Champ de déduplication
idevent id
Identifiants de clic
aucun
Finalité du consentement
Nécessaire
Version d’API figée
1
État de l’implémentation
Implémentée · vérifiée par rapport à la documentation du fournisseur · vérifiée le 2026-09-02
Documentation du fournisseur
Documentation Track

Ce dont vous avez besoin

Les identifiants publics peuvent être saisis dans le chat ou dans l’assistant guidé ; les secrets passent par la carte d’identifiants d’accès sécurisée ou par OAuth, et sont stockés chiffrés.

Identifiants publics

url
URL du point de terminaison (https)

Identifiants d’accès

Secret de signature (généré par Track)
signing_secret stockées dans le coffre-fort chiffré

Consentement

Fonctionne sous la finalité nécessaire, car elle cible vos propres systèmes (traitement côté responsable du traitement). Les identifiants sont tout de même retirés sans consentement analytics, et les identifiants de clic sans consentement marketing.

Configuration en quelques étapes

L’assistant exécute les vérifications détaillées. Vous voyez les étapes clés qui nécessitent une décision de votre part.

  1. Saisir les identifiants

    Ajoutez les identifiants publics de la plateforme. Les formats sont validés par rapport à la documentation du fournisseur avant tout enregistrement.

  2. Connecter les identifiants d’accès

    Collez le jeton dans la carte sécurisée ou connectez le compte via OAuth. Les secrets vont directement dans le coffre-fort chiffré.

  3. Mapper et tester

    Les événements standard sont pré-mappés vers les noms d’événements de la plateforme. Un événement de test marqué traverse le pipeline réel et affiche la réponse du fournisseur.

  4. Publier

    Vérifiez le diff, approuvez, publiez une version de configuration signée. Revenez en arrière en un clic si nécessaire.

Extrait de Tracking Knowledge

Pas encore d’article dédié — le hub Tracking Knowledge couvre le tracking côté serveur, la déduplication et le consentement en général.

Questions

Puis-je fonctionner uniquement côté serveur ?

Oui. Choisissez le mode serveur dans l’assistant guidé ; le script du fournisseur n’est jamais chargé, et la correspondance repose sur les identifiants hachés et les identifiants de clic capturés par le tracker.

Comment les doublons sont-ils évités ?

Le tag navigateur et la requête serveur portent le même identifiant d’événement, et les achats ajoutent l’identifiant de commande. Le worker déduplique également les événements source répétés avant la livraison.

Que se passe-t-il si l’API du fournisseur change ?

Les versions d’API sont figées de manière centralisée avec leur date de vérification ; des avertissements de fin de vie apparaissent dans l’état de santé de la destination bien avant le retrait d’un endpoint.

Connecter Webhook

Configurez-la avec l’assistant guidé ou laissez l’assistant IA s’en charger dans le chat.