Architect your schema for use with Customer Journey Analytics upgrade-schema-architect

Adobe recommends creating a custom Experience Data Model (XDM) schema for Customer Journey Analytics when implementing Adobe Experience Platform Data Collection. Creating this schema is typically done before any implementation changes or code is touched. A custom schema lets you design a concise, organization-specific data contract without inheriting constraints from Adobe Analytics. See Choose your schema for Customer Journey Analytics to learn more about the types of schemas available to your organization.

Schemas are intended to be polished versions of how you want your data to be structured long-term. Changes to schemas are expensive because they impact data collection, validation, and downstream services. You can add to schemas over time as business requirements allow; however, schema fields cannot be removed once data starts flowing into them.

Compare schemas to data views

The data pipeline for Customer Journey Analytics contains separate areas for data collection and data interpretation. When upgrading from Adobe Analytics, a common misstep is trying to recreate props and eVars with their behaviors in XDM. Instead, use the Web SDK to collect the data and use Data views to determine how that data is interpreted in reports.

Compare schemas to Adobe Analytics data collection

The Experience Data Model that Customer Journey Analytics uses enables significantly more flexibility than most other Analytics solutions (including Adobe Analytics). Establishing a solid schema is your organization’s opportunity to avoid carrying forward constraints that exist in other Analytics products.

Establish a schema using common attributes

A unified schema across channels becomes possible when you standardize a set of reusable attributes that appear across many events. Some examples include:

The key is to standardize what the field represents regardless of channel. Avoid modeling the same concept differently across channels unless they truly represent different concepts. For example, it might be wise to avoid having separate schema fields for web campaign IDs and mobile campaign IDs. Separate schema fields make it more difficult to establish cross-channel return on ad spend data. If a differentiation is required in reporting, you can segment by channel or concatenate multiple fields to provide that distinction. The same schema field can be used in any number of dimensions or metrics.

A practical way to support multiple channels while keeping a single schema strategy is to use a core + extensions pattern:

This pattern supports a single organizational schema strategy without forcing teams to populate unnecessary fields.

Prefer standard field groups where they fit

Adobe recommends using standardized field groups where they match your needs, and extending with custom fields for organization-specific concepts.

Standard field groups typically help you:

Custom fields are appropriate when:

Determine how metrics are counted

In Adobe Analytics, many teams treat the events variable as the only means to track metrics. In Customer Journey Analytics, you can track metrics in multiple ways depending on what you need to count and how you want to interpret it.

When architecting a schema, stick to facts. For example, error.type = "validation", user.isLoggedIn = true, checkout.step = "shipping". Define metrics in the data view as counts and filtered counts over those facts. For example:

Maintain parity with Adobe Analytics during transition without schema baggage

Some organizations need to continue Adobe Analytics reporting while upgrading to Customer Journey Analytics. You can maintain parity without introducing Analytics-specific artifacts into your long-term schema design using the following approach:

Identify stakeholders and define ownership

Schema design succeeds when field meaning is agreed upon and maintained. While organizational structures vary, the following roles commonly participate:

Define a clear owner for schema changes. A stable schema with disciplined change control prevents downstream breakage and reduces rework. Consider using a tracking governance workflow or tooling to democratize requests and manage change control over time.

Privacy and governance considerations

Schema design should reflect privacy and governance expectations, according to your organization’s privacy policies. Consider the following points as you architect your schema:

Next steps

Once you have established and agreed upon a schema architecture, you can begin creating it in Adobe Experience Platform. See Create a custom schema to use with Customer Journey Analytics for more information.