Sessions

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 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 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 " if you have any questions or need help, please reach out to us at help\@chord co mailto\ help\@chord co