Introduction to Offer Decisioning Engine
20 Aug 2023 » Platform
One of the probably least understood tools that come with the Adobe Experience Platform (AEP) is Offer Decisioning Engine (ODE). It is currently bundled with Adobe Journey Optimizer (AJO), although I personally consider it a completely independent tool. I have used it in a couple of projects and, in the last one, we have configured it to do some cool stuff. While conceptually simple, it has so much flexibility that it is difficult to understand it in full. This post is just an introduction to help you understand it.
Concepts
Let’s start with a few key concepts.
Definition of an offer
The first concept that needs to be clarified is what we call an offer. As consumers, we think of offers as any promotion to lure us to open our wallets, and probably this is what retailers will use ODE for. However, the concept of offer in marketing is not quite that. In summary, an offer is just a piece of content. No more, no less. In other words, it does not have anything to do with promotions, even if the word implies so. The connection with a promotion is given by the context in which they are used.
Metadata
You have two types of metadata:
- Collection qualifiers: labels (single values) that are used to group offers in collections.
- Offer attributes: key/value pairs of meta-data, which, you can use to classify offers.
Types
Offers can be of the following types:
- HTML
- Plain text
- JSON
- Image
Channel
This is what it is you think it is. The idea is that an offer can be sent through multiple channels, each of which will require a different rendering. ODE supports:
- Web
- Mobile
- Social
- Non-digital
- Instant messaging
Placements
This is where things start to get interesting. Before you start creating the offers themselves, you must define the locations where the offers should be shown. This is what we call a placement, which is a combination of a channel and a type.
You should expect to have multiple placements in your implementation. To make it clearer, here you have some examples:
| Placement name | Description | Type | Channel |
|---|---|---|---|
| WEB-HP-HERO | Hero banner on the home page of your website | Image | Web |
| EMAIL-NEWS-BOTTOM | Bottom part of your newsletter | HTML | |
| APP-ORDER-TOP | Top of the order confirmation screen on your mobile app | Mobile | JSON |
These are just examples. Since you create the placements based on your needs, I encourage you to establish a naming convention for the name.
Offer rules
An ODE rule is very similar to an AEP segment. I am pretty sure that you are scratching your head, wondering: why do I have 2 different interfaces to create exactly the same? According to the decision rules help page:
The Segment Builder provided to create decision rules presents some specificities compared to the one used with the Segmentation service. However, the global process described in the Segment Builder documentation is still valid to build offers decisions rules.
Although they are technically different, in my head, they are almost the same. Once you start using the rules UI, you will see the differences.
Offers in ODE
Now you have all the clarifications needed to start to understand what an ODE offer is. The definition I gave above was a generic definition, which could apply to any tool. The best way to understand an ODE offer is to follow its creation wizard. You will notice how I have been preparing the ingredients in the previous paragraphs.
An ODE offer is composed of the following parts:
-
Details. Basic information about an offer:
- Name: remember to follow a naming convention.
- Start and end date: mandatory field that defines when an offer is available
- Metadata parameters
- Representations. An offer (e.g. 10% discount on all beauty products for silver members) can be shown in multiple placements and while the offer will look different depending on this placement, it is the same underlying offer. Therefore, for every placement where you plan to show your offer, you must supply placement-specific content. For example, if the offer is going to be shown in a push notification, the content must be in JSON format; but the same offer on the home page may be an image or an HTML snippet. In other words, you are grouping all the ways an offer may look under one umbrella. It goes without saying that, before you can start creating offers in ODE, you need to define the placements and get the content from the creative team.
-
Constraints. Here you define the offer-specific conditions under which ODE will return this particular offer. There are other conditions to be taken into account, which I will explain later.
- Offer eligibility. I would have used a different wording and called it “audience”. It is either unrestricted or only for profiles that qualify for an AEP segment or ODE rule.
- Capping. You can restrict how often and how many times an offer can be shown.
Fallback offer
In some cases, you may want to show something to your visitors or customers, even if they do not qualify for any offer. These are called fallback offers. The only difference with the offers I have just described is that there are no constraints, for obvious reasons.
Collections
In a typical implementation, you could have hundreds or thousands of offers. Besides, these offers will likely be very heterogeneous. On the other hand, for a particular placement, you will only want one of a handful of offers. This is where collections come in handy: they are groups of offers.
There are two types of collections:
- Dynamic collections. These are collections based on a given list of collection qualifiers, which I mentioned above. We call them dynamic collections because the collection automatically expands or shrinks as you add or remove offers with the corresponding collection qualifier, or add or remove this metadata label to existing offers.
- Static collections. Alternatively, you can manually pick which offers belong to a collection.
Decisions
I have written this post in this particular order so that each section builds on top of the previous content. The last part of ODE, the bow that ties everything else, is the decision. I will not explain in detail here how it works, but it is basically a decision tree. It takes a collection and, using your own algorithm, chooses the best offer.
You may have noticed that there are two places where you select what offers someone is entitled to:
- At the offer level, the constraints define which offers are available for a particular profile.
- At the decision level, the decision tree chooses the best offer amongst those that the user is entitled to.
Both work in conjunction and the reason for having both is to give the highest flexibility.