Documentation
Events & identity
How sessions, user hash, and conversion events stitch into journeys.
Attribution is only as good as the journey you can stitch. Intently keys journeys on session id and, when enabled, a user hash.
Sessions
The SDK maintains a first-party session. Server routes under /api/v1/track receive that session with each event. Touchpoints and conversions are stored against sessionId.
Same-session stitching always works when the snippet is installed. Cross-session stitching (returning visitors, paid click → later purchase) requires user hash tracking.
User hash
Enable user tracking under Settings → Tracking so the SDK can attach a stable userHash when your hash mode allows it.
When a conversion later includes that hash, Intently walks touchpoints for:
- the same
userHash, or - the converting
sessionId(so anonymous early touches on the paid landing are not dropped when the hash appears mid-session)
Default attribution lookback is 90 days (configurable 7–365 in Settings → Attribution).
Conversion events
These event names create an attributed conversion (when the feature is enabled):
| Event name | Typical use |
|---|---|
purchase | Order completed |
lead / generate_lead | Lead captured |
form_submit | Form completed |
sign_up / signup | Account created |
complete_registration | Registration finished |
subscribe | Subscription started |
Revenue on the conversion (when present in event properties) is stored in cents and used in channel reports. Stripe payments create conversions with source: stripe — see Stripe revenue.
What is not a conversion by itself
Page views, clicks, and engagement pings create touchpoints when UTM or click IDs are present, but they do not credit revenue until a conversion event (or Stripe payment) fires.
Consent
If server-side consent blocks storage for the visitor, touchpoints and conversions are not written. Destination dispatch may also be gated. See Consent.