Best Practices for Building Schemas in Adobe Experience Platform
It‘s intimidating when you are confronted with a blank canvas in Adobe Experience Platform (AEP) such as the example shown in Figure 1. However, we assembled the following best practices for building schemas to lessen your learning curve.
Figure 1: Blank Canvas for Creating Schema in the AEP UI
Let’s start with our first pro-tip. Before you begin to add pieces to your canvas, we recommend that you know your base classes.
Best Practice: Know Your Base Classes
Explore and familiarize yourself with all the fields and their types, which AEP provides via the XDM Individual Profile and XDM ExperienceEvent classes. In most cases, they will address the majority of your use cases. In other words, use the out of the box tools first, before reaching for custom builds.
What are the fields in the XDM Individual Profile and XDM ExperienceEvent classes? Before we talk about that, let's cover some basics, starting with the schema.
What is a Schema?
A schema describes the format and structure of data using a set of rules. The goal of the schema in AEP is to normalize data structure and type because ingested data sets can come from multiple systems. A schema must be created to describe the incoming data before AEP can ingest the data.
Schemas in AEP are based on an XDM system, a data standardization initiative from Adobe, and used in various applications within their ecosystem.
One of the advantages of XDM schemas is that they allow for an easy representation of embedded objects (think deep hierarchical object structure) within the schema instead of the heavy JOIN statements used in a traditional relational database world.
What Are the Data Types in an XDM Schema?
An XDM schema can be one of two types of data based on data behavior:
1. Record data contains information about a subject's attributes. An example of record data is customer records in a database or the lead object in a CRM application.
2. Time series data type is a snapshot of an event, which includes contextual data. An example of time-series data is a visit to a webpage or a purchase of a product.
What are the elements of an XDM Schema?
Schemas in AEP consist of a base class and zero or more mixins*.
Class + [Mixin*] = XDM Schema
Figure 2: Elements of an XDM Schema
What is an XDM Class?
An XDM class sets forth the smallest number of properties a schema must contain in order to represent a particular data behavior, regardless of the data type.
Adobe provides two XDM classes in AEP that should represent most cases for creating schemas for record and time-series data behaviors:
1. XDM Individual Profile is a singular representation of the attributes of both identified and partially-identified subjects.
2. XDM ExperienceEvent describes a snapshot of an event, which includes contextual data.
When composing a schema in the AEP UI, the first action you will need to do is select a class. This brings us to our second best practice: Use standard XDM classes in AEP unless you have a very good reason for not doing so.
Best Practice: Use Standard XDM Classes in AEP
Although you will be able to define your own classes within the schema registry, we recommend that you use either the XDM Individual Profile and XDM ExperienceEvent. The reason being that for data sets to be merged into the unified profile, the schema describing the data set must be built using one of the standard XDM classes.
Let’s discuss the other elements of an XDM schema: mixins.
What are Mixins?
A mixin is a reusable component that groups together one or more data fields with similar functions. An example of a mixin would be profile subscription data. The profile subscription mixin has fields for data that you collect when a person signs up for a subscription, such as their contact information and their delivery preferences.
Mixins can belong to only one XDM class. If you create a mixin based on Record data behavior, it will only be available for schema using a Record data behavior class, such as the XDM Individual Profile.
Notice that the keyword in the description of a mixin is "reusable." Therefore, we recommend that you do not duplicate mixins, which can result in a chaotic environment.
Best Practice: Do Not Duplicate Mixins
When you’re at a point where you need to add more fields that your base class isn’t providing, explore the existing mixins, and try to find one that supports your needs. It’s easy to create new mixins every time, but that defeats the purpose of reusability across schemas in AEP.
Mixins are a group of data fields with similar functionality. Within the data fields, there’s a group of special fields known as Identity Fields.
What are Identity Fields?
There are certain fields in the schema that can be used to determine the record’s “identity.” For example, if you are ingesting CRM data, you may want to consider attaching the proper Identity type to certain fields like “email” or “lead id.”
Fields identified as “identity” will be used in the identity graph in order to help compose a unified profile, therefore identity fields are key to creating a 360-degree view of your customers. Before you begin to build your schema, we recommend that you define unique identities specific to your organization.
Best Practice: Consider Unique Identifiers Specific to Your Organization
Examples of fields that are common and should be marked as Identity: email address, phone number, Experience Cloud ID (ECID), or CRM ID. You should also consider any unique identifiers specific to your organization, as they may be good "identity" fields as well. These can be login ID, loyalty ID, and reward ID.
Now that you are aware of the elements of an XDM schema, you could start to create one in the AEP UI that describes the data you are onboarding into AEP. We created the flow diagram below to help you visualize the process.
Figure 3: Schema Creation Process Flow
You should feel a great sense of accomplishment when you finish building an XDM schema for the first time. However, there are still some details of the XDM schema’s lifecycle that you should be aware of.
What Changes Can be Made After an XDM Schema is Created?
Changes can be made to an XDM schema as long as it does not have a dataset with ingested data associated with it. But once a schema has been used, some of its modifications are locked, as they are considered potential breaking changes. The following modifications cannot be made:
- Removing previously defined fields
- Introducing new mandatory fields
- Renaming or redefining existing fields
- Removing or restricting previously supported field values
- Moving attributes to a different location in the tree
The operations below though are still allowed at any time, even when a schema is “in use”:
- Adding new fields to an existing schema
- Making a mandatory field optional
The most important and irreversible change that you can configure for an “in use” XDM schema in AEP UI is to enable the Unified Profile option.
What is Unified Profile?
Unified Profile is an AEP service that evaluates and “stitches” data ingested in real-time, based on the identity fields of your schema.
If the schema you’re creating is intended for a unified profile inside the platform, you need to enable this option at the schema property and data set level. The unified profile can be enabled for a schema of the XDM Individual Profile class and XDM ExperienceEvent class. In other words, enabling a schema for a unified profile does not require your schema to be exclusive to the XDM Individual Profile class.
Once enabled, the change cannot be reversed in the AEP UI. However, all is not lost because you can use the API if needed to delete the schema, provided it is not used by any data set.
Best Practice: Use the API if Needed
As of today, a schema having the “Enable Unified Profile” toggle on, even when not in use, cannot be deleted via the AEP UI. Use the API and your schema ID to delete schemas that have Unified Profile On. Be careful and confirm they are not used by any of your datasets.
In the end, a schema is a structure that defines fields and types of data. In AEP, the data set is the object that receives the onboarded data. The next step after creating your schema is to create a data set from the schema. It is important during the data set creation that you enable “unified profile” for the data set as well.
Best Practice: Enable Unified Profile for Data Set Too
During the data set creation, enable “unified profile” for the data set. Oftentimes, schemas are created with the unified profile ON, but the user forgets to do so on the data set, which does not trigger the stitching and the real-time evaluation of data ingested for unified profile.
Once data is onboarded into the data set created from your schema and merged into the unified profile, you can use the data by creating audiences inside of AEP. We want to leave you with this last pro tip: Segmentation building requires data from an XDM Individual Profile and XDM ExperienceEvent schema.
Best Practice: Requirement for Segmentation
You need at least one XDM Individual Profile schema and one XDM ExperienceEvent schema with attached respective datasets in order to do segmentation in AEP.
There you have it. The best practices we have uncovered in our experience for creating schemas in AEP! Now get out there and start composing some well-crafted schemas in AEP.
