Two reports show different order counts for the same week and the meeting stops. Somebody says the data is broken. Almost always it is not: the rows underneath are identical, and the reports were built on two different interpretations of them.

In Adobe Customer Journey Analytics that is not a bug to be stamped out — it is the design. The interpretation layer is a first-class object called a data view, and once you know it exists, the argument changes from "whose number is right" to "which question was each report answering". That is a much shorter conversation.

Table of contents

1. What is a data view?
2. Why one dataset can honestly answer two questions
3. Attribution and allocation: the distinction that settles arguments
4. Integration across Adobe Experience Cloud
5. What to plan for: defaults, sharing and guardrails
6. Conclusion: why the interpretation layer needs an owner

What is a data view?

A data view is a container, specific to Customer Journey Analytics, that determines how to interpret data from a connection. It specifies every dimension and metric available in Analysis Workspace and which columns each draws from. Analysis Workspace projects are built on data views, not on connections — which is why the data view, rather than the schema, is where most reporting questions are actually answered.

The property that makes this safe is stated plainly by Adobe: any setting you select or change in a data view is retroactive and non-destructive. It does not change the underlying data: nothing is rewritten, nothing is reprocessed — the transformation happens when the report is read.

Which makes a data view cheap to create, cheap to change and cheap to get wrong once — a very different risk profile from a data warehouse, and the practical reason analytics teams move faster here than with an implementation-bound tool.

Why one dataset can honestly answer two questions

Because interpretation is separate from data, several data views can sit on one connection with genuinely different meanings — different component sets, session timeouts and attribution. One can present every dimension on last touch while another, on the same datasets, presents everything on first touch. Neither is wrong.

The same freedom extends to what organizations usually fight about. Time zone and calendar type are data view settings, so a retail team on a 4-5-4 calendar and a finance team on Gregorian months can read one set of data without converting anything by hand. Session timeout is a data view setting too — so "what counts as a visit" becomes a reporting decision rather than an implementation one.

Components are equally flexible. String fields become dimensions and numeric fields metrics by default, but a component can be switched between the two, metrics can be built from string fields and dimensions from numeric ones, and several components can come from one schema field. Each carries its own name, description and tags, and can be hidden from non-admin users.

That flexibility is also the trap: component names are what analysts see, and renaming one months later means renaming it in every conversation that already happened.

Attribution and allocation: the distinction that settles arguments

Two settings decide who gets credit, and they are routinely discussed as one.

Attribution is a metric setting. It customizes how dimension items get credit for success events, and it is configured with a model, a container and a lookback window. Allocation is a dimension setting — half of what Adobe calls persistence — and it determines which value to keep when more than one dimension item could persist in a single column at once.

Then comes the rule that explains most disagreements between two apparently identical reports. Used with a single dimension, a metric’s attribution overrides the allocation set on that dimension. Used with multiple dimensions, the metric’s attribution is applied on top of the allocation of each dimension. Same components, two different answers, and all that changed was adding a column to the table.

None of this should be avoided — it is what lets one dataset answer a marketing question and a finance question without a second pipeline. It does require somebody to own the definitions. Where a report still refuses to reconcile, a metric’s column settings show whether an analyst overrode the model inside the report.

Integration across Adobe Experience Cloud

A connection joins datasets in Adobe Experience Platform, which is what makes person-level reporting across channels possible in the first place — and also what makes the identity model a reporting concern. If the same customer resolves to three profiles, no data view setting will repair the count; the groundwork is in XDM schemas and Identity Service.

Downstream, the same definitions are inherited by everything else built on Adobe Customer Journey Analytics. The data preview inside a data view is the quickest sanity check available: it compares the view’s data against the connection’s as a percentage of the connection total over the last 90 days, and a preview that will not load usually means the connection is still backfilling.

What to plan for: defaults, sharing and guardrails

Persistence is off by default, and the default is not neutral. With persistence disabled, a dimension only relates to metrics present in the same event. A campaign dimension that appears to credit nothing is very often a dimension nobody enabled persistence on.

Empty values can overwrite good ones. Under most-recent allocation, if treat "No Value" as a value is enabled on the dimension, empty values overwrite previously persisting ones — two settings on the same dimension, one quietly undoing the other.

Shared components change everywhere at once. Edits to shared metrics and dimensions apply instantly across every data view they are shared to, and they cannot be shared across connections. That is the point of them and also the risk: a rename made for one team’s report lands in every other team’s report the same minute.

The guardrails matter at design time. An organization can have up to 2,000 data views; a connection supports between 500 and 1,000 depending on the package, and up to 100 datasets. The dataset ceiling is the one that shapes architecture.

Retroactive cuts both ways. Correcting a definition fixes history — and also changes every number anyone has already quoted from it. Treat a data view change as a release, with a note to the people who read the reports.

Conclusion: why the interpretation layer needs an owner

The settings themselves take an afternoon. What takes longer, and pays for itself repeatedly, is deciding how many data views the organization genuinely needs, writing component definitions in language the business already uses, and knowing which of attribution or allocation is answering a given question. Organizations that skip it end up with hundreds of data views and the same argument every month.

Softwhale designs this layer as part of the Adobe Experience Platform work underneath it rather than as a reporting afterthought: datasets and identities first, then the connection, then as few data views as the business actually requires. If two of your reports disagree today, that is a short and very answerable piece of work.