Data Warehouse and Data Feeds in Adobe Analytics
Data Warehouse and Data Feeds are the two raw-export paths out of Adobe Analytics: Data Warehouse delivers scheduled tabular reports computed from unprocessed hit-level data, while Data Feeds deliver the raw hit rows themselves, column by column, to a destination your team controls. Reports answer a question; feeds hand over the evidence. The export layer is also where implementations quietly rot: feeds keep delivering columns whose meaning drifted two redesigns ago, and the drift surfaces only when a downstream model disagrees with the UI.
Teams reach for these exports when the reporting interface stops being enough - when finance wants numbers reconciled outside the tool, when a data science team needs event-level rows, or when the warehouse everyone actually queries lives in BigQuery or Snowflake. The export layer is also where implementations quietly rot: feeds keep delivering columns whose meaning drifted two redesigns ago, and the drift surfaces only when a downstream model disagrees with the UI.
Data Warehouse vs Data Feeds
| Data Warehouse | Data Feeds | |
|---|---|---|
| What arrives | Aggregated tabular report answering a defined request | Raw hit-level rows with every configured column |
| Granularity | Rows per breakdown combination | One row per server call |
| Latency | Scheduled; large requests can take hours | Hourly or daily batches |
| Segments | Applied at request time (with compatibility limits - sequential segments unsupported) | Not applied - you filter downstream |
| Typical consumer | An analyst or a spreadsheet | A pipeline into a warehouse or lake |
| Failure mode | Request too broad, waits forever | Schema drift nobody documents |
What replaces them in Customer Journey Analytics
Customer Journey Analytics keeps the name and upgrades the semantics: CJA Data Feeds deliver hourly or daily event-level exports in Parquet, and unlike their Adobe Analytics namesakes the rows arrive with data-view processing already applied - identity stitching, persistence, and attribution are reflected in the export rather than left for your pipeline to reconstruct. Alongside them sit full-table exports from Analysis Workspace to cloud destinations, dataset-level exports from Adobe Experience Platform, and Query Service for SQL access. The migration-planning consequence: every job that consumes an Adobe Analytics feed today needs a mapped successor before the report suite goes quiet, or the BI layer breaks the week after cutover. Mapping feed consumers belongs in migration scoping, because the analytics tool is rarely the only thing drinking from the export.
FAQ
What is the difference between Data Warehouse and Data Feeds in Adobe Analytics?
Data Warehouse returns computed reports - aggregated tables built from raw data on a schedule - while Data Feeds return the raw data itself, one row per hit. Use Data Warehouse when you need an answer too large for the reporting UI; use Data Feeds when a downstream system needs the underlying events.
Do Data Feeds exist in Customer Journey Analytics?
Yes, under exactly that name: CJA Data Feeds export event-level data hourly or daily in Parquet format, with the data view's identity stitching, persistence, and attribution already applied to the rows. Migration planning should still inventory every current feed consumer and assign each one a successor path, because schemas and semantics differ from the Adobe Analytics feeds they replace.
Why do exported numbers differ from the Adobe Analytics UI?
Because the export and the UI often apply different processing: time zones, bot filtering, segment logic, and post-processing rules can each apply on one side and not the other. A reconciliation pass that explains every delta - not just notices them - is what makes an export trustworthy.