Report suites vs data views
A report suite is Adobe Analytics' container for collected data together with the settings that shaped it at collection time; in Customer Journey Analytics that job splits in two. A connection defines which datasets are joined - the nearer analogue to the report suite itself - and a data view sits on top as an adjustable lens, closest in spirit to a virtual report suite, applying its settings when data is read rather than when it was gathered. The container stops being the truth; the lens becomes configurable. The container stops being the truth; the lens becomes configurable.
That shift from collection-time to read-time settings is the deepest conceptual change in an Adobe Analytics to CJA migration, and its consequences run both ways. The generous half: a data view can re-interpret existing data retroactively - rename a dimension, change attribution, adjust session timeout - and history follows, because nothing was baked in. The unforgiving half: a wrong setting is equally retroactive, so data-view governance needs the same seriousness that report-suite admin work used to get, with fewer excuses.
The mapping teams actually need
| Adobe Analytics | Customer Journey Analytics |
|---|---|
| Report suite | Connection (which datasets) + data view (how they read) |
| Virtual report suite | Data view - the closest conceptual match |
| Report suite time zone and currency | Data view settings, changeable retroactively |
| Visit definition (30-minute inactivity default; shortened on request, also ends at 12h continuous activity or 2,500 hits) | Session settings per data view, freely configurable |
| eVar expiration and allocation | Persistence and attribution set per dimension, per data view |
| Multi-suite tagging | One connection reading multiple datasets |
FAQ
Can one connection have multiple data views?
Yes, and it should - that is the pattern that replaces virtual report suites. One connection defines which datasets are joined; each data view on top of it serves a different audience with its own sessions, components, and naming, all reading the same underlying data.
Do data view changes rewrite historical data?
No - they re-interpret it. The stored datasets never change; the data view applies its rules at query time, so a settings change appears to apply to all history instantly. That is powerful for fixing definitions and dangerous for uncontrolled changes, which is why data-view changes belong under change management.
What happens to my report suite settings during migration?
They become design inputs, not imports. Each setting - time zones, visit rules, expirations, classifications - has to be consciously re-expressed in connection and data-view terms, and some have no equivalent because the new model made them unnecessary. The settings inventory is one of the first documents to produce in a migration.