One signal path, from your data to every channel.
How we build Marketing Cloud setups that keep working after go-live: four steps, one data model, and a loop that feeds results back in.
Most Marketing Cloud problems we are called in to fix are not tool problems. The journeys work, the emails render, the automations run. What breaks is the path between them: data arrives in three shapes, consent lives in two places, and nobody can say which contact got which message, or why.
Our method exists to make that path boring. Every project, from a single welcome journey to a full implementation, follows the same four steps.
1. Collect: decide what enters, and how often
Before we build anything, we list every source and agree three things for each: the key that identifies a person, how often the data arrives, and who owns it. Marketing Cloud Connect handles CRM objects; REST APIs handle real-time events such as a cart update; SFTP imports handle what can wait until morning.
The rule we hold to is simple: if a field is not used by a journey, a segment or a report, it does not get imported.
2. Unify: one key per person
Duplicate contacts are the most expensive mistake in Marketing Cloud, because they cost money on every send and break every report. We pick one Subscriber Key, usually the CRM Contact or Lead ID, and design the data extensions around it in Contact Builder, with consent stored next to the person it belongs to.
For brands that need identity resolution across many sources, Data 360 (the new name for Data Cloud since October 2025) unifies profiles and sends segments back into Marketing Cloud. We activate it when the data really needs it, not by default.
3. Orchestrate: journeys that decide
A journey should react to behaviour, not to a calendar. We build entry sources on real events, wait before deciding, split on signals we trust, and set goals so that people leave a journey as soon as they have done what it was built for.
4. Activate: every channel, measured in one place
Email, SMS, push and paid audiences go out from the same model, so the same suppression rules and the same consent apply everywhere. Every send writes back what happened, which is what makes the last step possible.
Measure, then loop
Results are not a monthly slide. Clicks, conversions and unsubscribes return to the data model and change the next decision: who enters, which path, how often. That loop is what we mean by a setup that runs itself.
Key takeaways
- Import only what a journey, segment or report will use.
- One Subscriber Key per person, with consent stored next to it.
- Journeys react to events and have goals, not just end dates.
- Every result flows back into the data model.
Keep reading
Want this inside your instance? Let’s build it together.
Tell us where you are and we’ll tell you what it takes to get there.
Talk to us