A session at Chord is a continuous window of activity by a single visitor on your storefront. Sessions are the atomic unit we use for analytics like traffic, attribution, conversion rate, and bounce rate. One row per session is exposed through the analytics layer, ready to be joined to orders, users, landing pages, and marketing channels.

This page describes how Chord defines, builds, and enriches sessions.

A session captures everything one visitor did in one sitting on a single storefront. It begins with their first event, continues as long as they stay active, and closes after they go quiet. Every page view, product view, add-to-cart, checkout step, and order placed during that window is rolled up under a single Session ID.

A session is always scoped to a single OMS and store, a visitor browsing two of your storefronts at the same time produces two distinct sessions, one per store.

Chord uses a 30-minute inactivity timeout.

There is no fixed maximum session length. A visitor who keeps interacting can stay in the same session for hours. There is also no calendar-day cutoff: a session that begins at 11:50 PM and continues at 12:05 AM is one session, not two.

The session's Start Time is the timestamp of its first event; the End Time is the timestamp of its last event; the Duration is the difference. A session with only one event has a duration of zero.

Every event arriving from your storefront carries an anonymous ID (a browser/device cookie) and, once the visitor logs in or places an order, a user ID from your OMS.

Chord builds a single, stable identity per visitor (internally called the blended user ID) using the following rule:

The practical effect: when someone browses anonymously for a week, then signs up, all of their earlier sessions are retroactively re-attributed to the same person. They show up as a single user in the user dimension, with their full session history attached.

Cross-subdomain stitching is automatic. The Chord CDP SDK persists the anonymous ID across subdomains, so a visitor who browses on shop.example.com and checks out on checkout.example.com is treated as a single visitor across both. No special reconciliation is required.

Every session row carries:

Identity & scope

Timing

Landing & device

Marketing attribution: derived from the landing page of the session

Conversion milestones

For each session, Chord exposes a flag for whether the visitor reached each step of the funnel:

Alongside these flags, the session also carries:

Customer state at the time of the session

An order is attached to a session when a corresponding Order Completed or Checkout Completed event lands inside that session's window. The order then contributes its revenue, basket, discount codes, and tags to the session's totals.

A session can contain more than one order; revenue fields are summed across them. Conversely, an order can only attach to one session (the one in which the completion event fired).

For multi-touch attribution, Chord computes four standard models per session toward the visitor's next conversion:

These points are exposed at the session grain and are also rolled up to orders.

Bot and synthetic traffic. Sessions are built only from real visitor activity. Before any session is constructed, Chord filters out events that look automated — that is, events whose browser user agent matches a known bot or automation tool. The filter is grouped into four categories:

In addition, one known synthetic ad-feed combination of UTM parameters (utm_campaign=sag_organic + utm_source=google + utm_medium=product_sync) is stripped, since it is generated by automated product syncing rather than by a real shopper.

Filtered events never produce sessions and never inflate visit, conversion, or attribution counts.

Server-side events. Sessionization runs on client-side events only, events that actually represent something a real visitor did in a browser. Server-side events are kept elsewhere in the warehouse but are not eligible to start, extend, or end a session.

A session is marked bounced when all of the following hold:

If any one of those conditions fails, the session is non-bounced.