Deliver and maintain › Adobe Analytics and CJA
Adobe Experience Platform Integration
Customer Journey Analytics collects nothing. It reads data that is already in Adobe Experience Platform, described by a schema and held in a dataset.
So the question that decides a CJA project is not whether CJA is better. It is how your data gets into Platform. That is a collection project, and it is where the time goes.
Two routes into Platform
There are two ways Adobe Analytics data reaches Platform, and they answer different questions.
The Analytics source connector copies an existing report suite across. Each report suite you configure becomes its own dataset in the Data Lake, thirteen months of history come with it, and new hits keep flowing. Nothing on the website changes and nothing needs redeploying.
The Web SDK sends data from the page to the Edge Network, which forwards it to Platform and can forward the same event to Adobe Analytics as well. This is the route for anything built from now on, and it is a re-implementation of how the site collects data.
Most organizations end up running both for a period. The source connector supplies history a new system has no other way of getting, and the Web SDK supplies the future.
The Web SDK route is a project, and this site has a full guide to it
The difference in size between the two routes is easy to miss. The source connector is a configuration screen. The Web SDK is a re-implementation of how the site collects data, and it is the larger piece of work by a wide margin.
It is also the one that matters most, because Adobe treats the Web SDK as the long-term collection path for everything, not only for CJA. Once data flows through the Edge Network, adopting CJA becomes a matter of connecting the dataset rather than re-instrumenting the site.
That migration has its own section on this site. A complete thirteen step walkthrough, with a knowledge base of twenty two reference articles behind it, covering the parts this module can only summarize.
Web SDK Migration, start to finish
The whole migration as thirteen ordered steps, from taking inventory to decommissioning AppMeasurement. Written as a procedure to follow rather than a topic to read, with the architect's decision called out at every fork.
Create the schema
The XDM work this section summarizes in three paragraphs, done properly. Classes, field groups, the Analytics Full Extension, and why clean XDM is what makes CJA adoption cheap later.
Map your variables
Where every eVar, prop and event you own is translated into schema fields. This is the exercise that turns a variable map into a migration plan, and it is the step most projects underestimate.
Prove parity
How to show the new collection matches the old before anybody switches anything off. It is the same reconciliation problem a CJA migration meets, and the same way out of it.
One piece of advice from that guide is worth repeating here, because it decides the order of your projects. Stabilize Adobe Analytics on the Web SDK first, then treat CJA as a separate project after that. Teams that attempt both at once end up debugging a new collection method and a new reporting model in the same week, and cannot tell which one is producing the discrepancy.
What a schema does that a design document used to do
Platform holds data as Experience Data Model. Three ideas cover most of what a practitioner needs.
A class says what kind of thing a record is. Almost everything in analytics is an XDM ExperienceEvent, a time stamped record of something that happened. A field group is a reusable block of fields added to a schema, so commerce fields, environment details and web fields arrive as ready made components. An identity map is a field holding the identifiers for the person an event belongs to, each keyed by a namespace.
Here is what changes for somebody arriving from Adobe Analytics. The report suite carried numbered slots, and the solution design reference recorded what each one meant, because the product could not. In Platform the schema carries the meaning itself, in the system.
The design document does not stop being useful. It still records why a field exists, which requirement it serves, and who asked for it. What it no longer has to do is compensate for a product that cannot describe itself. Building a schema properly is its own step in the migration guide, alongside a reference article on the xdm object versus the data object, which is the decision that shapes everything downstream.
What the source connector gives you, and what it does not
The connector is the easiest part of a CJA project. You choose a report suite and a standardized Adobe Analytics schema is created for you. There is no schema design decision and nothing to map by hand.
Two details decide how much history you get. Thirteen months of backfill comes with each dataflow. Since 26 April 2023 the backfill in non-production sandboxes is limited to three months, which regularly surprises a team who tested in development and planned around what they saw.
Adobe states that certain types of data are segmented out by the source connector and never reach the Data Lake. Other rows can be segmented out again between the Data Lake and Customer Journey Analytics. So a report suite and its CJA counterpart will not agree on totals, before any data view setting is considered. Measure the size of that gap during a parallel period and write it down. The alternative is discovering it in a meeting where somebody has already decided the new system is broken.
The deeper limit is what the connector cannot give you. It brings across data that Adobe Analytics already shaped, with its collection-time decisions baked in. It is a good way to get history into CJA and a poor way to get the clean XDM that makes CJA worth having. That is the argument for the Web SDK route.
Where two sources stop agreeing
One report suite on its own is straightforward. The interesting problem starts when you combine sources, and it is a problem about documentation rather than technology.
Take the Kestrel and Co. implementation used throughout the SDR module. On the website, eVar19 holds Payment Method, and the design says it carries the name: Visa, PayPal, Klarna. The showroom till system also records how somebody paid, as a three letter code in a field called tender_type. The trade account system records it a third way, because designers are invoiced rather than paying at the point of sale.
In Adobe Analytics this never came up. Each system reported separately and nobody had to reconcile them. Bring all three into one CJA connection and those three meanings have to become one field, or the resulting dimension is nonsense.
Data Prep is where that reconciliation happens. The tooling is not the hard part. The hard part is that somebody has to know what each source means by payment method, and the only place that is ever recorded is a design document.
Put the variable map from every source side by side in one sheet, slot by slot, and mark every place two sources disagree about the same thing. That exercise predicts most of the effort in a multi source migration. It can be done in a morning by somebody with no Platform access at all, and it turns a vague statement about complexity into a countable list of decisions. Where a field is undocumented, treat that as a finding rather than a gap to fill in later. An undocumented variable that four teams quietly rely on is the most expensive thing in any migration.
Connections and data views
A connection names the datasets in play, and can hold up to a hundred of them. It is the plumbing: which data, from which sandbox, with backfill switched on or off per dataset.
A data view sits on top and decides interpretation. An organization can hold up to two thousand data views, and one connection can carry hundreds. That tells you how Adobe expects them to be used: freely, and as a way of serving different audiences from one set of events.
The difference between the two is worth learning early. A data view is cheap and reversible. A dataset is neither.
Field data types in a schema cannot be changed after data has been ingested against them. Define a numeric field as a string, or a date as free text, and the correction is to delete the dataset and recreate it. That takes the ingested history with it. This is the one irreversible mistake in the whole pipeline, and it is the strongest reason to have somebody who knows the data review every field type before the first load.
What the pipeline looks like
Data reaches Platform by the source connector or the Edge Network, a schema describes it, a connection selects it, and a data view decides what it means. Two of those four are effectively permanent and two are cheap to change.
The route you take decides how much of CJA you actually get. The source connector gives you CJA reading Adobe Analytics data, with Adobe Analytics decisions already applied. The Web SDK gives you CJA reading events, which is the thing worth having.
None of this has solved identity. Data from a website, an app and a call center can sit in one connection and still describe the same person three times over, because each source knows them by a different identifier. Cross-Device Analytics covers how Adobe resolves that in both products, and why the honest answer is still not one person.
Spread across three products, which is itself the lesson. Source connectors and schemas live in Experience Platform under Sources and Schemas, with field mapping under Data Prep. Connections and data views live in Customer Journey Analytics under Connections and Data views. Adobe Analytics is only the source, and nothing about this integration is configured from Admin > Report Suites.
This article focuses on the concepts, architecture, and practical guidance behind the topic. For the latest UI walkthroughs and step-by-step implementation instructions, use the links below. They leave this site and open Adobe's own documentation in a new tab.