AEP Connecting Tissue
04 Jan 2026 » Platform
When licensing a tool like the Adobe Experience Platform (AEP), you should expect an implementation effort at the beginning. One area that is often overlooked is the integration between AEP and other tools. Most of my customers deal with it as with any other integration, but to some it has come as a surprise.
Friction Point
The reason why I wanted to write this post in the first place is to clarify the unnecessary friction that integrating AEP with the rest of the ecosystem has caused. Some of my previous customers had an expectation that this tool can connect to any data source or destination seamlessly, without any additional development.
AEP, like any other advanced software, was built to be as generic as possible. We have thousands of customers, each with a completely different setup. It is impossible to build a piece of software that supports every single case.
As I was preparing this post, I remember my days with Adobe Analytics and Adobe Audience Manager, when this was not a major issue. I guess that, since these tools were very specific and simple compared to AEP, such an expectation did not exist. I also assume that Adobe Experience Manager (AEM) requires a large implementation, which allows for developer time to create any custom integration.
Out of the Box
Let’s start with the out-of-the-box integrations that already exist. AEP boasts a large number of data sources and destinations.
The catalog has dozens of integrations; I stopped counting a long time ago. Some of the categories that you will see are:
- Other Adobe applications
- Advertising platforms
- Cloud storage
- CRM platforms
- Databases
Expect more to be added and feel free to suggest new ones to your Adobe representative.
Most of my customers have all they need in the existing catalog. If you find one that suits you, just go ahead and use it. However, be mindful that you cannot change the behavior other than what is available in the configuration wizard.
Custom Integrations
This is where the friction I mentioned at the top arises. I have had customers who were annoyed with me when I told them that the integration they wanted to set up was not possible. I would argue that nobody should be surprised when licensing SaaS tools as complex as AEP, when a custom layer needs to be built. In other words, my point is that, if you are implementing AEP, you should expect some level of custom integration, which will require development effort.
These are some examples I have seen where a custom integration was needed:
- Source data format needs to be adapted to XDM format to take full advantage of AEP’s features.
- Connecting to a data source needs to follow a particular security standard not currently supported.
- AEP sends the data too fast to a destination.
The solutions I have seen in the past can be grouped into two groups: ETLs and microservices. Let me know in the comments if you used other approaches.
ETLs
Extract-Transform-Load (ETL) tools have existed for a very long time. With them, you can adjust the format of a data source to the format expected by a destination. I do not have the numbers, but I believe that most AEP implementations use ETLs to extract marketing data from internal systems and convert it to XDM or CSV format to be ingested by AEP. The main limitation of an ETL tool is that it usually only supports batch processes.
I would assume that all my customers would have, at least, one ETL tool. To my dismay, I have had customers who refused to use one.
Microservice
I am using here the term “microservice” very loosely. I am referring to a custom development that receives data from a source and does all the necessary adjustments so that the destination can receive the data. I know it sounds like an ETL, but there are a couple of major differences:
- Microservices can support real-time use cases.
- Microservices can do anything that you can do with a programming language, which is more than what ETLs can usually do.
Let me share a few examples of microservices my customers have needed:
- The HTTP API connection was sending the data too fast and in bursts, causing the downstream system to crash. This destination was designed to be as fast as possible, so it is not possible to make it slower. The solution was to build a microservice with a large buffer, to adjust the speed.
- An Adobe Journey Optimizer (AJO) journey required accessing data in a way that AJO custom actions could not support. A microservice was created, which would receive a call from a custom action, retrieve the additional data, and send it in an event back to AEP, which was captured by the journey.
- AJO Custom Actions send calls individually, whereas a particular receiver end required microbatching and a slower rate. A microservice took care of this mismatch.
In summary, with AEP (and, I assume, with our competitors), you should always expect to develop a connecting layer around AEP.
Photo by John Barkiple on Unsplash