How to Integrate Adobe Campaign Classic with Adobe Experience Cloud

How I plan Adobe Campaign Experience Cloud integrations: Analytics, Target, Assets, shared audiences and Triggers, and what each one needs.

Executive Summary: Adobe Campaign Experience Cloud integrations connect Campaign Classic to Analytics, Target, Assets and shared audiences, and through Triggers to website behaviour. I explain what each integration actually does, what it needs before it can work, where I have seen projects stall, and the order I would connect them in for one retailer.

When a company buys Campaign Classic as part of a wider Adobe contract, someone usually promises that it “works with the rest of the Experience Cloud”. It does, but each Adobe Campaign Experience Cloud integration is a separate piece of work with its own prerequisites, and some are more useful than others.

Here I write about the integrations I see most in v7 projects: the shared visitor ID, Analytics, Target, Assets, shared audiences and Triggers. For each one I cover what it does, what it needs, and my honest view of when it is worth the effort.

What Adobe Campaign Experience Cloud integrations have in common

Every integration depends on two foundations. First, the Campaign instance has to be linked to your company’s Experience Cloud organisation, the customer entity that holds users and solutions. The integrations overview explains the linking and lists the available integrations. On hosted instances, Adobe does this with you. On-premise, expect configuration on your side and on Adobe’s.

Second, most integrations rely on the Experience Cloud ID service, which gives a visitor one ID across solutions. When a recipient generates tracking logs, Campaign stores the visitor ID in the @sourceID field of nms:trackingLogRcp, and other solutions recognise it when they share the same tracking domain (CNAME). If your tracking domain and your Analytics domain are not aligned, ID matching suffers and every integration built on it is weaker.

My first step on any integration project is to check both of these. Nearly every stalled project I have seen stalled here, not in the integration itself.

Adobe Analytics: measuring email traffic and importing segments

The Analytics connector links the two solutions through the Web Analytics connectors package. The Analytics connector page lists the prerequisites: the package must be installed, and the connector does not work with transactional messages (Message Center).

What it gives you:

  • Delivery indicators in Analytics. Campaign sends delivery data to Analytics, so you can see email-driven sessions and conversions alongside other channels.
  • Remarketing segments in Campaign. Behaviour segments from Analytics, such as visitors who viewed a product and left, come back into Campaign for targeting.

In my view, the first is the main reason to do it. Being able to show that email drove revenue, in the same tool the business uses for every other channel, changes how email is valued in budget discussions. Remarketing segments are useful too, but for real-time behaviour, Triggers are usually a better fit.

The practical work is in tracking. Links in Campaign emails need consistent campaign parameters so Analytics can attribute sessions. I agree a naming convention with the Analytics team before the first send, because changing it later breaks year-on-year comparisons.

Adobe Target: dynamic images at open time

The Target integration inserts an image that Target decides at the moment the email is opened. The Target integration page is clear about the limit: only static images are supported. The rest of the email is not personalised by Target.

In the email, you insert a Dynamic image served by Adobe Target, set a default image, a Target location name and any Campaign fields to pass as decision parameters. In Target, you create redirect offers, the audiences that decide between them and an activity that uses the location.

Where I find it worth it:

  • Location-based or weather-based hero images, where the right image depends on where and when the email is opened.
  • Offers that may expire between send and open, because Target can switch to a default after a date.

Where I would not bother: anything you can decide at send time with Campaign data. A conditional block in the email is simpler, cheaper and easier to test. Target adds a dependency at open time, so test the default image carefully. It is what people see if the call fails.

Assets: one library for email images

The Assets integration lets operators place images from a shared Experience Cloud library while editing an email or landing page. The shared assets page notes an important limit for on-premise customers: the integration is not available unless AEM Assets is also on-premise.

The benefit is governance. Brand teams approve assets once, and email designers use approved assets in their delivery templates without downloading and re-uploading them. On teams with strict brand control, that alone justifies it. On a small team that uploads ten images a week, it is a nice-to-have.

Shared audiences: Audience Manager and Experience Cloud Audiences

With the shared audiences integration, Campaign can import audiences from Audience Manager or Experience Cloud Audiences into lists, and export lists as shared audiences for other solutions. The audience sharing page describes two identifier types: the Visitor ID, which reconciles visitors with recipients, and the Declared ID, a reconciliation key you define.

The timings matter for planning. Adobe’s documentation says audiences imported from Audience Manager take 24 to 36 hours to synchronise, and audiences from Analytics have to be shared in Audience Manager first, adding more time. Each synchronisation fully replaces the imported data, and only segments are supported, not traits or key-value pairs.

This makes shared audiences a tool for strategic segments, not for reacting to behaviour. I use them for “high-value customers seen on the site” or for exporting a Campaign segment to suppress existing customers from paid media. For anything time-sensitive, Triggers are the better path.

Campaign and Experience Cloud Triggers: reacting to website behaviour

Triggers connect Analytics behaviour to Campaign through the pipeline. A trigger, such as cart abandonment, is defined on the Analytics side, and the pipelined process on the Campaign marketing server retrieves the events and processes them. The Triggers overview gives a typical response time of under an hour.

Two things to know before you plan around it. It is not available out of the box, so you implement it with Adobe. And it needs a valid organisation identifier and the right developer access in your organisation, which in a large company can take longer to arrange than the technical work.

Once it runs, Triggers are the most valuable integration on this list for most retailers. Cart and browse abandonment emails based on real behaviour are among the most effective automated messages I have worked on, and Triggers let Campaign send them without a separate tool.

On the Campaign side, a workflow processes the trigger events, matches them to recipients and sends the email. Treat it as a production workflow: monitored, with error handling and with a clear suppression rule so nobody receives three abandonment emails in a day. My workflow best practices apply directly.

Testing each Adobe Campaign Experience Cloud integration end to end

Each integration crosses at least two teams, so testing has to cross them too. I write a short test plan per integration and run it with someone from each side in the room, or at least on the same call.

Analytics. Send a delivery to a seed list, click the links from a seed inbox, and check that the sessions appear in Analytics with the agreed campaign parameters. Then check that the delivery indicators arrive. If the sessions appear but the attribution is wrong, the link parameters are the usual cause.

Target. Open a test email from the regions the activity targets and from one that it does not, and check that each shows the right image and that the default appears where expected. Test on a mail client that blocks images by default too, so you know what that recipient sees.

Triggers. Abandon a cart on the website with a known test profile and watch the event arrive in Campaign, then the workflow pick it up, then the email go out. Then repeat it twice in a row and check that the suppression rule holds.

Shared audiences. Export a small test list and check that it appears in the other solution after the documented delay. Do not test with a production segment you need tomorrow.

The point of all this is ownership. When something breaks six months later, the people who ran the test know where to look, and they know who on the other team to call.

Worked example: a retailer’s Adobe Campaign Experience Cloud stack

The hypothetical brief: an online retailer has Campaign Classic, Analytics and Target. Email reporting is done in Campaign and nobody outside the CRM team trusts it. Leadership wants cart abandonment emails, and the creative team wants seasonal hero images that differ by region.

My plan, in order:

  1. Foundations. Confirm the Campaign instance is linked to the organisation and that the tracking domain matches the Analytics setup for the ID service.
  2. Analytics connector. Install the package, agree link parameters and send delivery data to Analytics. This builds trust in email results first, which makes the next steps easier to fund.
  3. Triggers for cart abandonment. Work with Adobe on the pipeline, define the trigger in Analytics, and build the Campaign workflow with a suppression rule and a typology. I would also run a control group, so the business can see the uplift, not just the sends.
  4. Target images. Last, because it is the least critical. Start with one hero image location by region, with a strong default.

I would skip shared audiences for now. Nothing in the brief needs them, and adding them would only add another synchronisation to monitor.

Where Campaign Experience Cloud projects go wrong

  • Treating “Experience Cloud” as one project. Each integration needs its own owner and test plan.
  • Ignoring the ID service and tracking domain. Matching suffers quietly.
  • Using shared audiences for real-time use cases. The synchronisation delay rules them out.
  • No default for Target images. A failed call shows a broken space.

Frequently asked questions

Do I need every Adobe Campaign Experience Cloud integration?

No. Choose by use case. For most retailers, Analytics and Triggers deliver the most value. Target and Assets depend on how the creative team works.

Can the Analytics connector report on transactional emails?

Not through the connector. Adobe’s documentation states it is not compatible with Message Center, so plan separate tracking for transactional messages.

How long does a shared audience take to appear in Campaign?

Adobe documents 24 to 36 hours for Audience Manager segments, and longer for Analytics segments shared through Audience Manager. Plan campaigns around that.

Is the Target integration the same as personalising content in Campaign?

No. Target only decides a static image at open time. Campaign personalises everything else in the email at send time.

The integrations are worth doing when each one has a clear use case and an owner. I start with the one that builds trust in email results, because it makes the case for the rest. My next post looks outside Adobe, at integrating Campaign with CRMs and legacy systems.

Last updated on 26 October 2026

Adobe Analytics Adobe Campaign Classic Adobe Experience Cloud Integration

Share this article

Leave a Reply

Your email address will not be published. Required fields are marked *