The Dotdigital Tag provides you with a set of calls for telling Personalization abut the behavior of your site visitors. Each call describes something specific: who the visitor is, which product they viewed, what's in their cart, or what they bought.

For each call, you should understand why it matters, when to fire it and where on your site that should happens.

Some attributes apply to every call you make with the Tag, such as the currency and language a visitor is using on your site, or the site brand used within the Personalization platform.

The ddg.configuration call lets you set these values once. Every other call made during the session (productBrowse, productList, cartUpdate, purchaseComplete, and so on) inherits the site brand, currency and language from it, so you don't have to set them on each call.

Make this call when the visitor's session starts, when they first reach your site. The only other time you need to run it is if the visitor moves to a different site brand or changes currency or language while browsing.

If you can't determine the start of the session, you can make the configuration call on every page during the session.

Visitors have a right to decide whether a website stores data in their browser. Depending on where you operate, regulations such as GDPR may require you to get permission before setting non-essential cookies.

The Dotdigital Tag sets cookies to recognize a visitor across pages and visits. Your consent manager is the source of truth for whether the visitor has agreed, and the Tag has no way of knowing their choice unless you tell it.

ddg.setCookiesConsent is how you tell the Tag whether the visitor has consented to cookies, and how it should behave. Getting this right protects your brand and keeps your data usable.

Call ddg.setCookiesConsent with true or false whenever the visitor's cookie permission is set or changes. Connect it to your consent manager so it fires on page load — to restore a saved choice — and on any later change.

The track call records that a visitor viewed a page. It's the foundation for everything else the Tag does: every other call describes something specific, such as a product, a cart, or an order, while track describes the visit itself.

It captures page views and browsing behavior across your whole site, not only the product and cart pages. That gives you the context to understand where visitors go and what they look at before they act. Pages with no products on them, such as your blog, help center or pricing page, are still part of the visitor's story.

ddg.track also makes the more specific calls easier to use. When a visitor's page history sits alongside their product and cart data, you have a fuller picture to build rules and segments from.

Call ddg.track on every page of your site that doesn't have its own dedicated call. If your site is a single-page application, call ddg.track each time the visitor moves to a new view so page changes aren't missed.

Never fire ddg.track on a page where another, page-specific call is already firing. As a rule of thumb:

If you load the Tag through Google Tag Manager, this affects your triggers. A single all pages trigger for ddg.track would fire it everywhere. Use page type triggers so ddg.track only fires where nothing else does.

This is one of the most important calls to make. When you make the identify call, you take an anonymous visitor and de-anonymize them using an email address or mobile number they've provided. This opens the door to growing your relationship with this visitor across web, email and SMS, creating a connected, personalized experience.

Once they're identified, the visitor's previous browsing behavior is joined with their current session in Personalization. If they exist in Marketing, their browsing behavior also syncs to that contact record.

Identification also allows abandoned browse and abandoned cart messages to be sent: without a known contact, there's no one to send to. Session data from unidentified visitors is still stored against an anonymous record and can personalize their future website visits.

Make this call as soon as the visitor first provides their email address or mobile number on your site. That's usually anywhere they might enter their contact details:

Anywhere a visitor might provide an email address or mobile number should be targeted, and ddg.identify should fire once they've given their details.

The productBrowse call captures the details of a product or item your visitor has viewed on your site.

Doing this:

Call productBrowse whenever a product description page loads or is updated. If a shopper visits a product page, it should run. If they choose a variant, such as a new color or size, call productBrowse again to specify the variant details they've chosen.

If you're not running a standard ecommerce site, and instead work with trips, memberships, subscriptions or other non-traditional products, run this call whenever the visitor views a page specific to your object.

The productList call captures any products a visitor may have viewed while scrolling through a list. It's useful for updating multiple products at once, and for recommendations and rules based on products a visitor has generally browsed. It can also trigger abandoned browse messaging, whether on your site or in email.

Make this call any time the visitor views multiple products on a single page. The most common example is a product category page or a sales or promotion page. Other examples include search results and filtered views.

cartUpdate tracks whenever a visitor adds, updates or removes an item in their cart. With this information you can power recommendations such as frequently carted, or progress bar banners showing how close someone is to a spending goal. Even more importantly, you can re-engage visitors who don't complete their purchase.

The cartUpdate call is critical for abandoned cart messaging, triggers, and segmentation. Without it, none of that functionality is available.

Make the call any time someone adds something to their cart or updates their cart. That might be on a product page, when clicking an add to cart button, or on your home page or a catalog page with a quick add to cart button. It could be on the cart page itself, where a shopper might add, remove or change the quantity of products. Think too about any scenario where someone views a mini version of their cart and makes changes, whether in a sidebar or elsewhere.

Where this happens largely depends on your site. The most important part is the when: whenever the cart or an item in the cart is updated.

The checkout call tells the platform that a visitor has moved from building a cart to actually checking out. It also updates the cart phase within Dotdigital Marketing, which can be used in automated programs.

That distinction matters. Without it, a visitor who added one item three days ago looks the same as a visitor who entered their shipping details a minute ago. With it, you can treat those two groups differently in triggers, segments, and reporting.

checkout also fills the gap between browsing and buying. Without cartUpdate and checkout, the platform sees a productBrowse and then a purchaseComplete with nothing in between.

Call checkout when the visitor starts the checkout process. This is usually the first step of your checkout flow, once they click through from the cart.

Not every site has a traditional checkout. Examples include a single-page checkout, a booking flow or a donation form. Fire checkout at the point where the visitor begins the process of completing the transaction.

The purchaseComplete call tells the platform that the visitor bought something. It marks the completion of the purchase cycle, updating the cart phase so the visitor drops out of abandoned cart and abandoned browse messaging.

It also records the purchase or order against the visitor. Purchases power product recommendations and can be used in segmentation and slot rules to further personalize web and email content for that shopper.

Call purchaseComplete once, on the order confirmation page or at the moment the order is confirmed. Only fire it for orders that are actually completed.

Not everything your visitors do fits a product or a cart. The event call lets you send custom events with any attributes you choose. Examples include a destination search, a quote request or a video view.

By capturing these custom events, unique to your site, you can use the data for segmentation, automation, rule building and more, to create a fully personalized experience.

Call event whenever a visitor does something meaningful for your business that the other calls don't cover. Choose the moment, then name the event and pass the attributes that describe it. If you have no attributes to add, pass an empty object.

Custom events are optional. The calls listed above are what makes the platform work; event is what makes it fit your business.