Subscriber Data Management: 18%

 See the bootcamp in Youtube

Trailhead: Marketing Cloud Contact Management

Marketing Cloud Data Management


Marketing Cloud Security


Personalized Email Marketing


Apuntes:


Contact Builder is a Marketing Cloud app which lets you access, manage, organize, link, and view contact data from all Marketing Cloud applications and channels. Is useful for decision splits and when you need to move contacts through specific paths in a journey, or as a way to inject a contact into a journey itself. 


Contact Builder has several tools to help manage contact data for use in building 1:1 relationships:


Contacts Configuration Determine how Contact Builder processes imported contact information.

Data Designer Define information about your contacts and relate that data directly to the contact record by linking data extensions.

Data Extensions Create and manage the data extensions that hold contact information.

Imports. Create the processes that move contact information into your data extensions.

Data Sources Visualize where your contact data originates and assign attributes to those sources.


A contact is a person you send messages to through any marketing channel. Typically appears in the All Contacts section, but a contact record can also appear in other locations.


A subscriber is a person who opted to receive communications or belongs to a particular channel. Lives in the individual studios. Can be imported or created manually and are stored in data extensions.


Keep in mind that all subscribers are contacts, but not all contacts are subscribers. With email, a subscriber is somebody you sent emails to, so a subscriber in Email Studio will always be a contact. You can have contacts whom you’ve never sent to who do appear in All Contacts. For example, contacts synced from Sales or Service Clouds or imported via a REST API request appear in All Contacts but not All Subscribers. A subscriber is only added to All Subscribers after something is sent to them. You might send the contact mobile messages but not email messages, so the contact could be a mobile subscriber, and not an email subscriber.


Contact Builder works with other Marketing Cloud applications such as Journey Builder, MobileConnect, and MobilePush. Contact Builder’s relationship with Email Studio is more complicated. Data in Email Studio shows up in Contact Builder, but data in Contact Builder does not show up in Email Studio. In other words, a subscriber in Email Studio will appear in Contact Builder under the All Contacts section, but a contact in Contact Builder won’t automatically appear in Email Studio.


A contact record in Contact Builder provides a single view of a customer and displays all their interactions with your brand. All of the associated addresses, subscriptions, and tracking information associated with activities and journeys relate back to that single contact record.


With the contact record, you can view important details about a contact, such as: 


Past interactions, activities, and journeys.

Relationships.

Subscription channels.

Email address and mobile number.


This single view of the customer is what allows you to find the mobile number necessary to send SMS messages via MobileConnect, the email address to send email messages via Email Studio, and the mobile device identification used for sending push messages via MobilePush.


Contact Key

Is a unique identifier that you assign to a contact. If a subscriber is sent an email and the contact wants to be on mobile, the contact is added to the mobile channel by the Contact Key. Identifies a contact within an account and ties together the contact, channels, and the relationship. The Contact Key is the same no matter what channel is used to send messages. 


The Contact Key is what allows you to connect contacts in multiple channels. Let’s say you have a contact in Email Studio that you identify using their email address, and in Mobile Studio you use their mobile number. Without the Contact Key, it would be difficult for Marketing Cloud to know to connect the contact, since the contact has two different identifiers. Marketing Cloud will process the information as two different contacts in Contact Builder. Make sure you are consistent across all channels when assigning a Contact Key to a contact. 


Contact ID

The Contact ID is a number Salesforce uses to uniquely identify a contact on the backend. Salesforce uses the Contact ID to identify a contact in various channels.


Subscriber Key

In Email Studio, contacts are identified by the Subscriber Key, which becomes the Contact Key in Contact Builder. The Subscriber Key is the primary key for your subscribers and allows you to identify subscribers with a value that you choose. Use a Subscriber Key to:


    - Maintain multiple sets of subscriber attributes for a single email address. For example, if a     family shares an email address, you can use a Subscriber Key to uniquely identify each            member of the family.

    - Include a single email address multiple times on a list. For example, send a separate                 message for each car a subscriber owns in a single send.


Deciding on a Subscriber Key is a crucial business decision that must be kept consistent throughout your entire Marketing Cloud operation. Be sure to establish the Subscriber Key with every data extension created through the send relationship. The Subscriber Key must be present in every sendable data extension.


AttributesRepresent a single piece of information about a contact.

A contact can contain two types of attributes:

    - Profile attributes describe who the contact is. Some of this data is provided by the subscriber, such as gender, state, or interest (do they like hiking or running?).

    - Behavioral attributes describe what the contact has done. For example, a contact indicates some related interests or clicks links when reading a newsletter.


Attribute Groups

Are data sources that are logically grouped together, and they allow you to organize data and configure relationships in Contact Builder. Let’s say you’re a retailer and you need to build a journey that sends an email to people who haven't made a purchase while they were in a journey. Usually, you’d have two different tables of contact data. You’re going to have one table that contains all your customers, and another table that contains all the purchases. An attribute group connects these two tables to each other based on a particular field, such as Purchase History.


Populations

Are used to categorize distinct subgroups of contacts. Think of a population as the subset of the master list of people who could enter a journey. Let’s say you work for a car transportation company and you have one master table of contacts, which includes both riders and drivers. You can create two different populations: one population for the drivers, and another for the riders, since separate marketing efforts and data structures are required for each group or population. 


If you’re using the most up-to-date Journey Builder functionality, you won’t need to use populations most of the time. Instead, it's best to save populations for specific use cases where you need to create complex queries, such as if your account uses field-level encryption or when you’re using API Entry Sources in Journey Builder.


Link Attribute Groups and Populations using the Contact Key value. Don't link using an email address field when the Contact Key or Subscriber Key value is available. If you must create a link using the email address, create a text attribute containing the email address, and link using that value. Use populations to create distinct subgroups of your contacts, then segment contact records from there. For example, a doctor's office can create separate populations for staff, patients, and vendors.


Data Retention

Marketing Cloud is able to handle large amounts of data, but everything runs more efficiently when you configure appropriate retention limits on data extensions. With retention settings, you can select who can see what actions are available, set the sharing window, and select which business units have access to shared data extensions. Consider how long you need to keep your data and configure the retention policy settings when creating the data extension. You can apply a data retention policy to a data extension with less than 100 million records from Contact Builder, but it’s best to plan ahead.


Data Retention Options

When you configure your data retention settings, it’s important to think about both the data and the use case for that data. Marketing Cloud is not designed to be a universal storage vehicle for all of your customer information, so you should be strategic in how you set up your data models. For example, if the data needs to be continually refreshed and an external system has more up-to-date information, you should set up your data model to re-import data before each send instead of preserving historical records in Marketing Cloud. 


Data that passes the retention limits will be permanently deleted, keeping the record counts in line with your ongoing personalization and segmentation needs. By default, the data extension retention policy deletes unused data extensions after 6 months. The deletion process runs nightly.


Delete Options:

Individual Records. When this option is selected, the data extension is retained, but the individual records inside the data extension are deleted.

All Records. When this option is selected, the data extension is retained, but all records inside the data extension are deleted.

All Records and Data Extensions. When this option is selected, the entire data extension and the records inside the data extension are deleted.

Period Options:

After. Enter the number of days after the data extension was created to wait before deleting.

Reset period on import. To extend the retention date following a new import.

On. Select a specific date to delete.

Using data retention settings in combination with the proper import action (add, update, overwrite, etc.) helps ensure your marketing automations remain useful and up-to-date.


Contact Delete Process

When possible, do not delete contacts. When you delete a contact, you are losing all of the contact’s tracking data and everything about the contact. If you want to remove unengaged subscribers, unsubscribe the contacts from individual channels rather than deleting them. If you want to remove unengaged subscribers, consider moving them to a different journey or data extension. You can also use Einstein Engagement Scoring to promote better engagement.


You can manually delete individual contacts and you can delete lists of contacts, but the Contact Delete feature must be enabled.


We recommend that you keep a log of the contacts deleted to prevent reintroduction. Also, be sure to back up the contact’s preferences so if you ever re-import the contact, you know the channels the contact subscribed and unsubscribed to, which is important for CAN-SPAM compliance. You can delete contacts related to Email Studio from your Marketing Cloud account, but this deletion does not totally remove the contact’s information from Marketing Cloud. Salesforce needs to retain this information to ensure that the contact’s email address does not receive messages from which they unsubscribed.


There is a 14-day default period, which is customizable, where Contact Builder suppresses contact information from showing in channel applications. You can change the suppression if you need to get people out faster. It will only delete subscribers from sendable data extensions, so if you have subscriber data on non-sendable data extensions, you're going to have to find the contact and delete it. We recommend keep the suppression period as short as possible.


Options to Delete a Contact:


Contact Deletion using API

You can delete contacts using Contact ID or Contact Key or List. Refer to the documentation on the REST APIs using the links provided.

Contact Deletion in UI

Select a contact from All Contacts and click Delete.

Contacts have to be set up on a sendable data extension or in a mobile list in order to delete them. You select one of those sources to delete and everyone on the list will be deleted and all the associated contact data will be removed.


Order of Operations When Deleting

When you delete contacts, the contacts are moved from the suppression state to the deletion phase. This creates a hard deletion of the contact from the account and from all sendable data extensions. This cannot be reversed. While the contacts are suppressed, you cannot see specific information about the contacts, you cannot send to them, and you cannot import them. The contacts are removed from queries and are finally deleted. You have to remove subscriber data from non-sendable data extensions on your own.


Once the deletion is completed, you can add the contacts back through data sources. If it's a user lead or if a contact is injected into a journey, the contact is also added to the All Contacts section. 


Sendlog Implications

The sendlog keeps aggregate tracking data. Let's say you sent to 10 people, then deleted one. Although there is no way to see that you sent to the particular person that was deleted, you'll still see that you sent to 10 people. So you will still see the aggregate data, but you cannot see the data of the contact you deleted.


Foreign key: Marketing Cloud organizes data using a relational database, and in this type of structure, foreign keys are used to connect data between two unique tables or sources. For example, you might find CustomerID on a customer data extension, and PurchaserID on a POS data source. They may have different names, but these fields are the same customer. Therefore these fields become the foreign keys that connect these two pieces of data.

Contact key: The contact key is a unique value you assign to identify a contact within your Marketing Cloud account. (You may know it as a subscriber key in Email Studio.)

Primary key: A Marketing Cloud primary key is a unique field on a data extension that identifies a specific and, well unique, data point. Often this is the contact key, but it can be something unique to that data. For example, in a product catalog data extension, SKU can be a unique identifier (and therefore, a primary key).


Data sources: This is where you identify and organize all your data sources, including synchronized and custom sources.

Data extensions: This is where you build the placeholders for your data. You can also create data extensions in Email Studio.

Attribute group: This is a way of organizing your data model. Within an attribute group you have attribute sets or data extensions, and the attributes are the fields within a data extension.

Populations: These can be used to differentiate between groups of people or data models that have unique attributes or identifiers. Populations are beneficial for a company that has a different model or structure for communicating with customers vs. employees.





Questions:


1. A marketing cloud admin has created some profile attributes but

doesn't want the customer to see them in the profile center. How should

the attributes be configured? (taken from Trailhead)


A. Mark the attribute as hidden

B. Mark the attribute as read-only

C. Mark the attribute as a profile attribute

D. Mark the attribute as a preference center attribute


2. Astronomical Astros has set up an abandoned cart journey. They would li ke to

create a separate path for customers who have more than 5 items in their carts.

However, when the marketing team tries to create the decision split, they cannot

locate the data. What should they trouble-shoot to try to fix the problem?


A. Ensure that the data extension is sendable.

B. Check that the data is set up as a preference attribute.

C. Make sure the data extension is linked to the contact in Data Designer.

D. Make sure the data is a field in Salesforce.


3. Cloudy's Characters' Marketing Cloud instance is starting to hit data storage

limits. They have come to you with budgetary concerns about purchasing more

storage. You've investigated and have found that there is 5 years of data being

stored on the data extensions that is no longer necessary. What would you

suggest? Choose 2.


A. Configure data retention policies on data extensions to store data for only 6 months.

B. Move data extensions that are not being used for marketing purposes to another storage system, such as a data warehouse or CRM.

C. Delete all your data extensions older than 1 year.

D. Move all your data to lists as it uses less storage.




Comentarios

Entradas más populares de este blog