Editor's note: Originally published July 22, 2025. Reviewed and updated September 2026 by Jake Winter to reflect the release of Adobe Customer Journey Analytics data feeds, which entered Limited Testing after this article first appeared.
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 Customer Journey Analytics. 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 Customer Journey Analytics customers over the past few years. It's become one of the primary reasons that Adobe Analytics customers hesitate to make the move to Customer Journey Analytics. The dialogue grew loud enough that Adobe began exploring options to emulate some version of a post-processed feed for Customer Journey Analytics.
To be clear, Customer Journey Analytics does have a data feed from Adobe Experience Platform (AEP), which can be scheduled and batched into your data warehouse, similar to Adobe Analytics data feeds. What was 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, Customer Journey Analytics will surface those from the tool itself.
| UPDATE Since this article was published, Adobe has shipped Customer Journey Analytics data feeds, currently in limited testing and delivered in hourly or daily batches. They're built from your data view rather than a static variable list, and they carry the persisted values that used to live in post columns. |
While it’s great that Adobe is listening to their customers and pursuing a version of post-processed data feeds for Customer Journey Analytics, I want to discuss why it’s not currently generally 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 Adobe Analytics customer raises concerns about losing post-processed data feeds, I like to remind them of the realities about those feeds:
The Adobe Analytics 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. Adobe Analytics 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 was built without a post-processed data feed. Customer Journey Analytics 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, Customer Journey Analytics 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 Customer Journey Analytics to fulfill use cases. For example, it was always a challenge to recreate segment logic from Adobe Analytics 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 Customer Journey Analytics. 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 Customer Journey Analytics 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 Customer Journey Analytics. 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 Customer Journey Analytics, 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 available from AEP. As a batch feed, it's still slow (though export increments now go as tight as one hour), 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 Adobe Analytics 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 Customer Journey Analytics.
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, Adobe has since made this official, though it's still in limited release. Second, as expected, it isn't 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." Even with the new feeds, 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 Customer Journey Analytics, 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 Adobe Analytics, both the tool and the data feeds were equally wrong. But with CJA's flexible processing layer, discrepancies between Customer Journey Analytics and your data warehouse can erode trust. Forcing an old-fashioned data feed out of a modern Customer Journey Analytics could introduce more governance issues than it solves.
Adobe Analytics 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 Customer Journey Analytics 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 Adobe Analytics can be more than just a migration, but a new way of thinking about how data provides value for your organization.