--- title: Sessions slug: ykTU-sessions docTags: createdAt: 2024-06-25T15:14:02.986Z --- # Sessions 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. ## What a session represents 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. ## How a session begins and ends Chord uses a **30-minute inactivity timeout**. - A new session starts on a visitor's very first event. - The session continues as long as the gap between two consecutive events is **30 minutes or less**. - A new session begins the moment a gap **exceeds 30 minutes**. 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.** :::BlockQuote **Example:** A visitor lands on your homepage at 10:00, views a product at 10:08, adds to cart at 10:15, walks away, and returns to view another product at 10:40. The 10:40 view is **25 minutes** after the previous event, so it stays in the same session. If they had instead returned at 10:46 (**31 minutes later)** that view would start a brand-new session. ::: 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. ## How visitors are stitched across sessions 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: - If we have **ever** seen a user ID associated with this anonymous ID, that user ID becomes the visitor's identity for **every session**, including sessions that happened before they logged in. - If we have never seen a user ID, the anonymous ID itself is the identity. 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. ## What is attached at the session level Every session row carries: **Identity & scope** - **Session ID**: a unique identifier for this session - **Blended User ID**: the stitched visitor identity (see *How visitors are stitched* above) - **Anonymous ID**: the visitor's browser/device cookie - **OMS**, **Store**: the storefront the session belongs to - **Session Number**: the visitor's 1st, 2nd, 3rd… session - **Visitor Type:** New Visitor if it is the visitor's first session, otherwise Returning Visitor **Timing** - **Start Time**, **End Time**, **Duration in Seconds** - **Duration Tier:** a bucketed view of the session length: 0–9s, 10–29s, 30–59s, or 60s+ - **Activity Count:** the number of page views plus tracked events in the session - **Days Since Last Session**: how long it has been since this visitor's previous session ended **Landing & device** - **Landing Page:** the **first page view** of the session (or, if the session has only non-page events, the first event) - **Last Seen Page**: the **most recent page view** in the session - **Device** and **Device Category** (desktop / mobile / tablet), inferred from the user agent **Marketing attribution**: derived from the **landing page** of the session - UTM source, medium, campaign, term, content - Google / Meta / Microsoft click IDs - Page referrer - Channel and sub-channel mapped from the UTM/referrer combination through Chord's marketing channel mapping (e.g., Paid Search, Paid Social, Email, SMS, Affiliate, Direct, Other). [See more on channel definition.](https://docs.chord.co/attribution-channel-mapping) - A paid-vs-organic flag derived from the channel - *(Optional)* a Post-purchase survey override: when the UTM-derived channel is Direct or Unknown and the visitor answered a post-purchase survey on the resulting order, Chord uses the survey answer as the channel. **Conversion milestones** For each session, Chord exposes a flag for whether the visitor reached each step of the funnel: - **Has Product Viewed**: the visitor opened at least one product detail page - **Has Product Added:** at least one product was added to the cart - **Has Cart Viewed**: the visitor opened the cart - **Has Checkout Started**: the visitor entered the checkout flow - **Has Checkout Completed**: the visitor finished the checkout flow - **Has Order Completion:** at least one order was placed during the session Alongside these flags, the session also carries: - **Completed Order IDs / Numbers**: the orders that were placed during the session - **Order Revenue Totals**: gross, net, tax, fulfillment, and refunds, summed across all orders completed in the session **Customer state at the time of the session** - **Customer Type**: Prospective customer (no prior orders), New customer (first order is in or before this session), or Repeat customer (had a prior order before this session) - **Is Bounced Session**: see *Bounce definition* below ## How orders attach to sessions 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](https://docs.chord.co/rxEl-marketing-attribution), Chord computes four standard models per session toward the visitor's next conversion: - **First touch:** full credit to the visitor's first session - **Last touch:** full credit to the converting session - **Linear:** equal credit across all sessions up to and including the conversion - **40 / 20 / 40**: 40% first session, 40% converting session, the remaining 20% spread evenly across the middle These points are exposed at the session grain and are also rolled up to orders. ## What is excluded from sessions **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: - **Search-engine and social crawlers:** e.g. Googlebot variants, Baidu, ByteDance, Yahoo Slurp, Facebook's link-preview crawler, Meta's external agent. - **SEO and analytics crawlers**: e.g. Screaming Frog, HubSpot Crawler, SEOMonitor. - **Uptime and synthetic-monitoring tools**: e.g. Datadog Synthetics, Shopify's checkout-observation probes. - **Generic automation patterns and headless browsers**: any user agent containing bot, crawler, or spider, plus headless tools like Headless Chrome, PhantomJS, Selenium, Puppeteer, and Playwright. 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. :::BlockQuote This filter relies on the browser's self-reported user agent. Sophisticated automation that deliberately impersonates a real browser will not be caught at this layer. ::: **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. ### Bounce definition A session is marked **bounced** when **all** of the following hold: - The session has only one page view - Only one distinct page (URL + query) was visited - The visitor did not start checkout and did not place an order - The duration was under 2 seconds If any one of those conditions fails, the session is non-bounced. ## Edge cases and caveats - **Late-arriving events.** When a delayed event lands for a visitor, Chord re-evaluates that visitor's full activity history so the session boundaries remain correct. This means historical session counts can shift slightly between runs as late events arrive. - **Identity discovered later.** As described above, a visitor's earlier anonymous sessions are retroactively re-attributed to their user ID once they identify. Counts of "anonymous sessions" can therefore decrease over time as visitors sign in or check out. - **Multi-storefront visitors.** A visitor browsing two of your stores simultaneously produces two distinct sessions — one per store — even if they share an anonymous ID. - **Cross-device.** Not modeled. Sessions on different devices are independent unless the same identifier is asserted on both. - **Bot filtering is user-agent based.** Sophisticated automation that spoofs a real user agent will not be caught by these filters. - **Empty sessions.** A session must have at least one client-side event by construction. There is no concept of a "page view that didn't fire." :::hint{type="success"} if you have any questions or need help, please reach out to us at [help@chord.co](mailto\:help@chord.co) :::