Dotdigital (Tag)

dotdigital is a marketing automation platform for email, sms and cross channel programs the dotdigital tag destination loads dotdigital in the browser and feeds it your chord events, so it can track web behaviour, recover abandoned browses and abandoned carts, and report orders this is the surface that makes abandonment work dotdigital's abandoned cart program starts its timer from the last cart update it saw in the browser, and abandoned browse depends on the visitor session the tag establishes — neither can be driven from a server for contact data fields, address book membership and consent records, pair this with the dotdigital # destination getting started you need one value, and one thing removed your tag url in dotdigital go to connect > connect website , select view code , and copy the src value out of the script tag it looks like https //r1 ddlnk net/dm 0000000000 01/ddgtag , or https //emails yourbrand com/dm 0000000000 01/ddgtag js if your account uses a branded domain dotdigital generates this per account, so use the one your account shows rather than adapting an example — the host varies, and it is the host your storefront's content security policy has to allow remove any dotdigital tag you installed yourself , including one added through a commerce platform app this is not a preference two tags on one page create two sessions, double every page view, and split one shopper's behaviour across both this destination replaces that installation rather than complementing it three settings are optional but worth filling in abandoned cart delay and abandoned cart program id — how long dotdigital waits after the last cart update, and which program to enrol into find the program id in the url when you open it under automation > programs without them dotdigital applies your account defaults cart url — your storefront's cart page required dotdigital rejects a cart update unless every line carries a product url, and this is what chord falls back to for a line that has none, so leaving it empty stops cart tracking working at all it is also the link a shopper follows out of an abandoned cart email site brand — only if your account uses dotdigital personalization connecting to the dotdigital cdp destination warning before connecting destinations in the chord cdp, please verify with all destination owners that all non chord cdp configured destinations are disabled running external destinations alongside configured chord cdp destinations can result in duplicate events downstream log into the chord data platform navigate to the cdp click the "add" button next to destinations select dotdigital tag from the destination catalog enter the destination name and your tag url , plus any of the optional settings above click "create" to connect connect it to your front end site remove your own dotdigital tag from the storefront using alongside the dotdigital destination the dotdigital # destination talks to dotdigital's v3 api server side the two are complementary rather than duplicates, and both can run on the same dotdigital account this destination owns web behaviour tracking, abandoned browse and abandoned cart none of that is reproducible server side the dotdigital destination owns the contact record — data fields, address book membership, consent records — which this destination's identify call cannot write it is also unaffected by ad blockers one thing to know before you enable both order and cart data lands in two places this destination writes into dotdigital's own order and cart collections — the ones its abandoned cart program and its order content blocks read dotdigital's events api is not permitted to write into those same collections, so when the server side destination reports an order it creates a separate, generically named insight data collection instead that is not double counting in dotdigital's order reporting, but it does mean an order reported by both surfaces exists as two records in two collections if you segment or build content on order data, decide which surface is your source of truth and use that collection if you only want one, this destination is the one to keep for abandonment, and the server side destination is the one to keep if reliability against ad blockers matters more deduplication custom events carry a messageid attribute — a unique identifier for that event if you also push events into the same dotdigital account from another system, that is the value to deduplicate against commerce calls 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 — it describes them only as unique identifiers so 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 id for the same reason an order with no reference cannot be deduplicated or reconciled by anyone event mapping chord event dotdigital page viewed page view product viewed product browse product list viewed product list product added , product removed , cart viewed cart update checkout started checkout order completed purchase, with the order reference and cart identify , email captured , signed up , user created contact identification any other track event custom event under its own name — see custom events product and cart data dotdigital uses two different product shapes, and chord sends the right one for each call product browse and product list send chord event property dotdigital field product id productid sku sku name name url , falling back to the page url url image url imageurl and imagethumbnailurl price price currency currency brand brand category categories description description variant id variantid imagethumbnailurl is filled from the same image as imageurl because chord's tracking plan carries one product image dotdigital's default content blocks read the thumbnail, so an empty one renders a blank image in a browse abandonment email cart lines send chord event property dotdigital field product id productid sku , falling back to variant id then product id sku name name price price quantity quantity price × quantity totalprice image url imageurl url , falling back to the event's url for the line that changed, then the cart url setting url brand brand category categories variant id variantid cart totals send chord event property dotdigital field cart id , falling back to order id or checkout id cartid currency currency subtotal , falling back to the sum of the line totals subtotal total grandtotal cart url , falling back to the cart url setting carturl shipping shipping discount discountamount tax taxamount a product line with no resolvable product id is dropped rather than sent blank, because dotdigital keys its catalogue and its abandonment content off the product id fields dotdigital requires dotdigital rejects a call outright when any of these is missing, and chord's tracking plan marks them optional chord fills each one so your events are not refused, but the substituted value is a fallback, not your data — send the real one and it is always preferred field substituted with what you lose by relying on it product url on a browse the url of the page the event fired on nothing, normally on a product viewed the page is the product's page product url on a cart line the event's own url for the line that changed, then your cart url every other line links to your cart page instead of its product the shopper still returns to their basket, but not to the item they were looking at sku on a cart line variant id , then product id if your dotdigital catalogue is keyed on real skus, the line will not match a catalogue entry, so merchandising blocks in your emails have nothing to render cart subtotal the sum of the line totals nothing, normally — it is arithmetic on the lines you sent, and excludes tax and shipping exactly as dotdigital's own subtotal does if no line carries a price, chord sends no subtotal and dotdigital refuses the cart, rather than reporting it as free sending sku and url on your cart lines is worth the effort they are the two whose fallbacks change what a shopper sees in an email note that chord's tracking plan currently documents a product url at the event level but not inside the products array — so per line urls are something to add to your event payload deliberately every cart update sends your whole basket, not just the line that changed dotdigital's cart update replaces the cart it has stored, and its abandonment timer runs against that so if your product added event carries a products array, chord sends all of it send the full basket on those events, or dotdigital's cart will be narrower than your shopper's a cart update with no cart id is skipped, because dotdigital tracks abandonment against the cart identifier and a cart with no stable id looks like a new abandoned cart on every change identity dotdigital receives the email address, mobile number and name in plaintext , and this is deliberate dotdigital has to actually deliver mail and sms to the person, so unlike an advertising pixel it accepts no hashed identifier — hashing would break delivery rather than protect anything if your security review needs to know exactly what leaves the page, that is the list chord trait dotdigital field email email phone mobilenumber first name firstname last name lastname first name + last name fullname mobile numbers must be in e 164 format — +14155550123 a number with no country code is skipped rather than guessed at completing it would mean assuming a country, and a wrong assumption can resolve to a real contact somewhere else and send them someone else's messages formatting like spaces, dashes and brackets is fine; a leading 00 is treated the same as + an identify with neither an email nor a valid e 164 mobile number is skipped, since dotdigital has no contact to attach it to the name fields are personalization only dotdigital's marketing platform ignores them, so they matter only if your account uses personalization custom events dotdigital's event taxonomy is open an event chord has no specific mapping for is forwarded under its own name, and dotdigital creates an insight data collection for it loyalty tier changed becomes a loyalty tier changed collection — dotdigital replaces non alphanumeric characters with underscores when it names the collection two limits custom events need the cxdp package on your dotdigital account without it dotdigital cannot accept them, and because the tag's calls are fire and forget the rejection is invisible from the page turn send custom events off if your account does not have cxdp turning it off does not affect any of the mapped commerce events nine collection names are reserved by dotdigital for its own features cartinsight , catalog , consentinsight , easyeditorextensions , nostoemailcampaigns , orders , productcategories , webinsight and wishlist an event whose name matches one of those is skipped, and the reason is logged to the browser console property mappings you can map any event property onto a destination field from the connection's mapping configuration mapped properties use a bare path on this destination — properties customer type → customer type , with no properties prefix on the destination side mapped properties reach custom events only they are forwarded as attributes on the custom event call, and nowhere else that is a dotdigital constraint rather than a chord choice identify , the product calls and every cart call take a fixed set of fields with no property bag anywhere, so an extra key has nowhere to go a mapping you configure will not appear on a product view, a cart update or an order mapping onto a field dotdigital does accept still works — a mapping that rewrites properties sku changes what chord reads for the product's sku , because mappings are applied before the payload is built it is only destination keys with no dotdigital equivalent that have nowhere to land personal fields — email , phone , first name , last name and their camelcase forms — are never forwarded as custom attributes they go through the identification call above instead content security policy if your storefront sets a content security policy, the dotdigital tag will not load until its hosts are allowed the symptom is silence no tracking, no abandonment, and a refused to load or refused to connect message in the browser console the first host to allow is the one in your own tag url, and it is account specific dotdigital serves the tag from ddlnk net for some accounts and from a domain of your own for others — an account configured with a branded sending domain gets a tag url like https //emails yourbrand com/dm 0000000000 01/ddgtag js read the host off the tag url you pasted into the destination and allow that one, rather than assuming the table below covers you directive host script src the host from your tag url, plus https // ddlnk net connect src the host from your tag url, plus https // ddlnk net , https // trackedweb net both directives are required script src lets the tag load; connect src lets it report — and a policy that allows only the first fails in a way that looks like it worked, because the script runs and nothing reaches dotdigital this list was confirmed on a live account , with one addition worth knowing the account tested had a branded domain, and its tag url host had to be allowed in script src on top of the two dotdigital domains that host differs per account, which is why it cannot be listed here dotdigital does not publish its csp requirements, and the tag routes to a regional host at runtime, so treat the table as a starting point rather than a complete list verify it during setup load a page with the destination active, then fire a product view, a cart update and an order, and add any host named in a violation check the network tab as well as the console — a blocked image beacon can be quieter than a blocked script gotchas two tags is the most common problem if page views look doubled or abandonment fires against a cart that does not match, check whether a hand installed dotdigital tag or a platform app is still on the page dotdigital's calls are fire and forget they return nothing and throw nothing, by design, so a rejected call does not surface on the page to confirm a call succeeded, inspect the request in your browser's network tab a 200 means dotdigital accepted it, a 4xx means something is misconfigured cart abandonment needs a cart update on every page dotdigital's timer runs from the last cart update it saw, so a storefront that only reports the cart on the cart page will trigger abandonment early fire a cart bearing event as the shopper continues browsing an empty order completed is skipped an order event with no products is not sent, because it would write an empty order into the collection your post purchase programs and order content blocks read — an email with nothing in it consent gating applies if the destination is configured with required consent categories, no dotdigital call is made for visitors who have not accepted them updated 9 september 2026