Day2: How Adobe Experience Cloud Products Actually Connect
When you first look at the Adobe stack, it feels like a shelf full of separate products. Adobe Experience Platform, Real-Time CDP, Adobe Journey Optimizer, Customer Journey Analytics, Target, Adobe Analytics. Each one has its own name, its own console, its own learning curve. So it is easy to assume they each solve a separate problem.
They do not. Once you see how they fit together, the whole stack turns into one system with a shared base. This post is about that base, written from the point of view of someone who already knows AEM and is now picking up AEP.
The shift: one foundation, many apps
Here is the idea to hold onto. One layer collects customer data, cleans it, works out who each person is, and builds a single profile. Every other product reads from that layer. It either activates the data, runs journeys on it, or analyses it. AEP is that base. RTCDP, AJO, Target and CJA sit on top.
If you work in AEM, you already know this shape. In AEM, Sites, Assets and Forms are different products, but they all sit on the same Oak repository. Write something once and every app can see it. AEP is the same pattern, except the thing it stores is customer data and resolved identity, and the apps on top are RTCDP, AJO, Target and CJA. Once you see it as one repository with many apps, the rest of this post is just detail.
Layer 1: the AEP foundation
This is AEP itself, and it does five jobs, in order.
Ingestion brings data in from websites, mobile apps, CRM, POS, call centres and files. It runs at two speeds, batch for nightly files and streaming for events that fire the moment they happen.
XDM schemas give that data a standard shape so every app reads it the same way. This is the part that will feel familiar. An XDM schema is close to a Content Fragment Model. You define the structure first, then data fills it.
Identity is where AEP earns its keep. It works out that an anonymous web visitor, a mobile user, a CRM record and a loyalty member can all be the same person.
The Real-Time Customer Profile is the single record that comes out of that stitching. It keeps updating as new data lands.
Governance and consent sit across all of it, so the data stays compliant and safe to use.
The order matters more than it looks. Each step depends on the one before it. A weak schema breaks identity. Broken identity builds a wrong profile. A wrong profile feeds every app above it with bad data. This is why the foundation work decides whether the whole program succeeds.
Layer 2: the apps that act on the data
Three jobs, handled by familiar names.
Real-Time CDP takes audiences built in AEP and sends them out to ad platforms, email tools and data warehouses. Think Google Ads, Meta, a DSP, a warehouse.
Adobe Journey Optimizer runs journeys off the profile. Cart reminders, onboarding, win-back, anything triggered by what the customer just did.
Target personalises the on-site experience using the same profile. The homepage, recommendations, A/B tests.
None of these build customer intelligence on their own. They react to what AEP already worked out.
One point worth knowing if you scope projects. RTCDP and AJO are not separate platforms next to AEP. They are apps licensed on top of it, on the same sandbox, sharing the same schemas and the same profile. So when you plan the work, the foundation is built once and shared, not rebuilt for each app.
Layer 3: analytics, and why CJA is different
Customer Journey Analytics connects straight to AEP datasets. That lets it analyse the full journey across web, app, CRM, call centre and store, all tied to one person.
This is where it splits from Adobe Analytics.
| Adobe Analytics | Customer Journey Analytics | |
| Primary focus | Digital behaviour only | The entire customer journey |
| Data source | Web and app hits | Unified AEP datasets (web, CRM, POS) |
| Identity | Browser based tracking | Stitched identities across all touchpoints |
The reason CJA can do this comes down to where it reads from. It works on the AEP datasets in the data lake, which hold the full event history across every channel, including the offline ones. Adobe Analytics was built for digital behaviour, so it never reached into the store or the call centre. That is the real line between them, not a feature here or there.
A real example: the "buy now" email that should never send
Start with the problem this whole stack exists to fix. A customer browses your site, adds an item to the cart, and leaves. The next day they walk into a store and buy it. Fifteen minutes later they get an email: "Still thinking about buying?"
That email is not a content bug. It is an identity and timing failure. The store sale lived in one system under the loyalty ID, the website knew the person only as a cookie, and the email tool never learned the purchase happened. Three systems, three identities, no shared view.
Here is the same story running on AEP.
The web cookie and the store loyalty ID share an email, so AEP links them into one person and the purchase lands on a single profile.
The website sends the browse and cart events tied to a web cookie (ECID). The store sale comes in tied to the loyalty ID and email. AEP's Identity Service spots the shared email and links all three, so it now knows this is one person. The purchase event lands on that single profile right away.
Because the profile updated, the apps on top react correctly. AJO sees the purchase and stops the reminder journey, sending a thank-you and a matching accessory instead. RTCDP drops the person from the cart retargeting audience so the ad stops following them. The awkward email never sends, and the spend on a pointless ad stops too.
Nothing here is magic. It works only because the foundation stitched the identity and updated one profile that every app could read.
A second example: a question only CJA can answer
Say a telecom wants to know how many customers who called support twice in a month then cancelled within the next thirty days. That question crosses the call centre, the billing system and the web account.
Adobe Analytics cannot answer it, because it only sees digital behaviour. CJA can, because it reads the AEP datasets that already hold the call records, the billing events and the web activity, all tied to the same customer. Same foundation, different app, a question that was out of reach before the data was unified.
The takeaway
You are not learning six products. You are learning one foundation and a set of apps that read from it. Get the foundation right, the schemas, the identity, the profile, and the apps fall into place. Get it wrong and every app above inherits the mess.
That is also why the next post matters. It goes deep on XDM: schema design, classes, field groups, identity fields, and the small mistakes that quietly break everything downstream. That is the part where an AEM background gives you a real head start.