Les pages de tarifs consultées, la démo regardée à moitié, la documentation qui les a fait venir : tout s’est passé sur votre site avant que le formulaire soit rempli. Événements capture tout cela avec un seul snippet et le rattache au contact dès qu’il s’identifie, sur le même profil que vos agents lisent par MCP et REST.
Les inscriptions arrivent plus vite qu’on ne peut se renseigner sur chacune, et la réponse à « pourquoi cette personne est-elle là » dort généralement dans un outil d’analytics web : trois visites de la page de tarifs et une démo regardée à moitié, rattachées à un identifiant de cookie anonyme que rien ne relie au CRM. Résultat : un lead arrivé chaud est traité à froid, et les recherches que le fondateur faisait autrefois à la main n’ont plus lieu du tout.
Les visites de la page de tarifs, la démo regardée à moitié, les articles de blog qui les ont fait venir. Tout est rattaché au contact au moment où il s’inscrit, pour que votre agent puisse répondre à « Pourquoi Jane est-elle là, et quel est son niveau d’intérêt ? » avec de vraies preuves.
Onze événements anonymes de visitor_a91c appartiennent désormais à Jane : les retours sur la page de tarifs, la démo regardée à 75 %, l’étude de cas, jusqu’à l’article de blog qui l’a amenée il y a 14 jours.
{ "contact_id": "ctc_01H…", "email": "[email protected]", "name": "Jane Reyes",
"company": { "domain": "acme.com", "industry": "fintech" },
"first_touch": { "referring_domain": "google.com", "landing_page": "/blog/customer-context-for-agents" },
"events": [
{ "event": "page_view", "url": "/blog/customer-context…", "at": "…14d", "resolved_from": "visitor_a91c" },
{ "event": "page_view", "url": "/pricing", "at": "…6d", "referring_domain": "google.com" },
{ "event": "video_milestone", "name": "product_demo", "at": "…6d", "milestone": 75 },
{ "event": "button_click", "text": "Compare plans", "at": "…2d" },
{ "event": "form_submit", "form_id": "signup", "at": "…now" }
],
"device": { "browser": "Chrome", "os": "macOS", "device_type": "Desktop" }
}Un enregistrement DNS TXT, ajouté une seule fois, prouve que le domaine vous appartient : aucun événement n’est accepté d’ailleurs. Ensuite, une balise script sur chaque page à couvrir.
Pages vues, sorties de page, premières visites, clics sur les boutons et les liens, envois de formulaires et événements vidéo : nommés et enrichis côté serveur avec le navigateur, l’OS, l’appareil et le référent. Rien à instrumenter.
Un seul appel relie le navigateur à votre identifiant utilisateur et rattache rétroactivement tout ce que la personne a fait avant : le parcours anonyme fait désormais partie du contact.
Vérifiez votre domaine une fois avec un enregistrement DNS TXT : les événements ne sont acceptés que depuis les domaines qui vous appartiennent. Ensuite, une ligne avant </body> : un script de 5 Ko compressé en gzip, snippet.js.
<script async src="https://events.pathbound.ai/snippet.js"></script>Un seul appel associe le navigateur à votre identifiant utilisateur : tout ce que la personne a fait avant, jusqu’à la première page vue, se rattache rétroactivement au contact. Un POST /v1/identify côté serveur ou un simple cookie fonctionnent aussi.
// After login (or any page where you know who the user is):
window.pathbound = window.pathbound || [];
window.pathbound.push(['identify', user.externalId, { email: user.email }]);cookie d’opposition respecté · HTTPS uniquement · aucun cookie tiers · domaines vérifiés uniquement · limites de débit par domaine · empreinte stable, qui n’identifie personne d’un site à l’autre.
Événements est une seule base, avec plusieurs portes d’entrée. Chaque source est résolue vers les mêmes contacts et arrive dans la même chronologie.
Une balise script capture automatiquement pages vues, clics, envois de formulaires et vidéo, et un appel identify à la connexion les relie à la personne. Aucune taxonomie d’événements à concevoir, aucune instrumentation page par page.
Installer le snippet →Déjà instrumenté dans PostHog ? L’intégration rapatrie ces événements par synchronisation dans la même base, résolus vers les mêmes contacts. Gardez PostHog pour l’analytics produit ; vos agents lisent une seule chronologie.
L’intégration PostHog →Les outils d’analytics comptent des sessions. Événements résout des personnes : quatorze jours de navigation anonyme et un utilisateur connecté forment une seule fiche, pas deux.
Un cookie visiteur et un identifiant de session suivent le navigateur. Quand les cookies sont effacés, une empreinte d’appareil stable retrouve l’identifiant visiteur précédent : le parcours survit au lieu de se scinder.
window.pathbound.identify() depuis la page, un POST /v1/identify authentifié depuis votre backend, ou un cookie posé par votre application. Les trois partagent la même clé de jointure : les combiner est donc sans risque.
Le rattachement déplace les événements au lieu de les copier. Le référent et les UTM de la première interaction sont écrits une seule fois et jamais écrasés. Aucun chemin d’ingestion ne modifie jamais la clé d’un contact identifié.
Le fonctionnement complet (cookies, empreinte d’appareil, cascade d’identification) est documenté dans Identité et empreinte d’appareil.
Pas de fenêtre de traitement par lots. Un événement est sur le profil au moment où il se produit : un agent sur une conversation de support en cours voit la visite de la page de tarifs de ce matin, pas l’export d’hier. La même base répond aux requêtes REST et aux outils MCP.
curl "https://api.pathbound.ai/v1/events?event_types=page_view&url_contains=/pricing&identified_only=true" \
-H "Authorization: Bearer YOUR_API_KEY"Tous les filtres et les schémas sont dans la référence de l’API Événements ; pour les agents, les mêmes données sont servies par le MCP données clients.
Les pages vues (y compris les changements de route d’une SPA), les sorties de page avec le temps passé sur la page, les premières visites, les clics sur les boutons et les liens, les envois de formulaires et les événements vidéo Wistia : lectures, pauses, fins de lecture, paliers à 25/50/75/100 % et capture d’e-mail dans la vidéo. Le tout sans configuration ; l’appel identify est le seul code que vous écrivez.
Ils sont enregistrés sous un identifiant visiteur anonyme. Quand la personne s’identifie (formulaire d’inscription, connexion ou identify côté serveur), tout son parcours se rattache rétroactivement au contact. Les événements sont déplacés, pas dupliqués, et le référent, la page d’arrivée et les UTM de la première interaction sont écrits une seule fois sur le contact, jamais écrasés par les visites suivantes.
Non. La capture automatique nomme les événements pour vous (page_view, button_click, form_submit), avec le texte de l’élément, l’URL et le référent déjà joints. Vous ajoutez un appel identify à la connexion ; tout le reste est automatique.
Non, et vous pouvez utiliser les deux. L’intégration PostHog rapatrie vos événements PostHog par synchronisation dans la même base, rattachés aux mêmes contacts. Gardez PostHog pour l’analytics produit ; Événements est ce qui fait arriver ce comportement sur le profil client que lisent vos agents.
Uniquement first-party : aucun cookie tiers, HTTPS uniquement, et les événements ne sont acceptés que depuis les domaines que vous avez vérifiés par un enregistrement DNS TXT. Personne d’autre ne peut envoyer d’événements en votre nom. Un cookie pathbound_dnt=1 désactive entièrement le snippet, et aucune empreinte n’est jamais calculée pour les visiteurs qui se sont opposés au suivi.
Une empreinte d’appareil stable (seul son hachage SHA-256 quitte le navigateur) retrouve l’identifiant visiteur précédent : l’historique survit à la perte des cookies et aux visites en navigation privée. Et aucun chemin d’ingestion ne modifie jamais la clé d’un contact identifié : une deuxième personne sur un appareil partagé ne peut pas hériter de l’historique de la première.
Inscrivez-vous, connectez un CRM ou ajoutez le snippet d’événements, puis pointez votre client MCP sur mcp.pathbound.ai/mcp.