Cookies
Overview
Chord CDP uses browser cookies for two separate purposes:
- Cookies Chord writes: First-party cookies on your own domain that keep a visitor's identity and attribution stable across pages, sessions, and devices.
- 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_<provider>, 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_<MEASUREMENT_ID> | 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_<provider> | 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). 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 |