Authors: @Danny-Miller, Shruti Jagtap, Douglas Paton
In this post, we look at the process for capturing the latest event experience across multiple products in Adobe Experience Platform. We also dive into how this technique can be used to create dynamic list segmentation for these products.
Data models can sometimes be structured in such a way where you can track different types of events in one schema/dataset. For example, this might be a single dataset that has all subscriptions for newsletters or subscriptions. The data structure might be common, but you have many newsletters across many products with differing statuses over time. When subscribe and unsubscribe events are tracked as individual events, it is common to want to know what the current state is so that you can deliver the next best customer experience.
To address this, we considered two approaches during implementation for a customer:
- Track the current state on an Array on the profile
- Use a segment against the Experience Event
We considered 1., but eventually decided to go with #2 for a couple of reasons. The first was that it didn't require us to update the Array all at once, which would be a huge task for those who have upwards of 30 different product/newsletter combinations all sending in events at different times and from different business units or sources. The second choice also provided us with more flexibility when it came to creating different segments. We could track people who had changed their state in the last X number of days but followed that up with Event Y, as an example.
However, in taking the second approach we needed to be able to identify the current status (the most recent event), for each user.
Determining the current status of users
To identify all user profiles that had active subscriptions, we built a segment that reflected the most recent event in a dataset (such as subscribe to the newsletter). But, we had to keep in mind that there could be multiple subscribe and unsubscribe events in the same dataset. And, each event might apply to different newsletters. The challenge was to capture the last subscribe event while ensuring that no further unsubscribe events following it.
We addressed this using the following methodology. A sequence of experience events was created where the following event should be excluded (as shown indicated by the red line in Figure 1). The reason for this was that, based on the conditions provided on the event, we were finding experience events associated with a profile following where there is no other experience event. This logic helped in flagging the last experience event of a profile.
Figure 1: A sequence of experience events. The red line represents exclusions to the sequence.
For example, let's create a segment to find all profiles who have at least one active subscription, as seen below.
Attributes Used
Subscription Status: Active, Abandoned, Deprovisioned.
Subscription ID: ID for the subscription.
Users can have multiple events for a particular subscription (captured via Subscription ID) and we capture the status for every event, as well. In order to find profiles with at least one active subscription, we have to find profiles that have at least one subscription where the status of the last event is Active. Then, we need to flag the last event and check if the status is Active.
To flag the last event, we need to ensure there is no other experience event following an event.
In this case, we need to find the last event which has the status as Active.
We did this using the following approach:
-
As shown in Figure 1 create the first event with the following conditions.
Figure 2: Subscription status set to Active.
- Create an event following the above event and ensure it has an Exclude condition.
You can see the status in the below event (Figure 2) has all values except Active.
The subscription ID used in this event (which is Any2) should be the same subscription ID that was used in the previous event. (Note the highlights in red in Figure 3. It specifies Any1 for the previous experience event).
Figure 3: Checking the status of the previous experience event.
Getting an attribute associated with the previous event
As you are adding events, the attributes associated with it are shown on the left rail under Events as shown below:
Find the attributes you want to add to your current event from the ones displayed here and drag and drop it to the segment builder to the right.
Figure 4: Choosing the variables that define the segment.
We do this because users can have multiple subscriptions and for every subscription, we need to find the last event. To make this happen, we need to ensure for every subscription ID we check if an Active event does not have a non-Active event following it.
For the following user, the segment logic checks for subscription 123 and sees a non-Active event following it hence it's not an Active subscription. But the same user has a subscription "789" that has an Active Subscription event and does not have any other event following it. This means the profile will qualify in our segment of "users with at least one active subscription".
Figure 5: Checking a user’s subscription status.
If we don't specify the subscription ID of the previous event (as seen in Figure 6), there is no guarantee for the subscription that is checked following the active event of a subscription.
Figure 6: Subscription ID must be specified, as seen here.
Even though this user has an Active subscription, he will not qualify for the segment as he has a Disabled event following an Active Event.
Figure 7: A non-qualifying user.
Other examples of use cases where this logic can be used are:
- Give all profiles that visited the site and on their latest event used channel/campaign "xyz" — logic: flag the last analytics experience event and check if the campaign/channel associated with it is "xyz".
- Give all profiles whose latest call (calls being an experience event) was longer than 10 minutes.
- Give all profiles whose latest purchase (purchases as an experience event) total price was more than $100.
Dynamic Segmentation — How was it achieved in the above example?
While it might not be obvious, we used Dynamic Segmentation above to ensure our Subscription was filtering on the correct Subscription_ID (a newsletter or license, for example). We needed to do this because we have multiple subscriptions in the same dataset.
Let's take a step back and see what it is doing.
We dynamically compare the subscription_IDs of event1 and event2 to ensure we are not comparing the Active status for one newsletter to the Disabled status of a different newsletter.
Figure 8: Comparing subscription statuses for a single subscription_ID.
We don't want to build a segment for each subscription id. We basically are saying event1.subscription_id must equal event2.subscription_id without having to specify which subscription_id we want. Without this feature, we would have had to create one segment for each subscription_id, which could be hundreds (depending on the number of newsletters or licenses we have) and could potentially grow over time as the user subscribes and unsubscribes to more products.
This segment solves our original question of "Get all user profiles that have any active subscriptions". If we wanted to pick a specific subscription, we would specify the subscription we were interested in.
How else could we take advantage of Dynamic Segmentation?
Let's imagine we are capturing a Product in our subscription experience event here, Product Purchases in another experience event, and Conference Attendance in a third experience event. We could build that into any of these segments and create additional events to trigger further action:
-
People who purchased a product, but do not subscribe to that product's newsletter.
-
People who have not purchased a product, but do subscribe to that product's newsletter.
- We could reach out through our newsletter dynamic content to help nudge them along or ask if want to be contacted or more info links.
-
People who let their subscription license expire, but still receive the newsletter.
- We could reach out with offers.
-
People who attended a conference for that product, but have not purchased it.
- We could reach out like above.
-
People who attended a conference for that product, but have not signed up for a product newsletter, nor purchased a product
- We could reach out to increase engagement but taper off over time.
We could even further augment these profiles with AI/ML models to calculate various propensity scores that would allow us to further target or tailor our messaging, but we will save that for another blog post.
An interesting challenge we found along the way
One of the more interesting things that we discovered through this process is that it's very hard to verify the list.
Because of the unwieldy nature of these lists and the sheer number of subscribers that could potentially be on each segment, we found that it was impossible to validate whether or not we had captured the correct subscribers for each list.
The best solution we found was to take a random sample and manually check them all. This isn't the most ideal validation method and it's an exciting challenge for us to work on in the future.
If you want to find out more about segmentation within Adobe Experience Platform, you can check out our technical documentation on Segmentation in Adobe Experience Platform. You can also explore a hands-on exercise in Adobe Experience Platform segment builder.
Follow the Adobe Experience Platform Community Blog for more developer stories and resources, and check out Adobe Developers on Twitter for the latest news and developer products. Sign up here for future Adobe Experience Platform Meetups.
Resources
- Adobe Experience Platform — https://www.adobe.com/experience-platform.html
- Adobe Experience Platform Segment Builder — https://expleague.azureedge.net/labs/L775/index.html#lesson-4-segmentation-on-unified-profile
Originally published: Jan 9, 2020