Consent management

overview the chord cdp enforces user consent before forwarding events to destinations when a destination has consent requirements configured, no event is sent to that destination — and no destination script is loaded in the browser — until the user has granted the required consent categories this document explains how consent categories are defined, how the cdp receives consent decisions from the browser, and how those decisions gate event delivery in both device mode and cloud mode the consent lifecycle in brief what happens, in order, on a visit to a storefront with a cmp configured before the cmp publishes a consent state, events are held in a browser queue and nothing reaches chord this covers the time the cmp script takes to load — not the time the visitor spends reading the banner once the cmp publishes a state, the queue flushes that first state is the jurisdiction default the cmp is configured with typically permissive under an opt out model (common in the us) and denied except strictly necessary under an opt in model (common in the uk and eu) from that point on, every event is sent to chord — whether consent was granted or denied a denial is recorded on the event; it does not stop collection enforcement happens per destination, not in the browser's decision to send consent is read fresh and stamped immediately before each send , including when a queued event is replayed a queued event can therefore carry the visitor's actual choice rather than the default it was queued under when the visitor changes their choice, the new preferences apply to every later event , and chord pixel fires a consent preferences updated event that event bypasses consent requirements and reaches every destination, so a destination can act on a revocation chord decides delivery per destination a destination receives an event only if every category in its consent requirements is true a destination with an empty requirements list receives everything nothing is retroactive events already delivered under a permissive default stay delivered all of the above requires the consent option to be set when chord pixel is initialized without it there is no queue and no consent stamp — events are collected and forwarded with no consent data at all what a full denial does — and doesn't — stop if a visitor declines every category in the cmp banner, the browser still sends every event to chord collection does not stop each event carries categorypreferences with every category set to false , and chord records it like any other event what stops is delivery a destination with one or more consent requirements receives nothing in device mode, its third party script is never loaded a destination with an empty consent requirements list still receives every event a full denial does not gate it — configuring the requirements list is what makes consent enforceable for that destination consent preferences updated still reaches every destination, so a platform can act on the revocation if you need collection itself to stop, your storefront has to stop calling chord pixel no setting in the console turns a denial into non collection consent categories consent categories are the units of permission that users grant or deny before configuring consent requirements on a destination, you must define your categories in the chord console under cdp → consent categories each category has name — human readable label shown in the console external id — the category identifier used by your consent management platform (cmp) must match exactly what your cmp emits description — optional explanation of what data collection this category covers active — whether this category is currently enforced the external id is the field that connects cdp categories to your cmp for example, onetrust uses category codes like c0002 for analytics cookies — the external id for your analytics category must be set to c0002 for the mapping to work consent management platform (cmp) integration chord pixel bridges your cmp and the cdp it reads the user's current consent state from the cmp, stamps each outgoing event with the user's category preferences, and updates those stamps dynamically as consent changes support cmps onetrust — detected via window\ onetrust ; categories read from window\ onetrustactivegroups cookiebot — detected via window\ cookiebot ketch — detected via window\ ketch and window\ ketchconsent shopify — detected via window\ shopify customerprivacy segment — detected via window\ segmentconsent the cmp integration is configured when you initialize chord pixel const chord = new chordanalytics({ consent 'onetrust', // 'cookiebot' | 'ketch' | 'onetrust' | 'shopify' | 'segment' awaitconsent true, cdpdomain process env chord domain, cdpwritekey process env chord write key, // rest of your configuration }) if the consent option is not set, chord pixel does not read your cmp at all events are still collected and forwarded, but they carry no consent information — see events with no consent data below consent readiness and event queueing when a cmp is configured, chord pixel checks whether that cmp has published a consent state before sending each event if it has not, the event is held in a queue rather than being dropped chord pixel polls every 100 ms and flushes the queue as soon as the state is available this queue covers the short window while the cmp script is still loading — not the period before the visitor answers the banner most cmps publish a default state as soon as they load, so events typically resume immediately, stamped with those defaults rather than with the visitor's eventual choice onetrust, for example, is considered ready once window\ onetrustactivegroups is populated, which happens before any banner interaction the queue is held in memory and is not capped it is also mirrored to sessionstorage so it survives navigation within the session; that mirror keeps only the most recent 50 events and is skipped entirely if it would exceed 100 kb there is no time based expiry — queued events are delivered whenever the cmp state becomes available setting awaitconsent true additionally defers consent setup until the cmp itself has loaded chord pixel polls every 50 ms and gives up after 60 seconds; override that with awaitconsenttimeout (in milliseconds) if the cmp never loads within that window, consent setup is abandoned and subsequent events are sent without a consent stamp consent stamping on every event, chord pixel fetches the user's current category preferences directly from the cmp (no caching) the result is added to the event under context consent categorypreferences { "context" { "consent" { "categorypreferences" { "c0001" true, "c0002" true, "c0003" false } } } } the keys in categorypreferences are the external ids of your consent categories values are true (granted) or false (denied) note that denying consent does not stop chord pixel from sending the event the event is still collected, stamped with the denial, and forwarded to the cdp, where consent requirements decide which destinations receive it this preserves a record of the decision and lets enforcement stay configurable configuring consent requirements on a destination open the destination's configuration in the chord console and add one or more consent categories to the consent requirements list each required category must resolve to true in the event's categorypreferences for the event to be forwarded a destination with an empty consent requirements list receives every event that passes host and event filters, whatever the user's consent preferences say stamping consent on an event does nothing by itself — the categories have to be configured here as well requiring all consent categories consent requirements use and logic if you specify two categories, both must be granted there is no or operator — if you want a destination to fire when any one of several categories is granted, create separate destination configurations events with no consent data the send null consent events option by default, if an event arrives with no categorypreferences at all, the destination treats consent as implicitly granted and forwards the event this preserves backward compatibility for destinations that predate consent configuration events arrive with no consent data in two common situations a storefront that has no cmp configured in chord pixel server to server sources such as shopify webhooks consent apis are browser apis, so a webhook carries no consent signal to block those events, disable send null consent events on the destination configuration with this option disabled, any event that lacks categorypreferences is dropped, regardless of what consent requirements are set no categorypreferences , option enabled (the default) — event forwarded no categorypreferences , option disabled — event dropped categorypreferences present — consent requirements are evaluated, and this option is not consulted the option is a property of the destination, so it applies to every source connected to that destination it cannot be scoped to one source if you need to block server side events while continuing to accept browser events that carry no consent data, configure a separate destination for the server side traffic how consent gates event delivery device mode device mode destinations run as browser plugins — the destination's third party script (e g , a pixel or sdk) loads in the visitor's browser, and events are sent directly from the browser to the destination's servers before any device mode plugin processes an event, the cdp sdk calls applyfilters() , which checks host and event type filters (unrelated to consent) if the destination has consentrequirements , evaluates them against the event's categorypreferences returns false if any required category is not granted when applyfilters() returns false , the plugin's handler is never invoked the event is silently dropped for that destination third party scripts are loaded lazily a device mode destination's script is only loaded after the first event passes all filters, including consent if the user never grants the required consent, the destination script is never injected into the page cloud mode cloud mode destinations receive events server side via the chord cdp pipeline the same consent logic runs in the pipeline before the event is dispatched to the destination function events that do not satisfy the consent requirements are dropped before the destination function executes the consent preferences updated event when a user changes their consent choices, chord pixel fires a consent preferences updated event this event always bypasses consent requirements and is forwarded to all destinations regardless of current category preferences this allows destinations to register the updated preferences — for example, to update suppression lists or unsubscribe records in a marketing platform — even when the user has revoked consent for that destination's category example sfmc collect js salesforce marketing cloud collect js is a device mode destination if it is configured with a consent requirement of c0002 (analytics cookies) a visitor arrives and has not yet interacted with the consent banner — no categorypreferences in events if send null consent events is enabled (the default), events flow to sfmc if it is disabled, events are held until consent is given the visitor dismisses the banner and denies analytics cookies — categorypreferences { "c0002" false } all subsequent events for sfmc are dropped the collect js script is not loaded if it hasn't been already the visitor accepts analytics cookies — categorypreferences { "c0002" true } events resume flowing to sfmc if the collect js script was never loaded, it is loaded now on the next passing event the visitor later revokes consent a consent preferences updated event is fired and delivered to sfmc regardless of the new consent state all subsequent track and page events are again blocked troubleshooting events are not reaching a destination even though consent was granted check that the external ids configured on your consent categories in the chord console exactly match the category codes your cmp emits a mismatch (e g , c0002 vs c0002 ) causes every event to fail the consent check events are flowing to a destination even though the user denied consent verify that the destination has consent requirements configured a destination with no consent requirements set will receive all events that pass host and event filters, regardless of the user's consent preferences events arrive with no consent object at all confirm that the consent option is set when chord pixel is initialized without it, chord pixel never reads your cmp, and every event is treated as having no consent data the destination script loads before consent is given this indicates that at least one event is passing the consent filter before consent is granted — most likely because categorypreferences is absent and send null consent events is enabled disable that option on the destination if you require explicit opt in before the script loads updated 22 september 2026