Adobe Solution Platform

Getting started with Adobe Experience Platform (AEP) can be overwhelming. It is not just a new product offering from Adobe but it is a whole new way of doing things. Data Collection is no longer limited to a tag manager or one data source, segmentation is sequential and across many sources and touchpoints, and orchestration opens the doors to activate anywhere anytime. The possibilities are endless but none of it would be possible if your data model and schema are not built right in AEP. In this blog post, we will share with you our best practices when it comes to Adobe’s Experience Data Model (XDM) especially when it comes to the schemas, principles, and main building blocks. 

The first, essential step in governing a common data model is, in many cases, also the most time consuming and challenging. Some common elements or benchmarks:

• Gather spreadsheets across different teams who manage content and marketing data in your organization
• Understand what external teams, such as agencies, are creating campaigns and metadata
• List what point solutions and use cases, including duplicates, your enterprise users
• Collaborate and agree upon universal taxonomy elements.

Experience Platform uses schemas to describe the structure of data in a consistent and reusable way. By defining data consistently across systems, it becomes easier to retain meaning and therefore gain value from data, which AEP provides via the XDM Individual Profile and XDM Experience Event classes. In most cases, they will address the majority of your use cases.

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.

• As the nature of digital experiences continues to evolve, so must the schemas used to represent them
• A well-designed schema is, therefore, able to adapt and evolve as needed, without causing destructive changes to previous versions of the schema
• Ensure that any revisions to the schema only result in non-destructive updates and changes
• In other words, breaking changes are not supported.

The first step in building a schema is to determine the concept, or real-world object, that you are trying to capture within the schema. Once you identify the concept you are trying to describe, you can begin planning your schema by thinking about things like the type of data, potential identity fields, and how the schema may evolve in the future.

An XDM schema can be one of two types of data based on data behavior, so you must choose the appropriate data type or class for the schema.

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. XDM Individual Profile is a singular representation of the attributes of both identified and partially-identified subjects.
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. XDM Experience Event 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. 

Although you will be able to define your own classes within the schema registry, we recommend that you use either the XDM Individual Profile or XDM Experience Event. 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.

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

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.

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.

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. The Data Access API supports the Adobe Experience Platform by providing users with a RESTful interface focused on the discoverability and accessibility of ingested datasets within the Experience Platform. 

During the data set creation, enable a “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 a 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 Experience Event schema. 

When creating a new segment, you are required to provide a segment name. The segment name is used to identify a particular segment amongst the collection built by Segmentation Service. Segment names should therefore be descriptive, concise, and unique. Next, merge rules.

Merge policies are rules used by Profile to determine how data will be prioritized and combined into a unified view under certain conditions. If a merge policy is not defined, the default Platform merge policy is used. If you would rather use a merge policy specific to your organization, you can create your own and mark it as your organization’s default.

Segmentation Service provides a consolidated workflow to build segments from Real-time Customer Profile data. In summary:

• Segmentation is the process of defining a subset of profiles from your profile store, allowing you to characterize behaviour or attributes of a desired marketable group. Segmentation Service makes this process possible.
• When planning a segment, keep in mind that a segment can be referenced from, and combined with, any other segment.
• A segment can be built from rules based on profile data, related time series data, or both.
• Segments can either be evaluated on-demand or continuously. When evaluated on-demand, all profile data is passed through the segment definitions at once. When evaluated continuously, data streams through segment definitions as it enters Platform.

The following best practices need to be followed in the ingestion process.

• Data to upload must be either in Parquet or JSON formats.
• A dataset created in the Catalog services.
• Contents of the parquet file must match a subset of the schema of the dataset being uploaded into.
• The recommended batch size is between 256 MB and 100 GB.
• Each batch should contain at most 1500 files.
• To upload a file larger than 512MB, the file will need to be divided into smaller chunks.

Adobe Experience Platform provides well-defined guarantees for completeness, accuracy, and consistency for any data uploaded through either batch or streaming ingestion. 

With above best practices with Adobe Experience Platform, you have a solution to help you manage your data governance, embedded in the very same tool with which you create the analysis, marketing solutions, and customer experiences that make use of the data you need to manage.