Deliver and maintain › Adobe Analytics and CJA
What Is Customer Journey Analytics
A processing rule has been putting the wrong value into a variable since March. Somebody finds it in September. The fix takes four minutes.
The next question is what happens to the six months already collected. In Adobe Analytics, nothing happens to it. The rule ran at collection, it wrote what it wrote, and the original value was never stored. There is nothing to go back to.
Anybody who has worked in Adobe Analytics for a while has lived that conversation. It is the clearest example of the restriction this module is about, and of what Customer Journey Analytics changes.
Why this module exists
This module does not teach you to use Customer Journey Analytics. That is a body of work in its own right, and it would need its own curriculum.
What it does is answer three questions for somebody who already knows Adobe Analytics. What does Adobe Analytics have that CJA does not. What does CJA have that Adobe Analytics does not. And which of the restrictions you have been working around for years does CJA actually remove.
That last question is the useful one, because CJA is where Adobe is taking analytics. Knowing what it fixes tells you whether the move is worth making, and when.
When the decision gets made
CJA is usually described as a way to bring online and offline data together in one place. That is true, and it makes CJA sound like Adobe Analytics with more storage. The real change is the timing of decisions.
Adobe Analytics makes almost every decision when data arrives, then stores the result. Which channel gets credit. How long an eVar persists. Where a visit ends. What a processing rule rewrote. All of it is settled at collection, and what lands in storage is the answer rather than the question.
CJA stores the event and settles those questions when you run a report. Attribution, persistence, session definition and much of the shaping happen at report time. That means they can be changed, and a change applies to everything already collected.
Neither arrangement is better on its own. Deciding early is cheap to read and expensive to change. Deciding late is cheap to change and asks more of you at report time, because the report now depends on settings somebody chose.
The Adobe Analytics restrictions that CJA removes
This is the part worth reading closely, because each row is something you have probably worked around.
| The restriction in Adobe Analytics | What CJA does instead |
|---|---|
| A processing rule that was wrong is wrong forever. The original value was never stored | The raw event is stored. Change the setting and every month already collected is re-read |
| 75 props and 250 eVars, allocated in meetings, and a spare slot is a scarce resource | Any schema field can be a dimension or a metric. A data view supports 5,000 of each |
| One report suite per report. Combining two means multi-suite tagging, decided at collection | A connection combines datasets after the fact, with no change to collection |
| Digital behavior only. Call center contacts and store transactions live somewhere else | Any dataset in Platform, whatever it describes, as long as it shares an identifier |
| The visit timeout is fixed for the whole report suite | Session length is a data view setting, and two data views can disagree deliberately |
| Attribution is chosen when the variable is configured, and changing it does not reach backward | Attribution is set per component at report time, and changing it applies to history |
| Low Traffic bucketing hides values you never got to see | Every unique value is kept at full cardinality |
Read down the left column and you have a fair summary of what makes Adobe Analytics work frustrating. Read down the right and you have the argument for CJA, which is stronger than the marketing version because every line answers something specific.
eVars, props and events do not exist in CJA
This is the sentence that unsettles people who know Adobe Analytics well. In Customer Journey Analytics, eVars, props and events in the Adobe Analytics sense no longer exist.
A schema replaces them. Data arrives as fields defined in Experience Data Model, and any field can become a dimension or a metric.
Somebody who has just spent months learning eVars could reasonably feel the ground moved. It did, and less than it looks. The slot was an implementation detail of one product. What you were learning underneath it was that a value has a scope, that the scope has to be chosen deliberately, and that persistence decides who gets credit. All of that still applies. In CJA those choices are more visible, because somebody sets them in a data view where you can see them.
Allocation, expiration, merchandising and the products string are Adobe Analytics words for a smaller set of ideas. What a value applies to, how long it applies for, and what it is bound to. Those ideas are why eVars (Conversion Variables) is worth reading even if you are heading straight to CJA. What does not transfer is the numbering, the ceilings, and the housekeeping that came with them.
The data view holds the settings
A data view decides how raw events are interpreted. It sits between a connection, which names the datasets in play, and Analysis Workspace, which is the same reporting interface Adobe Analytics uses.
Inside it are the settings that used to be report suite configuration and processing rules. Which fields are dimensions and which are metrics. How a value persists and for how long. Which attribution model applies by default. Where a session ends. There are also derived fields, which do at report time what processing rules did at collection.
One consequence catches teams out. A single dataset can now produce several versions of the truth. Build two data views over the same events with different session timeouts and you get two different Sessions figures. Both are correct, both are defensible, and both can be quoted in a meeting by people who do not know the other exists. Governance stops being about who can edit a report suite and becomes about who can create a data view.
Visits is calculated in Adobe Analytics at processing time. Sessions is calculated in Customer Journey Analytics at report time. Adobe states that the two metrics may differ, and in practice they do. Anybody running both systems over the same period should expect the totals to disagree, and should say so before the comparison reaches somebody's desk. The alternative is a meeting about whether one of the two systems is broken. Neither is. They are answering slightly different questions.
What Adobe Analytics has that CJA does not
The trade runs both ways, and some of these surprise people late in a project.
| Absent from CJA | Status | Why it matters |
|---|---|---|
| Activity Map | Not currently planned | A whole way of looking at a page goes, and teams who use it daily will notice |
| Contribution analysis | Not currently planned | Explaining an anomaly becomes a manual investigation |
| Triggers | Never supported | Abandonment triggers have to be rebuilt elsewhere in the stack |
| Unlimited dimension persistence | Capped at 90 days | Long lookbacks that Adobe Analytics allowed have a ceiling here |
| People metric via Cross-Device Co-op | Never supported | Person level counting comes from stitching instead |
Set against the earlier table, that is the honest shape of the decision. CJA removes a long list of restrictions and takes away a short list of features, and which list matters more depends on how your organization actually works.
What CJA runs on
Customer Journey Analytics reads data held in Adobe Experience Platform. It collects nothing itself.
That is a real dependency. Data has to be in Platform first, described by a schema, sitting in a dataset. Which means the practical question is not whether CJA is better. It is how your data gets into Platform, and that is a collection project rather than a reporting one.
There are two routes, and one of them is a significant piece of work with a guide of its own on this site. Adobe Experience Platform Integration covers both, what a schema now does that a design document used to do, and the one mistake that cannot be undone.
In a different product, reached from the same place. Customer Journey Analytics has its own entry in the Experience Cloud application switcher. Inside it, the left navigation carries Connections, Data views and Workspace. That Workspace is the same interface Adobe Analytics uses, which is deliberate, and it is why an experienced analyst is productive on day one and confused on day two.
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.