The amazing journey of creating Journeys

Journey Builder is probably the flagship feature of Marketing Cloud, it helps to automate process, design flows for specific business scenarios and accompany the customers throughout their life cycle with the brand. But moreover, it integrates the different Clouds of Salesforce like Marketing Cloud with Sales Cloud or Service Cloud, being able to interact in ‘real-time’ with the CRM.

Automatizing campaigns and becoming omnichannel compliance

When entering for the first time in the Journey Builder feature in Marketing Cloud, we see there are plenty of activities we can play with to interact with our customers with just dragging-and-dropping it to the canvas and a bit of configuration.

Before starting to put all the activities into the canvas, we have to think about the journey we want to design. Sometimes it is better to keep it simple than trying to create endless journeys with too many activities. Indeed, the best practice is to start with something simple and adding more activities in the new versions of the journeys once we see it is working as expected or it needs a bit of fine-tuning.

For a better understanding, the activities are differentiated by color:

Entry source activities

In green, depending on where is the audience of the journey coming from we need to use the right Entry Source:

  • Data Extension: when the data is coming from a Sendable Data Extension in Marketing Cloud.
  • API Event: when the audience is coming from a third system that is not integrated with Marketing Cloud (the more typical use case is the abandonment cart, triggered from the eCommerce).
  • CloudPages: when a customer submits a form in landing page created with CloudPages, it automatically enters in the journey.
  • Google Analytics 360: for audiences created in Google Analytics (GA360 integration required).
  • Salesforce Data: for customers coming directly from Sales Cloud or Service Cloud (Marketing Cloud Connector required)
  • Event: for triggered actions based on customer attributes (e.g. anniversary journey)

Channel activities

In blue, we have many channels where the communication can be sent from. Without entering into the technical details of each one, they are organized in three blocks:

  • Messages: includes the default channels managed in Marketing Cloud (email, SMS and push).
  • Advertising: for activities related to the Advertising Studio module.
  • Customer Updates: to update one or more fields of a Data Extension.

Flow control activities

In orange, the flow control activities, that drive the customers within the journey through the different paths:

  • Wait activities: to provide an evaluation period to the customer to interact with the communications, or based on specific attributes.
  • Split activities: for driving the customers to a different path based on an attribute in a Data Extension (Decision Split), randomly, for example, to create control groups or A,B,…,n testing purposes based on a percentage of the audience (Random Split) or based on the interaction of the customer with the email – opens, clicks or bounces (Engagement Split).
  • Join: after splitting the paths, we can join them again using this activity. So, for example, we avoid duplicating actions merging all of them in a single path.
  • Einstein activities (in blue): based on the AI and the historical tracking data, Einstein can suggest the next best action for each customer about when to send the next communication, through which channel or to create specific actions depending on the likelihood of opening or clicking an email.

Salesforce Activities

Finally, in blue, if the Marketing Cloud Connector is configured, we can interact in real-time with actions related to the Salesforce CRM. There are specific activities for the default objects (Account, Lead, Contact, Case, Opportunity, Campaign Member, Task) but we can also interact with other objects, like the custom ones, using the Object Activity.

Custom Activities

You may have heard or read about Custom Activities. These are activities created by the account owner or third parties for covering functionalities that cannot be accomplished with the default activities. For example, if at some point in the journey, we need to send customer data to a third party in charge of sending a postal mail.

It requires a high knowledge of programming and, in most cases, its development should be taken as a separate project, since it takes time and it is very important to assess all possible scenarios.

You can find all the prerequisites in the developers documentation.

Journey Data VS Contact Data

From my experience, this is the trickiest topic to understand. The information we use in Journey Builder may be coming from static data (for example, the entry Data Extension for one shoot campaigns) or dynamic/live data (for example, from Data Extensions that are updated every day and includes attributes that can be needed to drive the customer to the right path in the journey).

Contact Data VS Journey Data in Decision Split activities

We can find these two types of data in some of the activities of the journey, for example, in the Decision Split. But, when to use each one?

  • Journey Data: for the static information of the customer from the time it was injected in the journey.
  • Contact Data: for getting the latest value of an attribute of the customer that may change during the lifecycle in the journey (it requires a data model to be created in Contact Builder – Attribute Group).

The type of campaigns in which the Contact Data is most common is the ones where, for example, we send an email with an offer and, after a while, we check if the customer purchased the product or not in order to later perform a specific action. In this case, the data should be available in Contact Builder and updated accordingly to the needs of the journey (for example, on a daily basis).

As a workaround, for some scenarios where the journeys are becoming too long or the complexity is higher, we can split the journey in two.

Managing versions

When the journey is ready to be sent, we just need to activate it but, if in the future we need to change some activities or modify the paths, we can create a new version at the same time the old one is still running.

Journey Versions

On this respective, when the new version is activated, it begins admitting new customers but, those who already entered the previous version, remain in the previous version. When all the customers of the old version have exited, the version becomes inactive.

For minor changes like updating an email activity, it is not necessary to create a new version, but it will be needed for applying changes like changing the paths. In case the entry source has to be replaced or the journey settings have to be modified, then a new journey will have to be created.

Journey settings

There are two things to be considered before activating a journey, as they cannot be modified later on and it will affect its behaviour.

Journey Settings
  • Contact Entry: what should happen when a customer exits the journey?

No re-entry: the customer will not be injected anymore in the journey even though when applying the entry criteria (e.g. Welcome Journey).

Re-entry anytime: the customer can be injected in the journey many times appearing two o more times at the same time (e.g. Purchase Confirmation Journey).

Re-entry only after exiting: the customer can be injected in the journey many times but only after exiting it (e.g. a promotional journey where we have to wait for the last interaction of the customer to decide whether it can be injected again in the same journey or not).

  • Goal:when does a journey succeed? (if needed).

It is possible to establish a criteria to identify if we achieve the objective of the journey. For example, based on a percentage of the audience. It is done based on an attribute in Contact Data where we need to store the value that will identify if a customer reaches the goal or not (e.g. number of customers who purchase the product offered in the email sent from the journey).

  • Exit Criteria: when does a customer have to exit the journey? (if needed).

There are some scenarios when a journey has different actions but, by the time the customers reaches the objective (for example, purchase a product), we can define the criteria to define who will exit the journey. As in the previous point, it is also configured based on Contact Data attributes.

I want to know more!

Would you like to know more about how to design real omnichannel campaigns? Look at this video! Thanks to the DreamOle community, one of my colleagues and I had the opportunity to present some of the best practices and trends in the market that confirm why omnichannel continues to be a challenge for some companies, and how Marketing Cloud can help us succeed.

DreamOle 2019 – Don’t smell like teen marketing – the real omnichannel orchestration

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s