Segmentation in AEP
25 Sep 2022 » Platform
If you have been following my series on the Adobe Experience Platform (AEP), you should now have data ready to work with. If you have the RTCDP or AJO SKUs, you will now want to start communicating with your customers. For that, the next step is to segment your total population, which is what I will describe here.
Let me first summarize to you how we arrived at this point in the process:
- You are in a project to implement AEP.
- The requirements have been gathered and you are working on the technical part of the project, after the U-turn.
- You have identified the AEP identities.
- You have plugged the data sources into AEP.
- You have created the XDM schemas and the corresponding datasets.
- After all the necessary tests, these schemas and datasets have been enabled for profile.
With all these steps, our unified profile service is full of profiles, ready to be activated.
Create a segment in the UI
I guess that, if you have been playing with AEP, you know where to find the segments in the UI:
You do not need a degree from Harvard to identify where you need to click to create a new segment. It is the button on the top left that says “Create segment”. This is what you get after clicking on it:
On the left panel, you have three tabs, which are the building blocks of the segments: profile attributes, experience events and other segments.
As its name implies, this tab allows you to select profile attributes and compare them with static values or other profile attributes. The section on the left allows you to navigate the XDM of the Unified Profile. Once you have found the attribute, you just need to drag and drop it onto the central canvas.
As with other Adobe Experience Cloud tools, you can combine the parameters in various ways, with containers, inclusion/exclusion conditions and the operators and and or.
Not only can you select attributes, but also events associated with profiles. Things get really interesting with this canvas, as you can do many combinations:
- Events with parameters with specific values
- Sequence of events
- Time between events
- Repetition of events
- And and or operators
- Inclusions and exclusions
- And more
I will not try to explain all the options here, as I do not think I even know all of them. I suggest that you play with the canvas to build what you want.
Combination of building blocks
The profile attributes and experience events are not mutually exclusive. In other words, a segment can have both. With this capability, you can create segments of profiles that have certain attributes and have interacted with the brand following certain patterns. In case you cannot visualize why this is useful, consider the following sample segments:
- An audience of customers who live in New York and have not purchased in the last month.
- An audience of executives at the director level, who work for a company in the FSI vertical and have attended two of your webinars.
- An audience of visitors to the website, who have spent more than $100 in the last purchase and have given consent to receive personalized offers.
Finally, it is also worth mentioning that you can also reuse existing segments. If you have many segments that are a combination of simple conditions, you can first build segments with these conditions and use them in other segment definitions. The goal is to reduce the time it takes to create segments and simplify the maintenance.
The last part of the segment builder is the properties section on the right:
From the top, we get the following:
- Segment size estimation. While this feature seems interesting, it is not very precise. It is based on sample data and some other details that I do not exactly know. I would only use it to get a rough idea of the size of the segment. You can force a refresh of the estimate, although I am not sure if you will get better results with it. If you get a size bigger than 0 in the segment size estimator, you can view a sample of profiles in the segment.
- Code view. I will refer to it in the next section.
- Name. This is a mandatory field. Before you even start creating the first segment, you should come up with a naming convention, document it and stick to it.
- Description. Although this is an optional field, will you remember what your segment was about in six months? No, right? My suggestion is that you document here enough details of the segment so that it reminds you in the future what you were trying to do with it.
- Evaluation method. See below and more in future posts.
- Summary of the segment. This is a textual description of the definition of the segment. It tries to explain what you have on the canvas.
Segmentation API & PQL
One of AEP’s key initial decisions was that it had to be API-driven. You should also be able to do using an API, all operations that you can do with the UI. In fact, with AEP, the UI ends up calling the API behind the scenes. The Segmentation Service API is no different. I usually do not talk about the API in my posts on AEP, but I think that this case is a bit different.
At the center of the segmentation engine, we have the Profile Query Language (PQL). Think of it as the equivalent of SQL; instead of querying tables, you query the unified profile store. As with SQL, complex queries can become very difficult to follow. If you want to see the PQL that is generated from your segment definition in the UI, click on the “ Code view” button in the segment properties section. If you want to learn how to use it, follow the previous link.
One limitation of the segmentation API is that all segments created via this method cannot be later edited through the UI. I assume this is because the UI cannot represent all potential PQL queries.
My initial plan was to explain in detail the evaluation methods in this section but I think this post is already too long. I hope to go into more detail in the future and, for now, leave a summary of this feature.
- Edge segmentation. These segments are evaluated in real-time on the edge nodes. These nodes have a copy of the profile store and can process requests from Web SDK implementations or calls to the Edge Network API. This is particularly useful for the integration with Adobe Target. Not all segments can be evaluated on the edge; check the edge segmentation UI guide to see which cases are supported.
- Streaming segmentation. Although you could argue that edge segmentation is also a type of streaming segmentation, the difference is that the streaming segmentation happens in the hub, not the edge. It is also a real-time evaluation of data coming from any streaming data ingestion methods. As with the previous case, not all segments qualify for this method. This help page will tell you the criteria.
- Batch segmentation. This is the fallback evaluation method, where the segments are evaluated nightly when the previous methods are not possible. Do not worry, all segments above will also be evaluated in batch for completeness.