A Practical Dotdigital Program Builder Guide for Ecommerce Retention

By Trayan Hristov · Thrivelia · Reviewed 13 October 2026

Dotdigital’s Program Builder should express a clear customer journey. Begin with the next action you want to help a customer complete, then confirm that the connected data can support that decision.

For a retail team, that might mean a better first-purchase welcome, a relevant recovery message or product education after delivery. The programme should fit the product model and the people responsible for maintaining it.

Establish the connected data contract

List the store, CRM, subscription and service data the proposed journey needs. Define the source of truth for identity, order status, permission and product information. Assign an owner to data latency and failure handling; a programme cannot correct information it never receives.

Select a small set of real customer examples. Trace their events through the connected systems and record when the relevant state becomes available. For a purchase-aware programme, test both the customer who has not purchased and the customer who buys while waiting.

Map the programme before adding nodes

Dotdigital’s official automation guidance covers Program Builder, triggered email and SMS/MMS, with transactional email treated separately. Welcome, customer preferences and cart-related programmes are examples of its automation use cases. Confirm the relevant channel, integration and feature scope for your account.

Write a journey map in plain language: eligible customer enters; a wait gives them time; a decision reflects their current situation; a useful message offers the next action; the programme stops or moves on when its job is complete. Each branch should have a customer reason and a clear owner.

Use Dotdigital’s automation guide as the official starting point for the live interface.

Choose the content and fallback together

For a home product, a first-use email can explain setup or care before introducing a complementary purchase. For apparel, it can resolve fit and styling questions. For a replenishable product, it can help the customer establish a routine before sending a reorder reminder.

Dynamic product content needs a deliberate fallback. Decide what to show when a product is unavailable, a property is missing or a customer’s preferences are unknown. Review the fallback as a real email rather than accepting an empty space in the template.

Plan a release that the team can explain

Run controlled customer scenarios before the first release and monitor the initial cohort. Keep the approved journey map, screenshots and observed behaviour in one release record. If a programme already has participants, review their states before making a structural change.

Check	Expected result	Owner to name
Data and eligibility	The intended customer state is represented accurately	Integration or data owner
Waits and decisions	The next path remains relevant after a customer acts	Lifecycle strategist or builder
Content and links	Mobile, dynamic and fallback versions work	Creative and QA owner
Launch and exceptions	The team can pause, diagnose and recover a problem	Release and escalation owner

Compare the quote and measure the programme

Request a written scope for contacts, channels, integration, support and any required services. Add internal production and governance time to the twelve-month cost comparison. A licence comparison without implementation work will understate the budget for a connected programme.

Measure the intended action and its timing alongside deliveries, clicks and attributed revenue. For retail, add repeat-purchase progression and relevant returns or cancellations. Our platform budget guide provides a matched quoting approach. Discuss your lifecycle brief when you need an account-specific scope. Documentation reviewed 13 October 2026.

Worked build: browse follow-up for a higher-consideration product

Consider an illustrative home brand where shoppers compare materials and dimensions before buying. A useful browse programme should recognise product interest, answer a decision question and stop when the customer purchases or the product information is no longer usable.

The first decision is whether a browse signal is reliable enough to act on. Repeated visits to one product can be different from opening a general collection. Decide which behaviour indicates useful intent, what data must be present and how the programme will behave if the customer is looking for a gift or comparing several products.

Specify the programme’s data and ownership

Use your live integration’s data model rather than assuming every storefront provides the same fields. Define the interval in which a browse remains relevant and record the difference between an event-time snapshot and the latest product availability.

Input	Why it matters	Owner to confirm
Customer identity and permission	The right person can receive the marketing message	CRM or marketing operations
Browse context	The product and timestamp are actually available	Web or integration team
Order and recent purchase context	The reminder should stop or change after purchase	Commerce integration owner
Product availability	The proposed product can still be bought	Catalogue or commerce owner
Content fallback	A missing product still produces a useful experience	Creative and lifecycle team

Map the Program Builder nodes to customer decisions

Dotdigital’s Program Builder uses connected actions, delays, decisions and end points. Its browse-programme guide describes using a decision to exit contacts without relevant product data or with a very recent purchase. Review working with Program Builder and the abandoned-browse example before adapting the live account.

Node purpose	Question to resolve	Proposed path
Start	Does the contact qualify for the programme?	Enter the reviewed audience
Delay	How much time should the shopper have?	Wait for a defined, tested interval
Decision	Is there useful browse data and no disqualifying recent purchase?	Continue or end
Campaign	What product question should the message answer?	Send the approved content and fallback
Decision or end	Does another message have a distinct useful job?	Continue only when the brief justifies it

Make the content answer the buying question

An illustrative first email could use ‘The detail to check before choosing your size’ and lead into the relevant dimension guide. A later message could explain material or care with approved product evidence. If the product is unavailable, an approved alternative or useful category guide is better than an empty product block.

Keep message frequency connected to the rest of the account. A customer may also enter a welcome journey or receive a campaign on the same day. The programme brief should establish which message has priority and which customer action should stop another reminder. Record the rule in the account’s operating documentation.

Use an integration-aware QA matrix

Keep a named owner for each failing data test. Creative QA cannot resolve a purchase event arriving after the reminder has already sent. Review the first live participants and compare the observed paths with the approved map before expanding the audience.

• Known shopper with useful browse data: the right product and guide appear.

• Browse data missing or stale: the programme reaches the agreed fallback or end.

• Purchase arrives during the delay: the browse reminder follows the new state.

• The product becomes unavailable: its content is replaced or the message is withheld according to the brief.

• Several products were browsed: the selected content follows a defined rule.

• Identity or permission differs between source systems: the discrepancy is resolved before launch.

• A welcome and browse programme overlap: the intended priority and frequency are maintained.

Measure the decision and the cost of maintaining it

Report eligible shoppers, useful-data coverage, deliveries, qualified product clicks and the intended purchase or enquiry outcome. For an illustrative cohort of 2,000 eligible shoppers, 1,600 have usable product context: data coverage is 80%. If only that group receives the message, its click or conversion rate should use the delivered group rather than all 2,000 shoppers.

Check whether the programme helps a considered purchase rather than only claiming nearby orders through attribution. Keep a comparable observation period and include relevant returns or cancellations. Use a suitable holdout when the decision requires an estimate of incremental value.

Request a quote that includes contacts, channels, integration and support requirements. Add catalogue maintenance, creative fallbacks and release ownership to the operating budget. For a connected retail programme, those responsibilities can determine practical value as much as the licence line.