> 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/browser-and-server-destinations.md). # Browser and server destinations Chord can send events to a destination in two ways. Which one a destination uses is called its mode. Many ad platforms offer both, as two separate destinations. ## Browser destinations A browser destination, also called device mode, runs the vendor's own script in your shopper's browser. The browser sends events straight to the vendor. * It sees what happens on the page, such as clicks and the vendor's own cookies. * It can only run when the shopper has the page open. * Ad blockers and privacy settings can stop it. * Chord loads the vendor's script only after an event passes your [consent](/activate/event-streaming/consent.md) settings. * You can limit which events it receives with an **Events Allowlist** on the connection. * [Functions](/activate/event-streaming/functions.md) and [Notifications](/activate/event-streaming/notifications.md) don't cover it, because its events don't pass through Chord's servers after the browser. ## Server destinations A server destination, also called cloud mode, sends events from Chord to the vendor. Your shopper's browser isn't involved after the event reaches Chord. * It still works when a shopper uses an ad blocker or closes the tab. * It can send events that never happen in a browser, such as refunds and subscription renewals. * It supports [functions](/activate/event-streaming/functions.md), [retries](/activate/event-streaming/errors-and-retries.md) and [Notifications](/activate/event-streaming/notifications.md). * It has less browser context than a browser destination, such as the vendor's own cookies. ## Why use both For ad platforms, you usually want both versions. The browser version catches on-page behavior. The server version catches what the browser misses. When both versions send the same event ID, the vendor counts the action once. See [Deduplication](/activate/event-streaming/deduplication.md). Each vendor page in the [destination catalog](/activate/event-streaming/destinations.md) explains what its two versions do. ## Custom events Browser and server destinations treat custom events differently. See [Custom events](/collect-data/everyone-else/sdk-reference/custom-events.md). --- # 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/browser-and-server-destinations.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.