Since joining Adswerve, I’ve had dozens of conversations with Adobe Analytics (AA) customers who are considering Adobe Customer Journey Analytics (CJA). Honestly, it’s one of my favorite parts of the job and a privilege to guide so many organizations through such an important decision. Across these discussions, one topic consistently emerges as a sticking point: the absence of a post-processed data feed in CJA. For many, this ranges from a serious concern to a complete non-starter.
The lack of post-processed data feeds has been a topic of concern for existing and potential Adobe CJA customers over the past few years. It’s become one of the primary reasons that AA customers hesitate to make the move to CJA. The dialogue has grown loud enough that Adobe is actively exploring options to emulate some version of a post-processed feed for CJA.
To be clear, CJA does have a data feed from Adobe Experience Platform (AEP), which can be scheduled and batched into your data warehouse, similar to AA data feeds. What’s missing are the post eVar columns with persistence, marketing channel processing and visit-level calculations. Instead of making these calculations available in the AEP export, CJA will surface those from the tool itself.
While it’s great that Adobe is listening to their customers and pursuing a version of post-processed data feeds for CJA, I want to discuss why it’s not currently available in CJA, why expectations for it should be measured and potentially challenge some assumptions behind the need for post-processed feeds in the first place.
When an AA customer raises concerns about losing post-processed data feeds, I like to remind them of the realities about those feeds:
The AA data feeds have been around for the better part of two decades. Making them usable often requires significant data engineering resources to clean, document, monitor and maintain them. Without that investment, the tables can become an overgrown, underused swiss cheese that only a handful of highly paid specialists know how to query effectively.
Despite all that, teams have built complex data infrastructures around them to drive critical business use cases. While valuable, these legacy approaches are increasingly expensive and out of step with modern data practices.
In the past decade, cloud computing has transformed data warehousing and processing. In particular, a greater emphasis has been placed on the value of raw, unprocessed data.
Why raw data? Because when data is processed before storage, it’s frozen with the business logic and assumptions from that moment. If the assumptions or logic change — and they almost always do — it becomes nearly impossible to apply updated logic to historical data. AA users know this well: changes to persistence or processing logic only apply from the date of the change, moving forward.
The revolutionary change unlocked by scalable cloud architecture is that assumptions don’t have to be embedded in the data ingestion. In fact, you’d prefer that they aren’t. Ideally, data is stored purely as facts with no assumptions tied to them. This allows the processing and transformation to be applied dynamically at query time. As assumptions and business logic change, a lightweight and flexible transformation layer over the raw data can change with them.
This is also why CJA doesn’t have a post-processed data feed. CJA is the processor. It’s designed to evolve and change with business needs, unlike a post-processed data feed, which can only produce assumptions based on the data collected at the time.
With this architectural pattern, CJA itself becomes the source of truth for all journey-related metrics. Beyond the Analysis Workspace UI, Adobe has unveiled both an API and a SQL connector to tap directly into the CJA reporting engine. Rather than exporting transformed data, you can directly query the source of truth.
Adobe has made several enhancements to help facilitate a direct connection to CJA to fulfill use cases. For example, it was always a challenge to recreate segment logic from AA when querying the data feeds. To help standardize how data is accessed, both the API and SQL connector can reference a segment ID created and shared via CJA. Additionally, CJA doesn’t have “low traffic” sampling, ensuring that all results are returned for even high-cardinality dimensions (IDs, URLs, etc).
From a governance perspective, the goal is for CJA to have the exact same calculations and definitions used universally across journey-related use cases.
Instead of exporting data as a byproduct of web analytics tools, more organizations are moving toward leveraging raw data and flexible transformation as part of a broader evolution toward treating data as a product. This means defining it with internal standards, optimizing it for downstream consumers and building durable pipelines that reflect their business logic, not the quirks of a particular vendor.
This mindset also unlocks composability, or the ability to “bring your own data” and swap tools in and out as your needs evolve. When you define and possess raw data in your business terms, it can be brought to any tools that provide processing, not just CJA. Whether it’s for modeling, reporting or activation, your data stack should be portable and your architecture should support it.
Focusing on use cases is the best way to tackle the downstream impacts of no longer having access to a post-processed data feed. Assembling an inventory of those use cases and understanding the exact data that consumers are using will help guide which method of accessing data will work best.
It can be surprising how few use cases, such as propensity scoring, actually require persistence. Or how many business intelligence (BI) dashboards can be satisfied with aggregated data via the CJA SQL connector. Or how many use cases just aren’t being used anymore. Regardless, assembling that exhaustive list of use cases will help you evaluate the impact of a move to CJA, and help prioritize them should you go ahead with a move.
If a use case truly can’t be provided by accessing CJA directly, as mentioned, there is a raw data feed coming from AEP. As a batch feed, it’s still slow (and frustratingly slower than AA, with a 3-hour frequency), but it will have semantic naming instead of props and eVars, and it outputs the raw underlying data in modern JSON or Parquet formats.
The resources that once went toward deciphering and propping up the AA data feeds can now be directed toward building a custom, flexible transformation layer tailored to the business use cases that couldn’t be directly addressed with CJA.
Earlier, I mentioned that Adobe may be exploring a next-generation data feed option in response to customer feedback. First, it should be made clear that, as of this writing, nothing is official. There’s a distinct possibility that a CJA data feed doesn’t materialize. Second, it’s pretty safe to say that if this functionality is developed, it will not be a 1:1 recreation of the AA data feeds.
A new CJA take on data feeds will reflect the dimensions and metrics configured in CJA and will require a new schema. That new schema will significantly impact your data warehouse pipelines and necessitate a refactor to account for the new output.
Finally, this could be a significant case of “be careful what you wish for.” In the event that CJA does add a post-processed CJA data feed that exports to your data warehouse upon ingestion, remember: CJA’s processing layer continues to evolve even after the data is exported.
Imagine a scenario where someone updates the Marketing Channels logic in CJA, conveniently fixing an issue that had been breaking reports for the last few months. Meanwhile, the historical data in your warehouse, exported weeks ago, is frozen in time with the now-outdated processing.
In old AA, both the tool and the data feeds were equally wrong. But with CJA’s flexible processing layer, discrepancies between CJA and your data warehouse can erode trust. Forcing an old-fashioned data feed out of a modern CJA could introduce more governance issues than it solves.
AA data feeds had a good run. They were a scrappy solution for enabling more advanced use cases in a pre-cloud world. They became available in a time when SaaS solutions passing around TSV files wasn’t uncommon, but today their utility has a ceiling and a cost.
Today’s best-in-class data teams are not just exporting their event data; they design it. They aren’t focused only on recreating what they had. Instead, they’re reimagining how they collect, prepare and present data in more scalable, efficient and user-focused ways.
Rather than looking backward, view the move from Adobe Analytics to CJA as a chance to modernize your entire data strategy with a data-as-a-product mindset, modular architecture and dynamic transformation.
If you found this article valuable, I wrote an entire guide about how to leverage a data-as-a-product mindset to modernize your digital analytics: From Adobe Analytics to CJA: The Complete Guide. I highly encourage you to give it a read to learn how the move from AA can be more than just a migration, but a new way of thinking about how data provides value for your organization.