The Marketing Cloud data model works when you can answer three questions clearly: Who is this person? Where does their data live? Which records should Marketing Cloud message? At a high level, Marketing Cloud identifies people using a subscriber/contact key, stores profile and behavioral data in data extensions, and uses lists/data extensions to build audiences for emails and journeys. The most common implementation mistakes are inconsistent identity keys, duplicate records across systems, and data extensions built without ownership or refresh rules. If you define one durable key and a small set of well-structured data extensions (profile, preferences, events), segmentation and Journey Builder become far easier, and far more reliable.

The simple mental model (how it all fits together)

Think of Marketing Cloud data like this:

• Identity: one key that represents “this person”

• Attributes: profile fields (plan, region, lifecycle stage)

• Events: behaviors over time (signup, purchase, usage, case opened)

• Preferences/consent: what you’re allowed to send, and how often

Reasoning layer

• If identity isn’t consistent → everything downstream (segmentation, suppressions, reporting) becomes unreliable.

• If data extensions don’t have clear purpose → you end up with “tables everywhere” and no trust.

1) Subscribers vs Contacts (what’s the difference?)

These terms get used loosely, so align your team on one definition.

Subscriber (the messaging identity)

A subscriber is the record that Marketing Cloud uses to send messages to an address (often an email address). The subscriber record is tied to a Subscriber Key that should be stable.

Contact (the person profile)

A contact is the broader “person” record that journeys and audience logic typically reference across channels and datasets (especially in Contact Builder contexts). In practice, the most important thing is: your subscriber/contact identity should map to one durable key.

Practical takeaway

Many teams treat “subscriber key” and “contact key” as the same durable person ID to avoid confusion.

If X → then Y

• If you use email address as the key → you will create duplicates when emails change.

• If you use a stable customer/user ID → you can update emails without splitting the person record.

2) The key decision: Subscriber Key / Contact Key (choose it carefully)

Your key is the backbone of segmentation, suppression, and attribution.

Good key options (most durable)

• CRM Contact ID (if your CRM is the source of truth)

• Customer/user ID from your product or billing system

• A mastered ID from Data Cloud (if you’re using it)

Risky key options (avoid if you can)

• Email address (changes; creates duplicates)

• Phone number (changes; formatting issues)

• Name + company (not unique; messy)

Reasoning layer

• If the key can change → your history splits and journeys misfire.

• If multiple systems create different keys → unify identity before building more.

3) Data Extensions (the “tables” that power segmentation)

A data extension is essentially a database table inside Marketing Cloud.

The three data extensions most teams need first

A) Profile data extension (who they are)

Holds stable attributes used for segmentation:

• customer ID (key)

• email

• lifecycle stage

• plan/tier

• region/language

• account segment (if B2B)

B) Preferences/consent data extension (what you can send)

Holds:

• channel permissions (email/SMS)

• topic preferences (if used)

• global suppression flags

• frequency preferences (optional)

C) Events data extension (what they did)

Holds behavioral data:

• signup date

• purchase/order events

• product usage milestones

• inactivity signals

• key web/app events (if tracked)

Decision logic

• If an attribute drives segmentation repeatedly → it belongs in Profile.

• If it’s a permission or opt-out → it belongs in Preferences.

• If it happens over time → it belongs in Events.

How to structure data extensions (so they don’t become chaos)

Keep the model “thin and purposeful”

• fewer, well-owned tables beat dozens of random tables

• each data extension should have a clear purpose and owner

• define refresh cadence (real-time, daily, weekly)

Use consistent naming conventions

Example:

• DE_Profile_Master

• DE_Preferences_Consent

• DE_Events_Purchases

• DE_Events_ProductUsage

Document source of truth

For each field, define:

• which system owns it

• refresh frequency

• acceptable null/blank behavior

4) Lists vs Data Extensions (which should you use?)

You’ll still see lists in many orgs, but data extensions are typically the most scalable approach for segmentation and automation.

Use data extensions when:

• you need structured segmentation

• you have multiple attributes and relationships

• you want repeatable audiences for journeys

• you care about governance and data quality

Use lists when:

• you have a simple “send list” with minimal attributes

• you’re doing a small, one-off campaign (rare in mature orgs)

Reasoning layer

• If you’re doing lifecycle automation → data extensions are the standard.

• If you’re sending occasional newsletters → lists may be fine.

5) How Journey Builder uses your data model

Journeys work best when the entry event and segmentation are easy to query.

Journey entry patterns

Event-triggered journeys

• triggered when an event record lands (signup, purchase, inactivity)

• best for relevance and timing

Batch journeys

• triggered on a schedule using a segment refresh

• best when you don’t have real-time events

What breaks journeys

• identity key mismatches between entry event and profile table

• events arriving late or without required fields

• preference flags not checked at send time

6) Data quality and governance basics (the unsexy part that saves you)

Minimum governance you should set up

• one identity key standard (documented)

• data dictionary (field definitions + owners)

• refresh schedule and monitoring (failed automations)

• suppression logic and frequency caps

• change control for new data extensions and fields

Reasoning layer

• If anyone can create new tables freely → the model becomes unmaintainable.

• If refresh fails silently → segmentation and journeys become inaccurate.

A simple “starter data model” you can copy

If you want a baseline structure, start here:

1. DE_Profile_Master (1 row per person)

2. DE_Preferences_Consent (1 row per person)

3. DE_Events_Signup (many rows per person)

4. DE_Events_Purchase (many rows per person)

5. DE_Events_Usage (many rows per person, if SaaS)

6. DE_Suppression_Global (one row per suppressed identity)

Common mistakes (and fixes)

Mistake: using email as the primary key
Fix: use a stable customer/user ID and treat email as an attribute.

Mistake: too many “one-off” data extensions
Fix: create a governed model with reusable profile and event tables.

Mistake: no refresh and monitoring
Fix: automate refresh schedules and monitor failures.

Mistake: preferences stored inconsistently
Fix: centralize consent and suppression logic in one place.

Frequently Asked Questions

What is a subscriber key in Marketing Cloud?

A subscriber key is the unique identifier Marketing Cloud uses to track and send messages to a person. It should be stable over time (ideally not an email address).

What is a data extension?

A data extension is a table in Marketing Cloud used to store profile, preference, and event data for segmentation and automation.

Should we use email address as the subscriber key?

Usually no. Emails change, and using email as the key often creates duplicates and broken history. A stable customer/user ID or CRM contact ID is typically better.

What data extensions should we create first?

Start with a Profile data extension (one row per person), a Preferences/Consent data extension, and 1–2 Events data extensions for the triggers you need (signup, purchase, usage).

Book a Marketing Cloud roadmap session

If your Marketing Cloud journeys are hard to scale, it’s usually a data model issue. Book a roadmap session and we’ll define your identity key strategy, design a clean set of data extensions, and connect them to journeys with governance and monitoring.