![](https://www.pedromonjo.com/assets/images/responsive/2024/2024-06-16-recency-frequency-aep/frequency-810-f35362def.jpg)
Recency & Frequency in AEP
16 Jun 2024 » Platform
Adobe Audience Manager offered a fundamental feature for a Data Management Platform: recency and frequency. However, the Adobe Experience Platform does not provide such a feature, at least not in the same way. Let’s see why this is so and what alternative options we have.
What is frequency and recency?
This is a feature that is applied to a building block of a segment in the following way:
- Frequency: how many times has the visitor qualified for the segment building block.
- Recency: what is the lookback window to count for the qualification.
Let’s use an example, the typical use case to stop showing an ad to a visitor after 3 times in the last 30 days. In Adobe Audience Manager (AAM) you would create a trait for the ad impression and a segment with just that trait, a recency of 30 days, and a frequency of 3.
You could then send this segment to a Demand Side Platform to exclude the visitor from the ad or campaign.
Quo vadis AEP?
What about the Adobe Experience Platform (AEP)? What features does it offer to achieve recency and frequency?
Before I explain the case of AEP, we need to remember the context in which it has been developed. AAM relied completely on 3rd party cookies to be useful, and recency and frequency were features mainly to control display ads on media websites. As we all know, there is a general crusade against these cookies and, for the past few years, we have been bracing ourselves for a cookie-less web. The reality is that 3rd party cookies have been more resilient than expected, especially since Google’s business model relies on them, but I would not bet on them.
On the other hand, AEP was never designed to work with 3rd party cookies and to replace AAM like-for-like, especially in the case of display ads. When it was initially designed, the expectation was that these cookies would disappear very soon. Although they are still with us, their future still looks gloomy. Consequently, the tracking of display ads is not supported, as they rely on 3rd party cookies.
That being said, AEP has very similar features that can be useful in other, similar use cases, where recency and frequency are needed. We just need to know how to use them and their constraints.
Segmentation engines
As with AAM, the obvious place to start is AEP segmentation.
Edge segmentation
If you review the Edge segmentation UI guide, you will see that some cases support frequency:
- Single event with a profile attribute within a relative time window of less than 24 hours
- Negated single event with a profile attribute within a time window (of less than 24 hours)
- Frequency event within a 24-hour time window
- Frequency event with a profile attribute within a 24-hour time window
- Negated frequency event with a profile within a 24-hour time window
- Multiple incoming hits within a time profile of 24 hours
- Multiple events with a profile within a 24-hour time window
This list may change over time, but this is what we have at the time of writing. You will have noticed that I have only referred to frequency, as recency is fixed at a 24-hour window. This works great if your use case has a recency of up to 24 hours, but you cannot use this engine for use cases where you need a longer recency period.
The best advantage of this segmentation engine is that it evaluates segments in milliseconds, which allows for real-time use cases. For example, if you want to count up to 3 times in the last 24 hours and then exclude the visitor from a personalization message, edge segmentation is for you.
Streaming segmentation
The streaming segmentation guide has a shorter list of criteria, although it is more generic. I have to admit that it is not clear to me which cases have a limitation of 24 hours and which do not. However, again, you can see how you can create more complex segments with frequency values. In some cases, again the recency will be limited to 24 hours, although in other cases you could use longer recency.
While it is not mentioned in the documentation, you need to remember that event datasets have a time-to-live (TTL). Therefore, the recency will have a maximum of this TTL.
Streaming segments, although they evaluate pretty quickly, are not as real-time as edge segments. This is something that you have to take into account: there will be a gap between the moment the person qualifies for the segment and the time when the segment membership can be used. In the ad suppression use case, this means that, during this period, the person will still be seeing the ad, even if she has reached the maximum frequency.
Therefore, you have to decide whether your use case can be delivered through a streaming segment:
- Can you live with the delay in qualifying for the segment?
- Can you create a segment with the recency that you need?
Batch segmentation
Last, but not least, are batch segments. Here you can basically do whatever you want in terms of recency and frequency, there are no restrictions like in the previous two engines. The main restriction is, again, the TTL of the dataset.
This flexibility comes with a price, though: batch segments are evaluated every 24 hours. In other words, it may take up to 24 hours between a profile qualifies for a batch segment with frequency and recency, and the time when the segment membership is updated. Again, you need to confirm whether your use case can allow for this delay.
AEP features and apps
AEP has many more capabilities, compared to AAM, and it also has apps built on top of it. Even if they were not exclusively built for recency and frequency use cases, you may be able to use them.
Computed attributes
The first one is probably the most obvious. With computed attributes, you can “[…] convert profile behavioral data into aggregated values at the profile level […]”.
In other words, you can create a rule to count the number of times a particular event has fired and, based on it, update a profile attribute. Then, you can use this profile attribute in a segment.
Computed attributes are evaluated in batch, with a refresh rate based on their lookback period (i.e., recency), and are also constrained by the TTL of the event dataset. You have to take this delay and maximum lookback window into account and see if they fit into your use case.
Adobe Journey Optimizer
I guess that you must be scratching your head, wondering what Adobe Journey Optimizer (AJO) can do for frequency and recency use cases. I cannot claim credit for this idea, it came from one of my customers.
The idea goes as follows:
- Configure a profile attribute as an integer, with a default value of 0.
- Create an event-triggered journey, with the triggering event the one you want to count.
- Set up the journey so that it increases the profile attribute by one, using the update profile activity.
- Create a [edge/streaming/batch] segment where the integer is less than your maximum.
Before you go ahead with this solution, you need to consider the following:
- It uses a profile attribute. If you have many use cases needing this feature, you will end up with a lot of additional attributes.
- You can use this profile attribute in any segment.
- There is a delay between the moment the event is generated and the moment the profile attribute is available. Expect somewhere in the region of 20-30 minutes.
- The recency of the journey described above is infinite: it always increases the integer. If you need a finite recency, you will have to change the journey and account for the lookback period.
Pretty neat, right?
Query Services
I did not want to finish this post without suggesting the “fallback” option: writing a SQL query to update a profile attribute. I do not think it makes much sense to use this option, though, as it just makes it more complicated to maintain. Besides, you need a data distiller license. However, there may be use cases I am not aware of that can only be delivered through Query Services.
Other options
I have not explored all AEP capabilities and options to manage frequency and recency. I am quite sure that there are more crazy things that you can do with AEP. If you have an idea or have implemented something similar, I would love to hear from you in the comments.