> 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/destinations/email-and-marketing/dotdigital.md). # Dotdigital Dotdigital is a marketing automation platform for email, SMS and cross-channel programs. Chord sends events to Dotdigital from the browser and from the server. ## What each version does * [**Dotdigital Tag**](/activate/event-streaming/destinations/email-and-marketing/dotdigital/dotdigital-tag.md) loads Dotdigital in the shopper's browser and feeds it your Chord events. It owns web behaviour tracking, abandoned browse and abandoned cart. None of that can be driven from a server. In Chord, you add it as **Dotdigital Tag**. * [**Dotdigital server**](/activate/event-streaming/destinations/email-and-marketing/dotdigital/dotdigital-server.md) sends events and contact updates to Dotdigital's v3 API from Chord's servers. It owns the contact record, including data fields, address book membership and consent records, which the Tag's identify call cannot write. In Chord, you add it as **Dotdigital**. ## Why use both The two versions are complementary rather than duplicates, and both can run on the same Dotdigital account. The browser version catches on-page behavior and makes abandonment work. The server version survives ad blockers and closed tabs, and keeps the contact record up to date. Order and cart data lands in two places when you enable both. The Tag writes into Dotdigital's own order and cart collections, the ones its abandoned cart program and order content blocks read. Dotdigital's Events API is not permitted to write into those collections, so an order reported by the server version creates a separate, generically named Insight data collection instead. That is not double-counting in Dotdigital's order reporting, but an order reported by both versions exists as two records in two collections. Decide which version is your source of truth for order segmentation and content, and build against that collection. If you only want one, the Tag is the one to keep for abandonment. The server version is the one to keep if reliability against ad blockers matters more. ## How they deduplicate Every event the server version sends carries an `id`, which is Dotdigital's documented unique event identifier, set to the event's own message ID. The Tag's custom events carry a `messageId` attribute with the same purpose. If you also push events into the same Dotdigital account from another system, that is the value to deduplicate against. Commerce calls from the Tag are different, and the limitation is Dotdigital's rather than Chord's. `cartUpdate`, `checkout` and `purchaseComplete` accept no per-call event identifier. The order's own `orderId` and the cart's `cartId` are the only handles available, and Dotdigital does not document deduplicating on either. Treat "report each order once" as the rule rather than relying on Dotdigital to sort out a repeat. Chord skips an `Order Completed` that carries no order reference (an `order_id`, an `order_name` or a cart ID) for the same reason. ## Set up * [Dotdigital Tag](/activate/event-streaming/destinations/email-and-marketing/dotdigital/dotdigital-tag.md) * [Dotdigital server](/activate/event-streaming/destinations/email-and-marketing/dotdigital/dotdigital-server.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/destinations/email-and-marketing/dotdigital.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.