Subscriber-and-list model

The traditional way to store subscriber data in Marketing Cloud has been to use the subscriber-and-list model. This approach is simple, straightforward, and has some nice built-in conveniences.

In this model, Marketing Cloud considers each subscriber to be a complete entity. The email address identifies the subscriber entity, and profile and preference attributes contain the following kinds of data about the subscriber:

• Profile attributes: Contain demographic data about the subscriber. Figure 6-1 shows the profile attributes that exist in your account by default.
• Preference attributes: Contain yes/no choices that subscribers communicate to you about how they want to hear from you. The only preference attribute delivered by default is called HTML Email. When subscribers select the check box next to this preference, they receive your emails in beautiful, full-color HTML. If they deselect this check box, they receive a text-only version of your email.

One of the little conveniences built into the subscriber-and-list model is Profile Center. For each subscriber, Marketing Cloud automatically generates a web page that you can link to in the footer of your email. When subscribers click the link, they go to a form where they can update their attribute values and change the lists to which they are subscribed.

Figure 6-2 shows an example of a profile center. It's an easy way to get to some of the subscriber data you've been after while making subscribers feel listened to and in control.

Your Marketing Cloud account comes with basic profile and preference attributes already created. You can choose to create a few additional profile and preference attributes to store data that isn't part of the basic starter set.

It wouldn't make sense to use a powerful piece of online marketing software to communicate to only one subscriber at a time, so you use lists to group many subscribers so you can send to them all at once. Marketing Cloud automatically includes all your subscribers on the big All Subscribers list, and then you create other lists, each one of which containing a subset of your All Subscribers list. Often, a list corresponds to a message type. For example, you might have one list for your monthly newsletter and another for your weekly flier. A subscriber can exist in any number of lists.

The subscriber-and-list model is simple to understand and adequate as long as each subscriber has no more than one piece of relatively static data for each attribute. For example, if all you have is the subscriber's email address, first name, and last name, the fields on the subscriber entity are fine. However, when you begin capturing things such as purchase history, where each subscriber could have a different number of past purchases and the information could be changing every day, using just the subscriber attributes becomes unwieldy and inefficient.

Relational data model with data extensions

As the Marketing Cloud software continued to evolve, the subscriber-and-list model started falling short of the growing needs of increasingly customized and automated online marketing campaigns. Marketers needed the power of a tool that was being widely used in other high-tech fields: the relational database.

To understand a relational database, think of your wallet. The wallet as a whole is yours, but the data within that wallet resides in separate locations:

• Your driver's license has your name, contact information, and demographics.
• Your credit or debit card has your name and information you use to make purchases.
• Your health insurance card has your name and information you use to get health care.

Each of these items serves a different purpose, so it makes sense to store the data associated with them separately, but they are also all tied together by a piece of data that is unique to you — your name. Using this name, you can figure out that the different cards go together and belong in the same person's wallet.

In relational database parlance, the different data storage locations (the cards in the preceding example) are called tables. In Marketing Cloud terminology, though, a table is called a data extension. In both cases, the unique identifier that ties the data together (your name in the example) is called a primary key.

To put this concept in practical terms, here is an example of data an online retailer wants to store about a customer. The retailer creates a Customers table with the following fields:

• Customer ID (primary key)
• Salutation
• First Name
• Last Name
• Address
• Address 2
• City
• State/Province
• ZIP/Postal Code
• Country
• Phone Number
• Email Address

After a customer makes a purchase, the retailer will have information that doesn't fit in the Customers table. So she creates a Shipping table with the following fields:

• Customer ID
• Order ID (primary key)
• Ship To Name
• Address
• Address 2
• City
• State/Province
• ZIP/Postal Code
• Country
• Phone Number

Now you might be thinking to yourself, “Wait a second. Customer ID was supposed to be the primary key.” But the value of a primary key has to be unique within the table so it can definitively identify a single row in that table. Because a single customer could make more than one purchase, the same Customer ID could appear on many rows.

So you need a different value, the Order ID, to be the primary key of this particular table and to uniquely identify each row. The Customer ID is still available on each row, though, to connect the Shipping table with the Customers table. Using the Customer ID, you can get to the name and email address of the customer who placed the order.

Because an order may contain several items all being shipped to the same address, next the retailer needs an Orders table to identify the item or items to be shipped:

• Order ID
• Product ID
• Order Date
• Quantity

Note that this table has no single primary key field of its own but it associates the primary keys of other tables together. You might use a table like this to send a “Thank you for your order!” email at the end of each day. You could write a database query to collect all the information related to today's orders by starting from this table, using the Order ID to hop to the Shipping table, and then finding the Customer ID to hop to the Customers table.

As you can see in Figure 6-3, several files can be linked to build a useful relational data model.

If your company has rules about how long you must keep data or how quickly you should delete it, you can set a data retention policy on a data extension to delete the content in the data extension automatically. You can choose among the following options for removing data:

• Individual records: When you delete individual records, each time the system cleans out the old data, it deletes the rows in the table that have reached the required age.
• All records: Deleting all records wipes out all the data in the data extension when any of the records has reached the required age. You usually use this option for data extensions in which all the content is the same age.
• All records and data extension: Choosing this option removes the entire data extension, data and all.

You also have options when it comes to setting up the date to delete the data extension content. You can choose a specific date or enter a number of days. When you create the data extension, the system starts counting the days, and after that date or the number of days you chose elapses, it deletes the content according to your selection. You can tell the system to restart the count of days each time you import into the data extension, if you prefer.

Using data extensions to contain your subscriber data is both more difficult and more powerful than using the subscriber-and-list approach. Whereas the purpose of subscriber attributes and lists is clearly defined before you even open your Marketing Cloud account, a data extension is a blank slate that can be configured to any purpose. Some data extensions contain the data that would otherwise be held in attributes; others serve the same purpose as lists, defining which subscribers receive a message.

Adopting a relational data model has several benefits:

• Easier maintenance of individual records or types of data within a larger set
• Easier accommodation of new data — just add a new table
• Reduced storage needs by eliminating duplicate data
• Faster data processing at send time

Which data model will work for you?

Now that you have an understanding of the differences between the data structures you can employ, it's up to you to decide which best fits your needs. Consider the following questions when choosing whether to use the subscriber-and-list model or the relational data model:

• How confident are you with relational database concepts? Do you have any SQL knowledge? Can you map out data relationships, and then manipulate your source data to support those relationships? Do you feel comfortable with complex data relationships? If you aren't comfortable with these concepts yet, you might want to start by storing your data in simple subscriber attributes.
• Are you going to be pulling information from a separate database to refresh Marketing Cloud data on a regular basis? Can you configure an automated synchronization of data between your primary database and Salesforce Marketing Cloud? If so, a relational data approach is not required but will make things easier.
• Do you plan to implement Journey Builder (see Chapter 10)? If so, you'll be better served by using a relational model with Journey Builder Decisions.
• How large is your data set, and how often will it be updated? If the data set is large and has components that are updated frequently, a relational model is far more efficient.

Even if you start with subscriber attributes, you can move to a relational data model later, and you probably will. The relational model makes it possible to use the coolest functionality in Marketing Cloud.

Setting up a subscriber-and-list data model

If you decide to start by using the subscriber-and-list model to store your subscriber data, you have a short to-do list to get up and running. Start in the Email app by choosing Email from the Email Studio category on the app switcher.

Setting up a relational data model

If you choose to dive right into a relational data model, you have more work to get things started. Much of what you need to do — before you begin any of the following procedures — involves planning the design of the database. When you're ready to implement your design, start in the Email app by choosing Email from the Email Studio category on the app switcher.

Setting up a sendable data extensions

When you use the relational data model, you create sendable data extensions instead of lists of subscribers. The procedure for creating a sendable data extension is the same as the one for creating any other kind of data extension. Just make sure to select the Is Sendable? check box on the Properties tab of the Create New Data Extension window, shown in Figure 6-4, when you get to Step 4.

Importing to subscriber attributes

This section is relevant if you've decided to start by using the subscriber-and-list model. If you'll be using a relational data model instead, you can skip this section and proceed to the next one, “Importing to data extensions.”

Because the subscriber attribute model contains all necessary data in one big All Subscribers list, preparing the file to populate this table is straightforward.

You put the data you want to import into a single file, where each subscriber's data is a separate line in the file and each piece of data is delimited by a character, usually a comma or a tab. The file is actually a text file, but you might be able to open it in a spreadsheet program to help you review the content more easily. If you're exporting data from a different business system, that system might be able to generate a properly delimited file for you.

Marketing Cloud gets confused if the character you choose as a delimiter also appears in one of the fields. For example, if you have a comma-delimited file and a comma appears in the middle of an address, Marketing Cloud will think that the comma indicates the end of the address field. If the content of your data includes the delimiter character, choose a different character as the delimiter. Figure 6-6 shows the different delimiters you can choose and the field where you can enter a different delimiter.

Use these steps to import your data:

1. In the Email app, pause your mouse pointer over the Subscribers menu in the toolbar, and choose Lists from the menu that appears.

2. In the list, find the list you want to import to, and click the import icon in the Actions section, on the right side of the row.

   The import icon is shown in the margin.

3. Complete the steps in the Import Wizard that appears.

   People have been importing to Marketing Cloud lists for a long time, so this wizard is a useful and time-tested aid to get your content into the system.

Importing to data extensions

This section is relevant if you've decided to use a relational data model. If you'll be using the subscriber-and-list model, see the preceding section, “Importing to subscriber attributes.”

If you're using a relational data model, you must import more than one file of data; you import one file for each data extension. Other than that, the import process for data extensions is similar to the import process for subscriber attributes.

Use these steps to import your data:

1. In the Email app, pause your mouse pointer over the Subscribers menu in the toolbar, and choose Data Extensions from the menu that appears.
2. In the list, find the list you want to import to, and click the import icon (shown in the margin) in the Actions section, on the right side of the row.
3. Complete the Import Wizard that appears.

Utilizing a CRM integration

If your company uses a customer relationship management (CRM) system, it may be the single richest source of customer data that your Marketing Cloud campaigns can use. Obviously, if you use the Salesforce CRM, you have a prime opportunity to connect the two systems so that customer data can flow directly from one into the other.

Integrating your Marketing Cloud account with your CRM system has several benefits, such as the following:

• Leverage knowledge of individual leads
• Enable your sales team to reach out to individual leads but enforce your branding standards on their communication
• Maintain customer data in a centralized location so you don't have to manage updates in two systems
• Provide a more in-depth view of customer interactions within the CRM environment

The process to integrate your account may require additional configuration, but, if the company does a good job of keeping your customer information complete and current in your CRM system, you'll be glad to have access to it through Marketing Cloud.