> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/reference/cookies.md). # Cookies ## Overview Chord CDP uses browser cookies for two separate purposes: 1. **Cookies Chord writes:** First-party cookies on your own domain that keep a visitor's identity and attribution stable across pages, sessions, and devices. 2. **Cookies Chord reads:** Cookies set by advertising and analytics platforms (Meta, Google, TikTok, Pinterest, and others). **Chord never creates or modifies these**; it copies their values onto the event so server-side destinations can attribute conversions as accurately as the platform's own pixel would. Everything Chord writes is a **first-party** cookie scoped to the top level of your storefront domain. Chord sets no third-party cookies. This document is the complete inventory, intended for privacy policy disclosures, cookie banner configuration, and consent category mapping. ## Cookies Chord writes ### Identity cookies These five cookies carry the visitor's identity. They are created on the first page view (anonymous ID) and on the first `identify` / `group` call (the rest). | **Cookie** | **Contents** | **Purpose** | **Lifetime** | | ----------------- | --------------------- | ------------------------------------------------------------------------------------ | ------------ | | `__eventn_id` | UUID | Anonymous ID. Ties all events from this browser together before and after login. | 5 years | | `__eventn_uid` | Your user identifier | Known user ID, set once the visitor is identified. | 5 years | | `__eventn_id_usr` | URL-encoded JSON | User traits captured at identify time (email, name, and any custom traits you send). | 5 years | | `__group_id` | Your group identifier | Group / account ID for B2B or multi-account storefronts. | 5 years | | `__group_traits` | URL-encoded JSON | Traits of the current group. | 5 years | All five share the same attributes: | **Attribute** | **Value** | | ------------- | ----------------------------------------------------------------------------------------------------------------------- | | **Domain** | Top level of the current domain — a pixel on `shop.example.com` writes to `.example.com`. Override with `cookieDomain`. | | **Path** | `/` | | **SameSite** | `None; Secure` on HTTPS, `Lax` on HTTP | | **HttpOnly** | No — the pixel must read these from JavaScript | | **Expiry** | 5 years, refreshed on every write | The cookie names are defaults. Any of them can be renamed with the `cookieNames` option, for example if your CMP or CDN requires a specific naming convention. ### Attribution cookies Chord persists click and campaign parameters from the landing URL so that a conversion later in the session is still credited to the campaign that drove it. Each provider gets one cookie named `__url_param_`, holding the captured value plus the timestamp it was captured. | **Cookie** | **Captured from** | **Surfaced on the event as** | **Default lifetime** | | -------------------------- | ----------------- | ---------------------------- | ------------------------------------ | | `__url_param_impact` | `im_ref` | `context.clientIds.impact` | 30 days, cleared on order completion | | `__url_param_utm_source` | `utm_source` | `context.campaign.source` | 30 days | | `__url_param_utm_medium` | `utm_medium` | `context.campaign.medium` | 30 days | | `__url_param_utm_campaign` | `utm_campaign` | `context.campaign.name` | 30 days | | `__url_param_utm_content` | `utm_content` | `context.campaign.content` | 30 days | | `__url_param_utm_term` | `utm_term` | `context.campaign.term` | 30 days | Behavior worth knowing: * Parameters are captured on **page events only**, so a single-page app must fire a page event on route changes for capture to happen. * The **first value wins** per provider for the lifetime of the cookie. A later visit with a different `utm_source` does not overwrite the stored one until it expires. * UTM values still present in the current URL always take precedence over the stored ones on that event. * `im_ref` is cleared after `Order Completed` (and the equivalent `order complete` / `purchase` names) so the next order is not credited to the same click. Additional parameters, such as Rakuten's `ranMID`, CJ's `cjevent`, or anything else you need, can be added with the `urlParamCapture` option, with a per-provider expiry, clear-on-event list, and optional URL pattern restriction. ### Session cookie | **Cookie** | **Contents** | **Purpose** | **Lifetime** | | -------------- | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | | `_amp_session` | Unix timestamp in ms | Amplitude session ID. Written by Chord so that server-side and browser-side Amplitude events share one session, even before Amplitude's own SDK finishes loading. | 30 minutes, sliding — refreshed on each event | This cookie is `SameSite=Lax` and scoped to the top level of your domain. Note that the pixel writes it on initialization regardless of whether an Amplitude destination is configured, so include it in your cookie declaration even if you do not use Amplitude today. Only Amplitude destinations consume its value. ## Cookies Chord reads Chord copies these values onto every event under `context.clientIds`, where server-side destinations use them for conversion attribution. Chord does not set, refresh, or delete them. They exist only if the corresponding platform's own script has already set them. | **Cookie** | **Set by** | **Surfaced on the event as** | | ---------------------- | -------------------------- | -------------------------------------------------------------------------------------- | | `_fbc` | Meta Pixel | `context.clientIds.fbc` | | `_fbp` | Meta Pixel | `context.clientIds.fbp` | | `_gcl_aw` | Google Ads | `context.clientIds.gcl_aw` | | `_ga` | Google Analytics 4 | `context.clientIds.ga4.clientId` | | `_ga_` | Google Analytics 4 | `context.clientIds.ga4.sessionIds` (keyed by measurement ID) | | `_ttp` | TikTok Pixel | `context.clientIds.ttp` | | `ttclid` | TikTok click ID | `context.clientIds.ttclid` | | `_epik` | Pinterest Tag | `context.clientIds.epik` | | `_amp_session` | Chord or the Amplitude SDK | `context.clientIds.amplitudeSessionId` | | `sms_click_id` | ShopMy | Used by the ShopMy destination for order attribution; not added to `context.clientIds` | To capture a cookie that is not on this list, add it with the `cookieCapture` option: a map of the field name you want on the event to the cookie name to read. ### Values read from live SDKs rather than cookies A few identifiers are read directly from a platform's in-page SDK, not from a cookie, because the SDK's own value is authoritative and available earlier than its cookie. These appear alongside the cookie-derived values in `context.clientIds`: | **Field** | **Source** | | ----------------------------------------- | ----------------------------------------------------------------- | | `amplitudeSessionId`, `amplitudeDeviceId` | Amplitude SDK, when loaded — takes precedence over `_amp_session` | | `posthog.sessionId`, `posthog.distinctId` | PostHog SDK, when loaded | ## Local storage Cookies alone are not durable enough for identity. Safari's Intelligent Tracking Prevention caps script-written cookies at 7 days, and browser cookie clearing is common. Chord therefore keeps a backup copy of identity state in `localStorage` and restores the cookie from it whenever the cookie is missing. | **Key** | **Mirrors** | | ------------------------------ | ---------------------------------------------------------------------------- | | `jitsu___eventn_id` | `__eventn_id` | | `jitsu___eventn_uid` | `__eventn_uid` | | `jitsu___eventn_id_usr` | `__eventn_id_usr` | | `jitsu___group_id` | `__group_id` | | `jitsu___group_traits` | `__group_traits` | | `jitsu___url_param_` | The matching attribution cookie | | `_cdp_debug` | Not identity data; a flag that turns on verbose pixel logging in the console | Only identity and attribution keys are mirrored. If `localStorage` is unavailable (private browsing, storage quota exhausted, or blocked by browser settings) Chord falls back to cookies alone without erroring. ### Server-set cookies for Safari Cookies set by a server response are not subject to the same ITP 7-day cap as cookies written by JavaScript. If you configure the `idEndpoint` option to point at a Chord identity endpoint on your own domain, Chord additionally sets: | **Cookie** | **Purpose** | **Lifetime** | | ------------------- | -------------------------------------------- | ------------ | | `__eventn_id_srvr` | HttpOnly server-set copy of the anonymous ID | 5 years | | `__eventn_uid_srvr` | HttpOnly server-set copy of the user ID | 5 years | These are written by an HTTP response, are `HttpOnly` (unreadable from JavaScript), and are used to restore the browser-side cookie if it has been evicted. The endpoint must be served from the same domain as your storefront for this to work. ## Consent and privacy controls ### What consent categories gate Consent categories gate **event delivery to destinations** and **device-mode script loading** (see [Consent Management](/collect-data/everyone-else/browser-events/consent.md)). They do not by themselves stop Chord from writing its own first-party identity cookies. To suppress identity collection itself, use the privacy options below. ### Privacy options | **Option** | **Effect on cookies** | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `privacy.disableUserIds` | No third-party cookies are read (`context.clientIds` is omitted), `identify` and `group` become no-ops so no user or group cookies are written, `_amp_session` is not created, and `userId` / `anonymousId` are stripped from every payload. | | `privacy.dontSend` | No events are sent at all. | | `privacy.ipPolicy` | Controls IP handling, not cookies. | Turning `disableUserIds` back off (for example after a visitor accepts your banner) generates a **new** anonymous ID rather than resurrecting the previous one, so the pre-consent and post-consent sessions are deliberately not linked. ### Clearing cookies Calling `reset()` on the pixel deletes all five identity cookies and their `localStorage` mirrors, and issues a fresh anonymous ID. This is the right call to make on logout. ### Declaring Chord cookies in your cookie banner For CMP configuration, Chord's cookies group as follows. Confirm the final classification with your own privacy counsel. | **Cookies** | **Typical category** | | ------------------------------------------------------------------------------------------------ | ----------------------------------------------------------- | | `__eventn_id`, `__eventn_uid`, `__eventn_id_usr`, `__group_id`, `__group_traits`, `_amp_session` | Analytics / performance | | `__url_param_*` | Marketing / advertising | | Third-party cookies Chord reads | Declared under the platform that sets them, not under Chord | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.chord.co/reference/cookies.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.