Consider Your Data Requirements
Learning Objectives
After completing this unit, you’ll be able to:
- Identify how Interactive Email Forms store data.
- Define your form’s data requirements.
Data Considerations
Data is the answer to every marketing question. OK maybe not every question, but close to it! As we mentioned, customers aren’t always eager to share details about themselves, especially if it’s time consuming, so be sure to carefully craft your form to be concise, user friendly, and most importantly, capture the data you need.
Data Storage
When you create your email form, you select a response capture method. Which is a fancy way of saying you need to choose if your data is stored in a new or existing data extension. But before we get into data extension details, let’s review two important aspects of your form—the questions and the answers.
Visible and Hidden Fields (Questions)
The questions you want to answer can be seen or unseen by that user. We refer to these as visible and hidden fields. Visible fields (called inputs) are the questions that a subscriber sees in your email. Hidden fields are used to pass information to your data extension that you don’t want to be seen or changed by your customer (such as email address, subscriber key, order number, or product ID).
Data Attributes and Field Values (Answers)
Now the answers to your questions need to be stored somewhere. In order for Marketing Cloud Engagement to know where to store the information and what to store in the data extension, every input's answer needs to be mapped to a data extension field. In Interactive Email Forms this is called a data attribute (the where). Another important aspect? In some form types, you also need to determine a field value for an answer (the what). Still trying to piece this together? Don’t worry, we cover this more in a bit.
For now, let’s review those data extension options in more detail.
Create a New Data Extension
The easiest option is to create and map your data extension directly within the email form content block in Content Builder. Data extensions created this way are saved in the Interactive Content folder under the top level folder, Data Extensions, found in either Email Studio or Contact Builder.
As you add new inputs (or questions) into your form, new columns are created in the data extension to store that data—automatically. Pretty easy, right?
Use an Existing Data Extension
Sometimes you might want to use an existing data extension to store your form data. To do this, simply select an existing data extension as your response capture method when building your email form. Be sure to carefully review the data extension’s configuration because it impacts how your form updates the data extension. For example, if the existing data extension uses a primary key, the system attempts to update an existing record for that primary key (called an upsert). If the primary key is not found in the existing data, the system generates a unique ID for the record and adds a new row to the data extension. If no primary key is defined in your original data extension, the system simply adds a new row upon each form submission.
Required fields are another consideration if using an existing data extension. Why? All required fields in the existing data extension need to be accounted for in your email form. For example, you might want to update a master customer data extension with the data you receive from a progressive profile email. In that case, each required field needs to be mapped to the email form. If any field is missing, the email form fails. To make sure that doesn’t happen, review each existing required field and determine if the field should be visible or hidden to an end user.
Capturing and Mapping Data
Now that you know your storage options, let’s review how to map your answers to a storage location. Here is an example of an email form block in Content Builder. Let’s review the key data components.
-
Input Label (1): This is the question you want the user to answer.
-
Data Attribute (2): The name of the data extension field where the answer is stored. If it is a new attribute (data extension field), choose a name and attribute length.
-
Description (3): Add text in the description if the user needs more information about what you are asking. For example, if you are asking “What is your birthday?” add a description of: “Provide as MM/DD/YY.”
-
Field Value (4): The data that is recorded in the data extension when a subscriber selects an option.
-
Option Label (5): What the user sees on screen and selects in the email. This can be different from what is stored in the field value.
Each input type (or question type) has a different user experience and some data considerations. Let’s review.
Input Type |
Description |
Data Considerations |
---|---|---|
Text |
Give an open response. |
|
Select |
Select one option from a dropdown of multiple options. |
|
Radio |
Select one option from a group. |
|
Checkbox |
Select multiple options from a group. |
|
Image single choice |
Choose one image in a group of images. |
|
Image multiple choice |
Choose one or more images from a group. |
|
Button single choice |
Choose one button in a group. |
|
Button multiple choice |
Choose one or more buttons in a group. |
|
Rating |
Select a star rating from a group. |
|
Data Requirements
Now that you have a basic understanding of data storage and input options, it’s time to draft your form and data requirements. To help you do that, consider these questions.
What data do you want to collect?
- What questions are required or just nice to have?
- Do you ask for personal, identifiable data? (Avoid if possible.)
- Does your question need additional explanation through a description? (Add clear instructions for each question.)
- If you want a customer to rate something (like a new product or service), what is your rating system? For example, is it a five-star scale where one star means poor and five stars means excellent?
- What is the format of your question?
- Open ended or do you want a specific response?
- Is it a date response or simply text?
- Do you want the user to select multiple options?
- What do you want to know but don’t want to ask a customer directly? (Remember, we call these hidden fields).
How do you plan to use the data?
- Need for personalization?
- If so, do you need to add the data to an existing data extension that stores your customer info?
- What are the data requirements for that data extension?
- Use in a new or existing journey?
- Does the data need to be added to an existing Journey Builder entry source data extension?
- For use in a one-time event, like a contest?
- Create a case in Service Cloud or create a lead in Sales Cloud?
- How will you get your data into Sales or Service Cloud? Using a Journey Builder integrated activity or manually exporting and importing the data?
- Need it for an external system?
- If so, how are you going to export the data out of Marketing Cloud Engagement? Any formatting requirements?
Email forms were designed to gather data about customers, so don’t skip over the planning step. It’s important to make sure you can use the data you are collecting and aren’t creating any data hygiene issues.
Now with a clear picture of your form’s data requirements, head to the next unit to see how CloudPages and Content Builder bring your email forms to life.
Resources
-
Spreadsheet Template: Interactive Email Form Block_Data Requirements
-
Quip Template: Interactive Email Form Block: Data Requirements
-
Trailhead: Marketing Cloud Engagement Contact Management