Given the desired output requirements, set up Subscriber Lists and Data Extensions in the Marketing Cloud.
There are two different methods to store and segment subscriber data in Marketing Cloud: Subscriber Lists and Data Extensions. While Subscriber Lists have limited functionality, Data Extensions provide full flexibility to store and relate subscriber information.
A Subscriber List is a collection of Subscribers who opted-in to receive email communication from Marketing Cloud. Subscribers automatically belong to the standard All Subscribers list, and additional Subscriber Lists can be created to segment Subscribers for targeted email communication.
Subscriber Lists always store the email address and subscriber status for each subscriber in the list. Optionally, a Subscriber Key can be defined to identify Subscribers in Marketing Cloud. In addition, further information about Subscribers can be stored in Subscriber Lists, by creating profile and preference attributes.
The subscriber status defines the email deliverability to a single subscriber. Following statuses exist:
The Subscriber Key is a unique value assigned to each subscriber, to identify Subscribers in Marketing Cloud. Using the Subscriber Key feature to reference Subscribers is optional. If no Subscriber Key is used, then the email address is used for identification.
Using Subscriber Keys instead of email addresses to identify Subscribers, allows storing the same email address multiple times in the same or different Subscriber Lists. Like this, multiple subscriber attributes for the same email address can be maintained. A use case for this is if the same email address is shared by multiple Subscribers with different subscriber attributes, such as family members or business contacts.
Additional information about Subscribers can be stored with profile and preference attributes. Such attributes are defined separately from Subscriber Lists. However, they are defined globally and apply to all Subscriber Lists and Business Units. Apart from storing information, they can be used to build groups within Subscriber Lists and to drive dynamic content.
Attributes can be defined as either required or optional. If an attribute is required, then a value must be provided for each subscriber in the Subscriber List. To prevent empty values, a default value can be defined.
Furthermore, attributes can be defined as either as visible or hidden. If an attribute is visible, then Subscribers can update their own attributes in the Profile Center. If a subscriber uses the forward button instead of the Forward to a Friend feature to forward an email, then the Profile Center link will still point to the original subscriber's Profile Center. To protect the subscriber’s privacy, no sensitive attributes should be visible and included in the Profile Center.
Subscriber Lists can be defined as either public or private (not public). If a Subscriber List is public, then the list will appear in the Subscription Center. Subscribers can then opt-in or opt-out from that public list in the Subscription Center. If a subscriber uses the forward button instead of the Forward to a Friend feature to forward an email, then the Subscription Center link will still point to the original subscriber's Subscription Center. To protect the subscriber’s privacy, no sensitive lists should be included in the Subscription Center.
Subscriber Lists can be defined to send a welcome email when a new Subscribers opts-in to the list.
If a Subscriber List requires double opt-in, then new Subscribers need to confirm their email address before they receive email from that list. New Subscribers will receive an email containing a link to confirm their email address. Until the link is opened, the subsided status of new Subscribers remains Unsubscribed. After the link is opened, the status changes to Active, and the new subscriber will receive emails sent using this list. The confirmation link can optionally link to a landing page.
Subscriber Lists can either be included or excluded in email sends. Targeted Lists are included Subscribers Lists, while Exclusion Lists describe excluded Subscriber Lists at send time.
Emails can be targeted and sent to multiple Subscriber List at the same time. To allow further segmentation, groups of Subscribers can be created within Subscriber Lists and included in sends.
Subscriber Lists can either be included or excluded in email sends. An Exclusion List is a Subscriber List which is excluded at the time of send. Subscribers in Exclusion Lists are only temporary withheld from a send, and can be included in future sends.
An example to use Exclusion Lists is when two Subscriber Lists A and B contain some of the same Subscribers. If an email is sent to Subscriber List A in a first send and then to Subscriber List B in a second send, some Subscribers might receive the email twice. To avoid this, the Subscriber List A can be added as an Exclusion List in the second send. If the Subscriber Key feature is enabled, Subscribers are excluded based on their Subscriber Key, otherwise based on their email address.
A Data Extension is a relational database table in Marketing Cloud to store subscriber or any other type of data. They can be used to maintain subscriber information which cannot be stored with profile or preference attributes in Subscriber Lists. For example, if a subscriber can have multiple values for the same attribute, or if an attribute is related to another attribute.
Data Extensions can also be used to store imported data from external systems in Marketing Cloud. The imported data can then be used in Marketing Cloud functionalities, such as to segment Subscribers or to include dynamic email content.
As Data Extensions are relational database tables, they consist of fields and relationships. Fields define which information can be stored in a single Data Extension, and relationships specify dependencies between two Data Extensions. Furthermore, Data Extensions can be used to send emails to. In this case, a Send Relationship must be defined to link data in Data Extensions to Subscribers in the All Subscriber list or Publication or Suppression Lists.
Data Extension fields define which information can be stored and correspond to columns in the relational database tables. As many fields as needed can be created for a Data Extension.
For each Data Extension field, the following properties must be defined:
Data relationships link two Data Extensions based on a common field contained in both tables. The common field is often the primary key of one of the two Data Extensions.
Data relationships can be used for advanced segmentation, by filtering related data across data relationships. They can also be used to include information from related Data Extensions in dynamic email content.
Data Extension can be created with three different methods:
Data Extensions can be defined as Sendable and Testable. Sendable Data Extensions can be used for sending emails, Testable Data Extensions for testing emails.
Sendable and Testable Data Extensions must contain a field of data type Email, as well as a Send Relationship. The Send Relationship links a field in the Data Extension to the Subscriber Key or Subscriber ID in the All Subscribers list. This ensures that Subscriber Statues can be maintained for Data Extensions, and enables deduplication based on Subscriber Key or email address.
When sending to a Sendable Data Extension, Marketing Cloud determines the Subscriber Statues based on the Send Relationship: If a Subscriber with the Subscriber Key or Subscriber ID in the linked Data Extension field is found, then the respective Subscriber Status is honored. If no match is found, then a new Subscriber with Status Active gets created.
By default, the Send Relationship checks Subscribers statuses in the All Subscribers list. This means that if a Subscriber unsubscribes from a default Data Extension send, it will be unsubscribed globally for all Data Extension sends. To differentiate between Data Extension unsubscribes, Publication Lists and Suppression Lists can be used. Publication and Suppressions Lists help to manage opt-ins and opt-outs to different categories of Data Extension sends.
To differentiate subscriber statues for different categories of Data Extensions sends, Publication Lists and Suppression Lists can be created. Publication Lists and Suppression Lists help to manage opt-ins and opt-outs when sending to Data Extensions.
When sending emails to a Sendable Data Extension, Publication Lists can be used to allow Subscribers in those lists to opt-out from future sends to this list. If no Publication List is selected at send time, then the All Subscriber list is used and opt-outs are global. Publication Lists therefore make it possible to maintain opt-outs for categories of Data Extension sends.
Subscribers are added to Publication Lists at send time. Publication Lists can also be defined as Public. If a Publication List is Public, then it is visible in the Subscription Center, and Subscribers can opt-out from it. Subscribers can also opt-in to Public Publication Lists, but they will only receive the email if they exist in the Sendable Data Extension.
When sending emails to a Sendable Data Extension, Suppression Lists can be used to exclude Subscribers in those lists from the send. Subscribers contained in Suppression Lists could, for example, be email addresses with a history of SPAM complaints, unsubscribe lists from previous providers or advertisers, email addresses of competitors, and canceled customers.
Subscribers can be added to Suppression Lists via import activities. Suppression Lists can also be defined as Public. If a Suppression List is Public, then it is visible in the Subscription Center, and Subscribers can opt-in from the Subscription Center. If a subscriber clicks the one-click unsubscribe link in an email, then the subscriber is added to the Suppression List but remains on the Subscriber List, Data Extension, or Publication List with status Unsubscribed.
Both Subscriber Lists and Data Extensions can be used to send emails to. However, different lists are used to include or exclude subscribers from email sends.
|Subscriber List||Data Extension|
|Included in Send||Targeted List||Publication List|
|Excluded from Send||Exclusion List||Suppression List|
Suppression Lists differ from exclusion lists, although their filtering logic at send time is the same. While Subscribers in exclusion lists have a subscriber status and may want to continue receiving messages in the future, Suppression Lists are Data Extensions without subscriber status and unique properties. Suppression Lists are not counted in the All Subscriber count and are available when sending to a sendable Data Extensions.
|Exclusion List (Subscriber List)||Suppression List (Data Extension)|
|Filter logic at send time||Filter logic at send time|
|Used with Subscriber Lists||Used with Sendable Data Extensions|
|Subscriber Status||No Subscriber Status|
|Counted in All Subscriber List||Not counted in All Subscriber List|
|May be included in future sends||Always excluded in sends|