Adobe Target and Adobe Journey Optimizer Coexistence - II
This post is a continuation of the first part of the Adobe Target (AT) and Adobe Journey Optimizer (AJO) coexistence. If you have not read it, you will not understand this post. I strongly suggest that you start there.
Let’s continue with the options to allow AT and AJO offers to coexist.
Only Use AJO for Personalization
If you are running offers on both AT and AJO, why are you managing two systems? Would it not make more sense to use the best tool for personalization?
AJO offers, especially if you choose to go with the latest version, AJO Decisioning, is the most advanced solution to manage offers. You can add start and end dates, priorities, capping rules, qualification rules, and you can use propensity scores in ranking formulas. While you may be able to do the same in AT, you would need to use profile scripts, with its limitations, or complex AT activities.
With this approach, you would use AJO for personalization activities, and AT for A/B tests and all premium features. Obviously, you would not be able to run an A/B test and an AJO personalization activity on the same placement. However, I would argue that, if you want to do that, you have not thought it through well enough.
If this were the absolutely best solution, everybody would be using it, but the reality is that this is not the case. The reason is very simple: AT has the Visual Experience Composer, which makes it much more marketer friendly than AJO. In AJO, you need to generate or manipulate the HTML manually. This is the main drawback of this approach. That being said, I have had customers who had an IT resource dedicated to the marketing team, to manage all technical work like this.
There is another drawback: reporting. With A4T, you have all the reporting done automatically, whereas if you use AJO, you will need to prepare the reporting more manually.
My hope is that, in the future, AJO will have its own Visual Experience Composer and an equivalent of A4T, so this gap will close and AJO will become the main tool for personalization.
The Arbitrator
The final and most complex solution is to create an arbitration layer between the browser, AJO, and AT. I can think of two options to develop this arbitration layer:
- Microservice. You could set up a microservice, which would be invoked from the browser. This microservice would then request the AJO offers and AT activities, would evaluate which content should be returned to the browser, and send it back to the browser. The browser would blindly show whatever the microservice sends back.
- JavaScript function. Very similarly to the microservice, this function would request the AJO offers and AT activities, decide which one should be shown, and discard the other one. This code would live in the user’s browser.
Each has its pros and cons, and I do not think there is a clear winner. In both cases, you need to write custom code, which is why I mention this is the most complex solution. The microservice requires extra infrastructure, but it will be faster than doing everything in the browser.
There is one detail that is very important to keep in mind with this approach: the difference between decision and impression. Let me explain.
By default, AT increments the impression counter every time a decision is made to send an experience back to the browser. In other words, AT assumes that all retrieved experiences are shown. Remember that AT and A4T reports use this impression metric heavily. With an arbitrator, not all retrieved experiences will be shown. This poses a problem for AT: the reports will be completely wrong. Fortunately, AT has a solution for this edge case. Since I recently wrote a full blog post on it, I will not cover the solution here and just reference my other post: Conditional Adobe Target Rendering.
The case of AJO offers is different. AJO will always send a record to a system dataset for every decision made. If you want to capture the impressions or the clicks, which are not mandatory, you should send an event back to AEP using a standard eventType: decisioning.propositionDisplay for impressions or decisioning.propositionInteract for clicks.
I know I have skipped many steps regarding this arbitrator. Since it is custom code, the business rules will be different per company, and it is a complex piece of software, I cannot offer a generic solution or sample code. YMMV.
Photo by Astrid Schaffner on Unsplash