A data view sits on top of a Customer Journey Analytics (CJA) connection. A connection combines one or more datasets from Adobe Experience Platform and connects it to CJA. The data view specifies how you want to interpret elements of the data in the connection, such as metrics, dimensions, sessions, etc… Data views are defined in preparation for reporting on the data in Workspace.
Any settings that you select or change in a data view are retroactive and non-destructive. In other words, they do not permanently change your underlying data .
You can create different data views for the same connection, with very different sets of components (dimensions/metrics). Or create data views with different settings for visit timeout, attribution, etc… For example, you could have one data view where all dimensions are set to Last Touch, and simultaneously, another data view (based on the same dataset) with all dimensions set to First Touch.
Workspace projects in Customer Journey Analytics are based on data views.
The latest update to data views gives you a lot more flexibility in what you can do with data views. These enhancements let you spontaneously change schema element settings in Data Views, without having to change the schema in Adobe Experience Platform or re-implementing your CJA environment.
You can change a component from a Metric to a Dimension and vice versa. You can create metrics from string fields or create dimensions from numeric fields. This makes your life easier, because you don’t have to create a numeric field in your XDM schema for every metric you want. Instead, you can just spontaneously create it in the data views dialog. Here are some examples:
You can create multiple metrics with different attribution models or with different lookback windows from the same schema field.
You can edit the ID of a component - this is used for cross-data-view compatibility. The component ID is what the reporting API uses to identify a specific metric or dimension. Because you can arbitrarily create many metrics or dimensions from one XDM field, we will give you the option to define your own component ID. As a result, a metric you use in one Workspace project can be compatible across data views (and the API), even if they are based on totally different fields from different connections or data views or from a different schema in XDM.
You can specify the friendly component name that will appear in Analysis Workspace. By default, this name is inherited from the schema display name, but you can now overwrite it for this specific data view.
You can view more schema-related information about components , such as: which dataset type (event, profile, lookup) it came from; which schema type (string, integer, etc.) it came from; and its schema path (the XDM field that it is based on).
You can tag a component to make searching for it in Workspace easier.
You can hide a component in reporting. Some metrics and dimensions settings require a second metric or dimension for configuration (like metric deduplication or purchase deduplication, for example). This allows you to define a metric or dimension that can be used in the settings of another metric or dimension without being exposed directly in reporting (such as purchase ID).
You can apply formatting to a metric, such as showing decimal, time, percent, or currency; specifying decimal places; showing upward trend as green or red; and specifying currency options.
You can create a metric or dimension based on only some of the values in the schema field. For example, if you wanted an “errors” metric, you could create a metric from the page name field but only include pages that contain the word ‘error’. The errors metric created from this is supported by filters, insertable into calculated metrics, and it works with attribution, flow, fallout, etc.
For dimensions, you can automatically include or exclude only certain values within a specific field. For example, if a developer sent in a wrong value of
dev mistake into a field, you could easily exclude it from reporting using an exclude rule and it will behave as if it never existed in the data.
You can rename your containers in a data view and have those renamed containers surface in any Workspace project that is based on that data view.
Some data view settings can be overridden in Analysis Workspace at the project level, others cannot.
If you delete a data view in Customer Journey Analytics, an error message will indicate that any Workspace projects that depend on this deleted data view will no longer work.