Contact Builder and Data Modelling
A Marketing Cloud Engagement data model built on a stable contact key, clear relationships and documented data extensions, so every journey and segment uses the same data.
The Marketing Cloud Contact Builder data model decides what every journey, segment and personalised email can see. When it is designed well, a marketer can split a journey on a customer's latest order without writing SQL. When it is not, teams copy data into dozens of single-use data extensions, contacts are duplicated under different keys, and nobody can say which table holds the current value.
GeekMidst designs and repairs data models in Marketing Cloud Engagement, from the choice of contact key to the relationships in Data Designer and the processes that keep data current.
Signs your data model needs attention
- The same person exists as several contacts because some sends used email address and others used a CRM ID as the subscriber key.
- Journey decision splits cannot reach the data they need, so every journey depends on a custom entry data extension.
- Data extensions have no primary keys, unclear names and no retention settings, and the contact count keeps growing.
- Synchronised data from Salesforce and imported data disagree, and nobody knows which wins.
- Deleting a contact for a privacy request is slow and uncertain because data is spread across untracked tables.
The decisions that shape the model
| Decision | What to consider |
|---|---|
| Contact key | Use a stable, unique ID such as the Salesforce Contact or Lead ID, not email address, and apply it everywhere |
| Attribute groups | Group related data extensions around the contact so journeys and filters can navigate them |
| Relationships | Set cardinality correctly, one-to-one for profile data and one-to-many for orders or events |
| Primary keys | Every data extension needs keys that match its grain to prevent duplicate rows |
| Sendable data extensions | Define the send relationship to Subscriber Key consistently |
| Retention | Set retention policies on transient and staging data so storage and contact counts stay controlled |
| Source of truth | Decide which system owns each field and how often it refreshes |
How Contact Builder fits together
Contact Builder links your data extensions to the contact record through attribute groups. Inside each group, Data Designer relationships say how one table relates to another, for example a customer profile linked to many orders, each linked to many order lines. Journey Builder and some filtering tools use those relationships to look up contact data at the point of decision, which is why an incorrect relationship can produce a split that quietly evaluates the wrong row.
If you use Marketing Cloud Connect, synchronised data extensions bring Salesforce objects into Marketing Cloud on a schedule. They are read-only in Marketing Cloud, so transformations usually happen in SQL Query Activities that write to your own data extensions. We cover common issues in Marketing Cloud Connect sync patterns and pitfalls.
Data extension design deserves its own care: primary keys, sendable fields and retention are the choices that most often cause trouble later.
How we approach a data model project
- 01
Map sources and uses
List every source feeding Marketing Cloud and every journey, segment and email that consumes data, so the model serves real needs.
- 02
Audit the current state
Check contact key usage, duplicate contacts, data extension keys, relationships, retention and automation that loads data.
- 03
Design the target model
Document the contact key, attribute groups, data extensions, relationships, refresh frequency and field ownership.
- 04
Plan the transition
Sequence changes so live journeys and automations keep running, including any contact key clean-up and re-pointing of sends.
- 05
Build and validate
Create or restructure data extensions and relationships, update loading automations and check row counts and sample contacts at each layer.
- 06
Document and hand over
Provide a data dictionary and diagram, and walk your team through how to add new data without breaking the design.
Related services and guides
Marketing Cloud SQL development
Query Activities that transform, deduplicate and load data into the model.
→CRM to Marketing Cloud sync blueprint
A reference design for moving CRM data into Marketing Cloud reliably.
→Data dictionary template
A structure for documenting every data extension and field.
→Segmentation and personalisation
Using the finished model to build audiences and tailored content.
→Questions we hear
Should we use email address as the subscriber key?
Do we still need Contact Builder if we use Data Cloud?
How do you handle data retention?
Can you work in our live account?
What do you deliver at the end?
Get your Marketing Cloud data model right
Tell us how data reaches Marketing Cloud today and where it causes problems. We will suggest whether an audit or a redesign makes sense.
