Marketing automation: building programs that behave predictably
The Marketing automation domain tests whether you can design, launch and maintain journeys in Dotdigital's visual program builder - not simply send one-off campaigns. Questions focus on enrollment, node behaviour, branching logic and the rules that decide who moves forward and who exits.
The program model
A program is a canvas of nodes: a Start node that defines the enrollment trigger, Send message nodes (email, SMS, push), Delay nodes, Decision nodes that branch on rules, Condition/"wait until" nodes that hold a contact until an event occurs or a timeout expires, Update contact nodes, Webhook nodes and End nodes.
- Enrollment triggers are typically "contact added to an address book", a date-based trigger such as birthday or anniversary, or an API/insight event.
- Decision rules can test opens and clicks inside the program, data field values, segment membership and consent.
- A contact is normally active in a given program once; re-entry depends on the program's re-enrollment setting.
- Delays are relative (wait three days) or absolute (wait until a date and time) and follow the account time zone.
- Suppression lists and consent are evaluated at send time, not at enrollment.
Worked example
A welcome journey enrolls everyone added to the Newsletter address book. After an immediate send, a two-day delay feeds a Decision: "clicked any link in the welcome email". Clickers receive a category guide; non-clickers wait five more days and get one reminder, then End.
Reasoning: the Decision must sit after the Delay so the contact has had time to open the email. Placed immediately after the Send node it would evaluate clicks at the moment of dispatch and almost everyone would fall into the "no" branch. The reminder also carries an exit rule, so a contact who purchases or unsubscribes during the delay leaves the path instead of receiving an irrelevant message.
Traps that cost marks
- Assuming a Decision node waits for an event; only a Condition/"wait until" node does, and its timeout defines the fallback branch.
- Forgetting that editing a live program changes the path for contacts already inside it - pause and restructure instead.
- Building a win-back program without an exit rule, so converted contacts keep receiving offers.
- Expecting a contact already in the program to re-enroll on a second trigger.