> 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/activate/event-streaming/consent.md). # Consent Consent controls which destinations receive each event. Chord records every event, stamps it with the visitor's consent choices, and then sends it only to destinations whose consent requirements the visitor has met. To set up consent on your storefront, follow the setup page for your platform: * [Shopify: Consent](/collect-data/shopify/browser-events/consent.md) * [Everyone else: Consent](/collect-data/everyone-else/browser-events/consent.md) This page covers how consent decides delivery. ## How consent decides delivery Consent gates delivery, not collection. Events still reach Chord when a visitor declines. Each one carries the visitor's choice for every consent category. For each destination, Chord checks the event's consent against the destination's **Consent Requirements**: * A destination receives an event only if the visitor granted **every** category in its requirements. There is no "any of" option. To send when any one category is granted, add the destination twice. * A destination with no requirements receives every event, even from visitors who declined everything. * Nothing is retroactive. Events already sent stay sent. {% hint style="warning" %} Always add at least one consent category to each destination. A browser destination with no requirements still loads its script and fires for visitors who declined everything. {% endhint %} ## Consent categories A consent category is one kind of permission, such as analytics or marketing. You create the categories once, then add them to destinations as requirements. Admin and Developer users can create, edit and delete categories. Member and Data Analyst users can view them. Order Admin users can't see them. To create a category: 1. In Chord, go to **CDP** and open the **Consent Categories** tab. 2. Click **Create Your First Consent Category**, or **+ New Category** if you already have some. 3. Enter a name and click the check mark to save it. 4. Enter the **External ID**. It must match exactly the category ID your consent management platform (CMP) reports, for example `C0002` for OneTrust analytics cookies. A mismatch such as `c0002` blocks every event. 5. Optionally add a description, then click **Save**. ![The Consent Categories tab before you add a category](https://2938842758-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5Oy2IAsu7IvAGAlWgC36%2Fuploads%2Fgit-blob-5989c3e4eb2c181c6ca1c75c9404b29aca8dfc77%2Fconsent-categories-empty.png?alt=media) ![The form for a new consent category](https://2938842758-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5Oy2IAsu7IvAGAlWgC36%2Fuploads%2Fgit-blob-8c4ff1f1cbb8fa6bfb0d5375203ea57418716f87%2Fconsent-category-form.png?alt=media) To edit or delete a category, use the pencil or trash icon next to it on the **Consent Categories** tab. ## Add requirements to a destination 1. On the **Overview** tab, open the destination and click **Edit**. 2. Scroll to **Consent Requirements**. 3. Choose the categories this destination needs. 4. Click **Save Changes**. ## What a full denial stops If a visitor declines every category: * Destinations with requirements receive nothing. For a browser destination, the vendor's script never loads. * Destinations with no requirements still receive everything. * Chord still collects and records the events. To stop collection itself, your storefront has to stop sending events to Chord. ## Events with no consent information Some events carry no consent information at all. This happens when your storefront doesn't have a CMP set up, and for backend events such as Shopify webhooks. Chord treats these events as consented and sends them on, even to destinations with consent requirements. This keeps transactional events, such as Order Completed, flowing to every destination. ## The Consent Preferences Updated event When a visitor changes their choices, Chord fires a `Consent Preferences Updated` event. Server destinations receive it whatever the visitor's consent, so a platform can record an opt-out. Browser destinations never receive it, so a declined visitor never loads a pixel. Some server destinations pass events they don't recognize on to the vendor as custom events. Meta Conversions API is one. It forwards this event to Meta. [Braze browser](/activate/event-streaming/destinations/email-and-marketing/braze/braze-browser.md), listed in Chord as **Braze (Device Mode)**, has a setting called **Eager SDK Initialization**. When it is on, Chord loads Braze before any consent check, so Braze loads even for visitors who declined everything. Leave it off if consent must gate Braze. ## Troubleshooting **A destination gets no events, though the visitor consented.** Check that each category's External ID matches the ID your CMP reports, including capitalization. **A destination gets events from visitors who declined.** Check that the destination has consent requirements. Live Events still shows denied events, because they reach Chord. Look at what the destination received, not at Live Events. **Events have no consent information.** Check that consent is set up on your storefront. See the setup pages above. **A browser destination loads before consent.** The destination probably has no requirements. Events with no consent information can also cause it. Braze browser can too, if you turned on **Eager SDK Initialization**. --- # 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/activate/event-streaming/consent.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.