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 docid\ kcbqxl1zcpjdhr9i2lijw ) 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