Unlock journey reentry with supplemental IDs
In this tutorial, you learn how to enable and apply a supplemental identifier in ÃÛ¶¹ÊÓÆµ Journey Optimizer. You’ll see how using supplemental identifiers allows profiles to reenter journeys, iterate over object arrays, and personalize messages using contextual data like product ID, shipping info, and more.
Welcome! In this tutorial, I will show you how to enable and apply Supplemental Identifier to a journey.
Supplemental ID adds additional context to a journey instance. This additional context enables additional functionality. Firstly, it allows profiles to re-enter event-triggered journeys. By default, event-triggered journeys are executed in the context of a Profile ID. This means that, as long as the profile is active in a given journey, it won’t be able to re-enter another journey. Capturing a Supplemental Identifier in your events, such as an Order ID, Subscription ID, Prescription ID, in addition to the Profile ID, allows a profile to re-enter a journey and be active in up to 10 concurrent instances of one journey. Secondly, if one of the events in the journey has an object array, using Supplemental ID allows you to add the array iteration and create a separate journey instance for each element of the array.
Lastly, Journey Optimizer allows you to leverage attributes of the Supplemental Identifier for message customization, ensuring highly relevant communications. For example, booking number, prescription renewal date, product type, or delivery date.
Let’s go into Journey Optimizer and I’ll show you how this is done on the example of a post-purchase journey.
The journey is triggered by a product purchase event followed by a product purchase confirmation email, the product shipped event, and a condition check, then trigger the product sent email. In this example, we want to send the same profile through this event twice. We’re going to trigger it once for a product P1 and then a second time for product P2. We’ll see that coming through in the emails. However, when we get to our second event, we’re going to be using an object array that’s going to have P1 and P2 in it. So once we send that single event, that will continue the journey for this profile for both products P1 and P2. We’ll then do a quick condition check to make sure it’s domestic shipping in the US and then we will send out the product’s email for P1 and P2. So before we trigger this, let me show you what each one of these looks like.
So here’s the purchase event. You can see on the right we have the associated schema. Let’s take a look at the schema itself. For the supplemental ID, I just selected this product identifier. It’s required for a supplemental ID to have it modeled as an identity in the schema and for an identity namespace to be a non-person identifier. So the product ID fits the requirement. You’ll notice that this is not in an array of any sort and that’s fine. We’re just going to send one event per person or per supplemental ID.
Now, if I go into the fields, you can see that I’ve enabled all of the fields that are part of the payload here and the supplemental ID has been enabled. And as mentioned earlier, the supplemental ID is product identifier and namespace is product ID. Okay, let’s go to our second event. The second event is a collection. It’s going to contain an object array and you’ll see that in the schema. So here’s our schema. Let’s pull it up. You can see how it is modeled as an object array within that object array and we also have a product identifier. It is an identity. It’s important to note that it cannot be a primary identity. The primary identity for both events, in our case, is the personal email address. And we also have the product ID. So it’s important that it has the same identity namespace as the first event so that the journey knows to continue once it gets this event.
If we look at the fields, we can see that they are all enabled here. And the supplemental identifier is also the product identifier, but it is within the collection within the object array. All right, now let’s go into the journey.
So we’re going to fire off an event here and then we’re going to receive an email. I’ll show you the email personalization before we fire off the event. The personalization here is just picking up the product name, the purchase date, the identifier and category from the journey context. You can see that these are contextual attributes that come in from the event payload, which I showed you earlier. If we go into the second email, the product sent confirmation, it’s going to look a little different. We’re getting our product name from the first event. The product ID is coming from technical properties. The supplemental ID and its namespace are actually stored here under contextual attributes. You can find them under journey properties down here. However, the shipping date, estimated arrival and tracking number are all coming via the payload of the second event. And because the collection is getting passed in each journey instance, we need to loop through that object array and pull out the elements that we need. We are pulling the product identifier, the supplemental ID, which equals P1 or P2. Depending on which instance of the journey we’re in, it will then take the shipping date, estimated arrival date and tracking number based on the respective supplemental ID. Lastly, let me show you what the logic of the condition check looks like in the expression editor. I added another attribute called ship to country. If we have a requirement to make sure that we are doing domestic shipping only, then we can do a quick check just to make sure that the country shipped to country is the US. So here you can see that I am pulling the shipping list all the elements from the event payload where the supplemental ID equals the product identifier. It will give me one object and within that object I’m selecting the ship to country. And if that equals US, then we’ll go ahead and continue our journey. All right, let’s test our journey. I’ll put it into test mode and I’ll grab our events.
Here’s our first event. We have P1, my email address, which is going to be the primary identity and baseball glove is the product. Let me copy that as the payload for the simulated product purchase event and hit send. You can see that it was sent successfully. Now I’ll grab the second one here. This is product P2. It’s a baseball bat, same profile. Very important to ensure that we’re sending the same person through the same journey at the same time. Let’s trigger the second event. Now let’s check my email to make sure that those emails are coming through. Sure enough, we have P1 here, baseball glove and P2 baseball bat. Excellent. Now we need to send our second event. So I’ll trigger another event. Let me make sure to select the product shipped event. Now you can see how I’ve modeled this. It still has the personal email address as my email, but now since I’m in an object array, I have both P1 and P2 modeled. I have some additional information here, such as tracking numbers, the ship to country that we discussed earlier, the estimated arrival shipping date, but the most important parts here are the product identifier and my email address, which is the primary identity. So I’ll grab this, overwrite this and hit send. Now what we should be seeing is the journey continue to the condition checked to make sure that the country the order is shipped to is US for domestic shipping and sending an email each for both P1 and P2. So let’s go to our email and make sure that I’m seeing those. And sure enough, we have P1 baseball gloves and P2 baseball bat shipped. In summary, we were able to send the same profile into a journey twice, but for different supplemental ID values, P1 and P2. And so that is an example of multiple re-entrance. Also the second event had an object array, which allows us to iterate through each object within that array and continue the journey for each one of those supplemental IDs individually. Thanks for watching.
For more information on supplemental IDs, please see the product documentation.