The snippet
Your website
One script tag autocaptures page views, clicks, form submits, and video, and one identify call at login ties them to the person. No event taxonomy to design, no per-page instrumentation.
Install the snippet →The pricing pages they read, the demo they half-watched, the docs that brought them in—it all happened on your site before the form was filled. Events captures it with one snippet and attaches it to the contact the moment they identify, on the same profile your agents read over MCP and REST.
Signups come in faster than anyone can research them, and the answer to “why is this person here” is usually sitting in a web analytics tool: three pricing visits and a half-watched demo, keyed to an anonymous cookie ID that nothing joins to the CRM. So the signup that arrived warm gets worked cold, and the research the founder used to do by hand doesn’t happen at all.
The pricing-page visits, the half-watched demo, the blog posts that brought them in. All of it stitched onto the contact the moment they sign up—so your agent can answer “why is Jane here, and how warm is she?” with real evidence.
Eleven anonymous events from visitor_a91c now belong to Jane: the pricing returns, the 75% demo watch, the case study, back to the blog post that brought her in 14 days ago.
{ "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" }
}A one-time DNS TXT record proves you own the domain—events are accepted from nowhere else. Then one script tag on every page you want covered.
Page views, page leaves, first visits, button and link clicks, form submits, and video events—named and enriched server-side with browser, OS, device, and referrer. Nothing to instrument.
One call links the browser to your user ID and backfills everything they did before—so the anonymous trail becomes part of the contact.
Verify your domain once with a DNS TXT record—events are accepted only from domains you own. Then one line before </body>: a 5 KB gzipped script, tracker.js.
<script async src="https://tracker.pathbound.ai/tracker.js"></script>One call binds the browser to your user ID—everything they did before, back to the first page view, attaches to the contact retroactively. A server-side POST /v1/identify and a plain cookie work too.
// 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 }]);DNT honored · HTTPS-only · no third-party cookies · verified domains only · per-domain rate limits · fingerprint is content-stable, not cross-site identifying.
Events is one store with more than one way in. Every source resolves to the same contacts and lands on the same timeline.
One script tag autocaptures page views, clicks, form submits, and video, and one identify call at login ties them to the person. No event taxonomy to design, no per-page instrumentation.
Install the snippet →Already instrumented in PostHog? The integration pull-syncs those events into the same store, resolved to the same contacts. Keep PostHog for product analytics; your agents read one timeline.
The PostHog integration →Analytics tools count sessions. Events resolves people—so fourteen days of anonymous browsing and a logged-in user are one record, not two.
A visitor cookie and session ID track the browser. When cookies are cleared, a content-stable device fingerprint recovers the prior visitor ID, so the trail survives instead of splitting.
window.pathbound.identify() from the page, an authenticated POST /v1/identify from your backend, or a cookie your app sets. All three share one join key, so combining them is safe.
Backfill moves events instead of copying them. First-touch referrer and UTMs are written once and never overwritten. No ingestion path ever re-keys an identified contact.
The full mechanics—cookies, fingerprinting, the identification cascade—are documented in Identity & fingerprinting.
There’s no batch window. An event is on the profile as it happens, so an agent on a live support thread sees this morning’s pricing-page visit—not yesterday’s export. The same store answers REST queries and the MCP tools.
curl "https://api.pathbound.ai/v1/events?event_types=page_view&url_contains=/pricing&identified_only=true" \
-H "Authorization: Bearer YOUR_API_KEY"Full filters and schemas in the Events API reference; for agents, the same data is served by the customer data MCP.
Page views (including SPA route changes), page leaves with time on page, first visits, button and link clicks, form submits, and Wistia video events—plays, pauses, completions, 25/50/75/100% milestones, and in-video email capture. All of it without configuration; the identify call is the only code you write.
They’re recorded under an anonymous visitor ID. When the person identifies (signup form, login, or a server-side identify), their whole trail attaches to the contact retroactively. Events are moved, not duplicated, and the first-touch referrer, landing page, and UTMs are written to the contact once, never overwritten by later visits.
No. Autocapture names events for you (page_view, button_click, form_submit) with the element text, URL, and referrer already attached. You add one identify call at login; everything else is automatic.
No, and you can run both. The PostHog integration pull-syncs your PostHog events into the same store, attached to the same contacts. Keep PostHog for product analytics; Events is how that behavior reaches the customer profile your agents read.
First-party only: no third-party cookies, HTTPS-only, and events are accepted only from domains you’ve verified with a DNS TXT record—nobody else can send events as you. A pathbound_dnt=1 cookie disables the snippet entirely, and opted-out visitors are never fingerprinted.
A content-stable device fingerprint (only the SHA-256 hash ever leaves the browser) recovers the prior visitor ID, so the history survives cookie loss and incognito visits. And no ingestion path ever re-keys an identified contact—a second person on a shared device can’t inherit the first one’s history.
Sign up, connect one CRM or drop the events snippet, and point your MCP client at mcp.pathbound.ai/mcp.