You are here:
Omnichannel Considerations and Best Practices
There are important aspects and trade-offs to consider before implementing this solution. This guide is just one example of how to enable an omnichannel experience for your customers. For example, instead of separate single-channel journeys, users can create seamless customer experiences by using Data Cloud to orchestrate one journey with all Email, SMS, and MobilePush activities together.
Potential Risks of Using the Unified Individual in This Solution
This solution assumes that you haven’t implemented Marketing Cloud Engagement to create omnichannel contacts in Engagement for use across all Email, SMS, and MobilePush channels. This guide outlines how you can create Identity Resolution rules in Data Cloud to relate separate Individuals—Email, SMS, and MobilePush SubscriberKeys—to a single representation of a person—a Unified Individual.
Generally, we recommend using the Individual profile as much as possible. We recommend limiting the use of Unified Individuals in campaigns to promotional use cases but not transactional or event-triggered use cases.
Messaging the Wrong Person
Consider Unified Individuals as dynamic, and treat them with caution because they could change. Unified Individuals are based on the rules you set within Identity Resolution and the data stored within your Data Cloud instance. Based on newly imported data from your external data sources or changes that you make in the Identity Resolution ruleset, the Identity Resolution process can add or remove Individual profiles and their associated contact point addresses from a given Unified Individual. Therefore, it’s possible that you could be sending messages to the wrong person.
Example: Data Cloud can have a Unified Individual for the person John Smith. Based on your Identity Resolution rules, the Unified Profile for John Smith is initially made up of three different Individuals (SubscriberKeys from Marketing Cloud Engagement): John.Smith.Email, John.Smith.SMS, and John.Smith.MobilePush. Cumulus activates the Unified Individual of John Smith to use in Journey Builder.
| Sourced from Unified Individual Profile of John Smith | |||||
|---|---|---|---|---|---|
| Individual ID | EmailAddress | FullName | PhoneNumber | Country | MobilePushSubscriberKey |
| John.Smith.Email | john.smith@example.com | John Smith | 555-123-1234 | United States | John.Smith.MobilePush |
| Selected from the Individual profile of John.Smith.Email | Selected from the Individual profile of John.Smith.SMS | Selected from the Individual profile of John.Smith.MobilePush | |||
Midway through the journey, Identity Resolution receives new information that results in the determination that the Individual John.Smith.MobilePush doesn’t belong to the Unified Individual for John Smith. In fact, this Individual profile belongs to a separate person who has the same name, Unified Individual John Smith, Sr. As a result, the journey could have sent emails and SMS messages to John Smith and sent push notifications with potentially sensitive information to John Smith, Sr.
Selecting Opted Out Individuals or Contact Points
When Data Cloud segments on the Unified Individual, it qualifies the Unified Individuals that have at least one Individual that meets the criteria.
When activating on the Unified Individual, Data Cloud uses your source order prioritizations and engagement histories to select the contact points to activate, regardless of their consent or preference type. Customers are solely responsible for activating contact points and obtaining consent to send messages to any contact points.
For example, the Unified Individual for John Smith can have two Individuals related to it, each imported from separate data sources and each with their own associated SMS phone numbers: John.Smith.1 from System A and John.Smith.2 from System B. If Cumulus segments on the Unified Individual with criteria of whether the Unified Individual has opted in for SMS messages, the Unified Individual for John Smith qualifies for the audience, even if John.Smith.A had opted in to SMS messaging and John.Smith.B had opted out. As part of activation, Data Cloud could select the opted-out phone number from John.Smith.B if Cumulus had selected to prioritize SMS contact points that came from source system System B.
Using the Wrong Context of a Person
When Data Cloud segments on the Unified Individual, it qualifies Unified Individuals that have at least one Individual that meets the criteria.
When activating on the Unified Individual, Data Cloud selects a channel’s contact point from one of the Individuals within the Unified Individual’s profile. These contact points can come from various systems, brands, divisions, or subsidiaries within your company. Then, Data Cloud selects attribute values based on the source system determined by the Reconciliation Rules set for your company.
This action can lead to a personalized customer experience that uses the wrong customer context, because the customer might be getting targeted content or promotions on a contact point that they didn’t expect.
The marketing team in charge of Brand A creates a segment to find Unified Individuals who are likely to upgrade their home insurance. As part of activation, Data Cloud selects the email address that is most engaged: john.smith@example3.com.
However, these brands and addresses aren’t contextually related. When Cumulus sends a promotion for the customer to upgrade their existing mortgage, it goes to the email address used for the stock-trading app instead of the email address associated with his insurance.
Each brand within Cumulus has a different source data system, and each one imports data to Data Cloud. The person John Smith signed up for the Cumulus email newsletter with Brand A of the company–the insurance brand. Separately, John Smith later signed up with Brand B–the credit card brand. Finally, John Smith eventually signed up on Cumulus mobile app with Brand C–the stock-trading brand.
The marketing team in charge of Brand A creates a segment to find Unified Individuals who are likely to upgrade their home insurance. As part of this activation, the team selects to source priority for Email, SMS, and MobilePush contact points so that they come first from system A, then system B, and finally system C.
The resulting data extension contains John’s email from system A (insurance brand), his phone number from system B (credit card brand), and the MobilePush Key from System C (the stock-trading app).
However, these brands and addresses aren’t contextually related. When Cumulus sends a promotion for the customer to upgrade their existing mortgage with them, it makes sense to use the email address that is used by the insurance brand. But it wouldn’t be appropriate to use the phone number associated with the credit card brand or the app associated with the stock-trading brand.
Consent Behaviors for Each Channel
Marketing Cloud Engagement has a variety of capabilities that you may use to manage customer consent and preferences.
In this solution, because the journey is being orchestrated using MobilePush Key as the SubscriberKey, the consent status for the email address john.smith@example.com is checked against the record for John.Smith.MobilePush.
SMS Messages: The native consent statuses in Marketing Cloud Engagement for SMS sending are stored at the phone number level (and keyword) and not at the SubscriberKey level (unlike Email). In this solution, the consent status for phone 555-123-1234 is checked regardless of the orchestrating SubscriberKey. Note: If you configure the SMS activity to Subscribe all contacts to a keyword, native consent is overridden and the contact is opted in.
Email Activities Only
- For each Email activity in the journey, associate a suppression list that prevents sends to the given email address. We recommend this option only for journeys or lists with less than 200,000 members. Before sending an email, Journey Builder checks the email address suppression status associated with the list.
- For each Email Activity in the journey, associate a publication list. Before sending an email, Journey Builder checks the publication status associated with the contact to see if they’re subscribed.
Email, SMS, and MobilePush Activities
- Use exit criteria in your journeys to monitor attributes from the Contact Model that you know are current to represent the person’s consent or preferences. Journey Builder monitors these values for the duration of the journey.
- Before using the activated data extension for journey entry, run an automation in Automation Studio to validate the consent or preference status of each contact or contact point against a separate data extension. Invalid contacts are removed before they enter the journey.
- As part of your journey Entry Source, configure filter criteria to exclude contacts from entering the journey. Invalid contacts are removed before they enter the journey.
Alternative Omnichannel Orchestration Approach
Instead of a journey with all Email, SMS, and MobilePush activities together, create a similar customer experience by using Data Cloud to filter and orchestrate a series of separate single-channel journeys.
Default Address Behaviors
This solution kit recommends that you update the Default Send Addresses within Journey Builder Settings to override the MobilePush Key’s default Email and SMS addresses to instead send to the EmailAddress and PhoneNumber stored within the activated data extension. This practice can cause downstream updates in the Marketing Cloud Engagement and Data Cloud systems.
Updates to MobilePush Key (MobilePush SubscriberKey) Contact Record
The Email and SMS addresses used in the send are added to the MobilePush Key (MobilePush SubscriberKey) Contact record in Engagement, resulting in a SubscriberKey that has both an Email address and SMS contact point address. Then, this information syncs to Data Cloud and is reflected on the Individual record of the MobilePush SubscriberKey, resulting in an Individual that now has both an Email and SMS contact point address.
This action can cause conflicting updates. Engagement might be updating the Contact record with new default Email and SMS contact point addresses while Data Cloud is activating a new audience using different Email and SMS contact point addresses for that same contact.
Reporting and Troubleshooting
- All send and journey reporting is based on the SubscriberKey being used for the journey. For this solution kit, the value for MobilePush Key acts as the SubscriberKey for the journey.
- Depending on your reporting strategy, you might need additional processes to harmonize this value back to the Email or SMS SubscriberKey or contact points that the journey’s sends were based on.
- Journeys that use this solution can’t use activations that refresh on a scheduled basis. Refreshes overwrite the required send relationship setting that relates the MobilePush Key attribute to a Subscriber Key. As such, Journey Builder defaults all orchestration, personalization, and sending lookups based on the value of the MobilePush Key (representing the MobilePush SubscriberKey).
