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.

Interactive Content data extension files shown in the Data Extensions folder in 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.

Need a refresher on data extensions and primary keys? Check out the module Marketing Cloud Engagement Contact Management.

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 screenshot with callouts for input labels, data attributes, description, field value, and option labels.

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 if a customer’s response is a short answer or paragraph. If utilizing an existing data extension field, review the data field configuration and field length to make sure it works with the format of your response.
Select	Select one option from a dropdown of multiple options.	Helps control responses that may aid in personalization or if adding data into an existing data extension with specific responses. For example, if you ask a customer to choose their favorite color, but don’t have tents in purple, you can limit to tent colors you do have: Red, white, or blue.
Radio	Select one option from a group.	Good option for Yes or No questions.
Checkbox	Select multiple options from a group.	For each checkbox option, you need to add a unique data attribute for each option as a user can select multiple items.
Image single choice	Choose one image in a group of images.	Want to spice up the interactive experience for users? You can change the image based on whether or not a user hovers over the image or clicks the image. Remember to add alt text for all images. For each image choice, be sure to add a helpful field value to identify their response. Perhaps use a number that corresponds to the image's position or use the alt text description of the image.
Image multiple choice	Choose one or more images from a group.	Similar to image single choice, you need to map each image to a separate data attribute for storage.
Button single choice	Choose one button in a group.	A button input may be more user friendly on a mobile device, though be sure the size of the button, color, and font size make them easy to read and select. Suggest using the same text as what is in the button to keep things simple and organized.
Button multiple choice	Choose one or more buttons in a group.	Data is stored in the same way as image multiple choice.
Rating	Select a star rating from a group.	For each star, select a field value to be recorded in the data extension. It may be helpful to label them as 1, 2, and so on, or based on your star ranking, bad, good, neutral, and so on.

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.

Use this Quip template or download the spreadsheet template to track all the details about your form data—whether it's hidden or visible, the input type, data attributes, and more.

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.

¿Necesita ayuda?

Descubrir más