Subscriber Data Management
Lists, data extensions, and the subscriber model
All Subscribers is the master email status list. Lists are simple opt-in containers; data extensions are relational tables. A sendable data extension needs a primary key and a send relationship that maps a field to Subscriber Key. The trap: deleting a row from a data extension does not necessarily delete the subscriber from All Subscribers, and unsubscribing from a publication list is not the same as a global unsubscribe. Publication lists track which audiences a subscriber belongs to; suppression lists prevent sends to matching addresses or keys.
Contact Builder
Contact Builder is the cross-channel contact model. Contacts represent people, Attributes store profile values, and Data Extensions can be linked to a contact through the Data Designer. Cardinality matters: one-to-one, one-to-many, many-to-many. A customer with many orders is one-to-many from Customer to Order; the Order table uses a foreign key to the customer. A common trap is treating Contact Key and Subscriber Key as interchangeable in every context. Subscriber Key is the email identity used by Email Studio; Contact Key is the Contact Builder identity used across channels.
Status and consent
Email statuses include Active, Held, Unsubscribed, and Bounced. Held means the address is suppressed by status, not that the person opted out. Consent is channel-specific: an email unsubscribe does not automatically stop SMS.
Worked example: one customer, many orders. Model a Customer data extension with CustomerID as primary key and an Order data extension with OrderID as primary key and CustomerID as foreign key; link Customer to Contact with CustomerID as Contact Key. Rule: design keys before importing; changing a primary key later is painful.