Send Adobe Target Exposure Back Into Real-Time CDP

Almost everyone running Adobe Target alongside Real-Time CDP thinks about the integration in one direction: build an audience in RT-CDP, push it to Target, personalize the site. Adobe has made that path genuinely good, including edge personalization use cases and profile attribute activation.

I want to argue for the other direction. What happens when the customer profile knows this person was in Activity X and received Experience B?

Once that’s true, Target stops being the place an experience got delivered and starts being a source of behavioral data for the rest of the stack.

What we showed them is data too

We put an enormous amount of behavior into AEP. Product views, cart adds, whitepaper downloads, purchases. What’s almost always missing is the other half of the interaction: what the brand chose to show that person before they did any of it.

Two customers view the same product page. Customer A saw the default. Customer B was in a Target activity and got a free shipping message. In the behavioral data they’re indistinguishable, same page, same timestamp, same referrer. From a marketing standpoint they are not remotely the same person, because we deliberately said something different to one of them.

Target already has this. Response tokens expose activity.id, activity.name, experience.id, and experience.name, and with Web SDK all of it comes back in the personalization response.

Capture that as an Experience Event and RT-CDP can suddenly reason about what the visitor did and what we showed them beforehand.

How it actually works

Nothing exotic here. Web SDK hands you everything you need in the personalization response, and you send it back through the Edge Network as XDM.

When Target returns a decision, each proposition carries a scopeDetails object that identifies exactly what was decided:

json

{
  "id": "AT:eyJhY3Rpdml0eUlkIjoiNDM0Njg5IiwiZXhwZXJpZW5jZUlkIjoiMSJ9",
  "scope": "__view__",
  "scopeDetails": {
    "decisionProvider": "TGT",
    "activity": { "id": "434689" },
    "experience": { "id": "1" }
  }
}

That’s the price versus convenience test in raw form. Activity 434689, experience 1, the convenience message. The proposition id is just base64 and decodes to the same two values, so the assignment is in there twice.

Response tokens ride along on the items, under meta, and that’s where the readable names and the Target profile values show up:

json

"meta": {
  "activity.name": "Homepage Value Prop Test",
  "experience.name": "Convenience",
  "profile.categoryAffinity": "outdoor-furniture",
  "profile.mortgageIntent": "high"
}

Worth knowing if you’re wiring up profile scripts: the attribute your script maintains as user.mortgageIntent comes back on the response token as profile.mortgageIntent. Same value, different prefix, and it trips people up the first time.

Then the distinction the whole architecture rests on. A decision is not an exposure. Target can return a proposition that never renders. What you want on the profile is the display event, which Web SDK sends after the content actually renders. It’s an Experience Event with eventType set to decisioning.propositionDisplay, carrying the propositions under _experience.decisioning.propositions. With renderDecisions: true, that fires automatically. For form-based activities, SPAs, and anything you render yourself, you send it explicitly after rendering:

javascript

alloy("sendEvent", {
  xdm: {
    eventType: "decisioning.propositionDisplay",
    _experience: {
      decisioning: {
        propositions: [{
          id: proposition.id,
          scope: proposition.scope,
          scopeDetails: proposition.scopeDetails
        }],
        propositionEventType: { display: 1 }
      }
    }
  }
});

Pass scopeDetails through untouched or you lose the identifiers and the whole exercise is pointless.

One asymmetry to plan for. The scopeDetails structure flows into XDM natively once your schema has the Experience Event – Proposition Interactions field group. The response token values do not. Those you read off proposition.items[].meta yourself and map into your own XDM fields. So the activity and experience IDs are close to free, and everything interesting sitting in the Target profile takes deliberate work.

Segment on the IDs, display the names. Activity names get edited mid-flight and your audience quietly splits in half when they do. IDs don’t move.

Continuing the conversation after they leave

This is the use case I’d build first.

Say you’re testing two value propositions: price versus convenience. A visitor gets the convenience experience, browses hard, and leaves without converting. Right now the next touch, whether that’s email, paid media, or an AJO journey, has no idea any of that happened. It starts over.

If exposure lives on the profile, you can build an audience for visitors who received the convenience experience, showed intent, and didn’t convert, then activate it downstream. The follow-up email reinforces convenience. Paid media runs the same proposition. The next site visit picks up where the last one ended.

That’s the difference between page personalization and journey personalization, and it doesn’t require anything RT-CDP wasn’t already built to do. Audiences from profile characteristics, activated to destinations for retargeting, suppression, CRM, and analytics enrichment. Target exposure is just another signal feeding it.

The financial services version is easy to picture. One visitor sees a points-forward credit card offer, another sees cash back. Neither applies. Those are two different follow-up conversations, and today you have no way to tell them apart. Retail splits on discount versus premium messaging, telecom on upgrade versus bundle, B2B on security versus productivity.

There’s a sharper version of this once a test concludes. You now know which experience won. Everyone who saw the losing one and didn’t convert is a list of people who got your weaker argument, and you can follow up with the message you just proved works better. You already paid for that traffic. The only thing left is deciding not to waste half of it.

Suppression is the underrated half

Not every audience exists to market to someone. Sometimes the valuable one is the list you stop talking to.

If a visitor just got hit with an aggressive acquisition offer on site, you may not want them receiving a second aggressive offer through paid media an hour later. Or you’ve got a test running and you’d rather no other campaign contaminate it while it’s live. An audience of people currently exposed to that activity, suppressed everywhere else, solves a problem that’s otherwise unsolvable.

This matters most in organizations where Target, paid media, email, and AJO are run by different teams. The customer doesn’t know or care about your org chart. They just notice the brand won’t stop talking.

Where journey orchestration comes in

With AJO, audience qualification events can fire when a profile enters or exits an audience. So: visitor receives Experience B, doesn’t convert, later behavior qualifies them for an audience, and that qualification drives what happens next in their journey.

One caveat worth being honest about, and it’s more specific than people expect. AEP only evaluates a rule referencing a single event in real time when the time window is under 24 hours. “Saw Experience B in the last 30 days” is a batch audience evaluated on the daily cycle, not a streaming one, no matter how the diagram looks. Even for streaming audiences, edge-to-hub propagation runs on the order of 15 to 30 minutes before a journey can act. Design for the evaluation method you’re actually going to get.

Also worth knowing: audience qualification activities only work with audiences built from segment definitions, which is what Segment Builder produces. Composed or uploaded audiences don’t trigger them.

The strategic point holds either way. Target exposure becomes something other Adobe applications can act on.

The loop closes

The architecture most teams have today stops halfway:

AEP → Audience → Target → Experience

What it can be:

AEP → Audience → Target → Experience → AEP → New Audience → Next Experience

RT-CDP gives Target context. Target makes a decision and delivers. That decision becomes an event in the customer’s history. RT-CDP combines it with everything else and it shapes the next decision, which doesn’t have to happen in Target at all. It could be AJO, paid media, a CRM, or a call center app.

The practical consequence is that experimentation starts producing audiences instead of only producing reports.

How you’d actually build it

The mechanics are above. The part people skip is downstream of them: data sitting in the Data Lake is not available for segmentation. It has to be modeled in an Experience Event schema and written to a Profile-enabled dataset before RT-CDP can touch it. If you get that wrong you’ll have a beautiful dataset and no audiences.

I’d start deliberately small:

• Activity ID and name
• Experience ID and name
• Timestamp
• Offer information, if it’s useful to you

Then let real use cases pull you further.

Two things to watch as you scale it up. Volume is real, since every rendered activity produces a display event and most of your traffic is anonymous, so keep an eye on profile counts and set an event expiration on the dataset. And none of this backfills. The audience starts accruing the day you turn it on, so if there’s a test coming that you’ll want to build from, get this live before it launches.

And no, you don’t need an audience for every experience you ever run. That turns into a swamp fast. The goal is to make exposure available as a building block, then build audiences when there’s a business reason. Nobody needs an audience off a button color test. A test involving pricing, eligibility, offers, or positioning is a different conversation.

The filter I’d use: would knowing what we intentionally showed this customer change what we want to do with them next? If yes, it belongs on the profile.

The bigger prize is the rest of the Target profile

Activity and experience exposure is the obvious starting point. It’s not the most valuable thing sitting in Target.

Target has been building visitor profiles for years, and a lot of that can be exposed through response tokens. Built-in values like category affinity, days since last visit, session data, and active activities, plus custom profile attributes, profile script values, and Customer Attributes.

Most mature Target implementations have accumulated attributes along these lines:

user.productInterest = mortgage
user.highIntent = true
user.lastProductViewed = checking
user.cartAbandoner = true
user.pricingPageVisits = 4
user.engagementScore = 8

Some passed in from the site, some calculated by profile scripts that run on Target requests and maintain state across visits. Adobe’s documented example is cart abandonment, but plenty of teams have built far more involved logic than that.

Historically all of it existed for one reason: make a better Target decision. Response tokens give you a second option.

Category affinity is the cleanest example. Target watches which categories a visitor engages with and can expose both the top category and the top five. Useful inside Target. Much more useful in RT-CDP, where “strong outdoor furniture affinity” combines with loyalty status, recent email opens, and Target exposure into an audience like high outdoor furniture affinity + saw the patio experience + no purchase. That’s a meaningfully better audience than “visited the outdoor furniture page,” and Target did the hard part.

Profile scripts are where I’d look next, and probably where the most value is hiding. If a script has been quietly setting user.mortgageIntent = high based on cross-session research behavior, that signal is currently trapped. Expose it and RT-CDP can build high mortgage intent + saw the rate experience + no application started, an audience that qualifies for an AJO journey, gets an educational mortgage email instead of a generic checking promo, gets reinforced in paid media, gets continuity on the next site visit, and gets suppressed from acquisition messaging the moment they actually apply.

Intent scores follow the same pattern. A profile script that assigns points for product views, pricing page visits, comparisons, and quick return visits produces a running score Target already maintains. Expose it and RT-CDP can combine that score with CRM data, offline purchases, call center interactions, and mobile behavior. Intent score above 8 + no purchase + Experience B exposure is a very different retargeting list than anything built from URL history.

Preferred messaging may be my favorite. If someone consistently engages with the “save time” message across three tested value propositions, you can maintain user.preferredValueProposition = convenience. Send that to AEP and the next AJO email doesn’t have to guess, paid media doesn’t start from zero, and the call center app can potentially know which benefits this customer responds to. That’s experimentation turning into organizational learning at the individual level.

Abandoned journey state rounds it out. Started a quote, started an application, used the calculator, viewed the premium plan, returned to pricing three times. Combine any of those with exposure and you get audiences like started quote + saw the promotional experience + didn’t finish, or used the mortgage calculator + high intent + no application.

The combination is the point

The strongest audiences won’t come from profile data or exposure. They’ll use both.

• High intent + received Experience B + no conversion
• Outdoor furniture affinity + saw free shipping + no purchase
• Existing customer + saw the upgrade experience + no upgrade
• Repeat visitor + premium experience + added to cart + no purchase
• Used the mortgage calculator + high intent score + saw the rate experience + no application

At that point you know who the person appears to be, what they’ve been doing, what you decided to show them, and what they did afterward. That’s a complete picture, and almost nobody has it today.

To be clear about the architecture

None of this makes Target your CDP. It shouldn’t be. AEP is where enterprise identity, events, governance, and activation belong, and I’m not suggesting otherwise.

But years of Target implementations have produced profile logic built specifically to understand digital behavior well enough to personalize against it. Leaving all of that isolated in one application is a waste, and rebuilding it in AEP before you can use any of it is a project most teams will never get funded. Response tokens are a practical middle path: expose the signals that matter, map them into XDM through the datastream, use them everywhere.

I wouldn’t send every Target attribute into AEP. That’s just noise with extra steps. I’d ask a narrower question:

What does Target know about this visitor that would change a decision made somewhere other than Target?

Those are the attributes worth moving. And once they’re in the profile alongside activity and experience exposure, Target stops being a destination for RT-CDP audiences and starts being one of its better sources.