Schemas

In this exercise, you’ll configure the required XDM schemas to classify profile information and customer behaviour. In every XDM schema, you’ll also have to configure a primary identifier.

Before you start configuring XDM Schema's and setting Primary Identifiers, we need to think about the business context of what we're trying to do:

There are 2 types of data that we want to capture:

The question Who is this customer? is a very open question that has many answers. When your company wants to see this question answered, you’re looking for demographic information like First Name, Last Name and Address. But also for contact information like an Email Address or a Mobile Phone Number. And also for information linked to Language, OptIn/OptOut and maybe even Profile Pictures. And finally, what you really need to know, is how we’ll be identifying this customer in the various systems that your company uses.

The same thing goes for the question What does this customer do?. It’s a very open question with many answers. When your company wants to see this question answered, you’re looking for any interaction a customer has has had with any of your online and offline properties. Which pages or products have been visited? Has this customer added a product to his cart or even purchased an item? What device and browser has been used to browse the website? What kind of information is this customer looking for and how can we use that to configure and deliver a delightful experience to this customer? And finally, what we really need to know, is how we’ll be identifying this customer in the various systems that your company will use.

From a Schema perspective, the type of data to be collected controls which class the schema needs to be. The question: Who is this customer? is something that we define in the Class Individual Profile.

If you want to collect data to answer the question What does this customer do? then we need to use the class Experience Event.

Click on Schemas in the menu on the left side of your screen. You’ll see the list of available Schemas. To create a new schema, click on the button Create schema button on the top right.

Select Individual Profile and click Next

Name your schema using the following pattern:

[your surname] - Demo System - Profile Schema for Website

Replace your surname with your own. As an example:

gillies - Demo System - Profile schema for website

You can give your schema a description if you wish, then click finish to create the schema.

Click on + Add next to Field groups to add field groups to your schema.

You can create new field groups to match your company requirements but Adobe also provides many out of the box field groups to save yourself some time. For this exercise we'll use some of these to store:

Search for these field groups and add them to your schema, once you've checked all 4 click Add field groups in the top right:

You can now see your updated schema, clicking on each field group will highlight the fields that have been added by that field group. Click on Save in the top right to save the changes to your schema.

Click on Save in the top right to save the changes to your schema.

Now we need define which fields in our schema will store the values used to identify our customers. Click on the Profile Identities field group. First notice that this field group top level object is _adobedemoamericas275 this is the Adobe Experience Platform tenant name, all custom fields and custom field groups will live under a tenant name branch to differentiate them from Adobe provided default schema fields.

Expand the object to see the fields below it. You'll find in here a number of identity fields. We need to do three things:

Since this is a Website Registration schema, we're going to define the ecid as the primary id, since it will always be present on the website. Click on the ecid field and scroll to the bottom of the field properties on the right hand side. Tick the Identity checkbox, tick the Primary Identity checkbox and set ECID as the Identity Namespace. Then click Apply.

In most cases our schemas will contain more than one identity field, this is how we start to build relationships within our Identity Graph (more on this to be covered later).

Click on the crmId field and flag it as an identity with namespace Demo System - CRMID. Click Apply

Similarly click on the email field and flag it as an identity with namespace Email Click Apply.

You'll notice your fields have little fingerprint icons in them and the list of identities for the schema is shown in the left pane.

Click Save in the top right to save your new schema.

Now maybe you have some additional fields that you collect on your registration form that aren't included in our default field groups. You can add these to one of the existing field groups or you can create a new custom field group to manage them. Let's add a new field group:

Click the + Add button next to Field Group to start adding a field group.

Instead of reusing an existing Field group, you'll now create your own field group. You can do that by selecting Create New Field Group.

You now need to provide a Display Name and Description for your new Field Group. As the name for our schema, we’ll use this: [your surname] - custom profile field group

As an example, for surname gillies, this should be the name of the schema: gillies - custom profile field group. That should give you something like this:

Click the Add Field Groups button to add the newly created Field Group to your schema.

Your new Field Group is still empty, so now you’ll have to add fields to that Field Group. In the Field Groups list, click your custom Field Group. You now see a number of new "+" buttons appear.

On the top-level of your Schema, click the + button next to Untitled Schema.

On the right hand side you can see the properties of your new field, give your new field a name registration and set the type to Object. We're going to make it an object so we can add other fields below it. Make sure the field is assigned to your newly created field group.

Once you've set the properties, click Apply at the bottom.

You can see the new object is now added under tenant name _adobedemoamericas275. As mentioned above, all custom fields added to schemas live under the instance specific tenant name. In the real world your tenant name will be similar to your company name.

Click on the + icon next to your identification field to add child fields below it.

Add the following fields:

Click Save to complete adding your custom fields and field group.

Click on Schemas in the menu on the left side of your screen. You’ll see the list of available Schemas. To create a new schema, click on the button Create schema button on the top right.

Select Experience Event and click Next.

Name your schema using the following pattern:

[your surname] - Demo System - Event Schema for Website

Replace your surname with your own. As an example:

gillies - Demo System - Event schema for website

You can give your schema a description if you wish, then click finish to create the schema.

You'll notice the _id, timestamp and eventType fields are already part of your schema. These are mandatory for all experience events and come as part of the class itself.

In most cases you will want to add additional information to give more context about the interaction your customer had. For this we'll use a field group.

Click on + Add next to Field groups to add field groups to your schema.

You can create new field groups to match your company requirements but Adobe also provides many out of the box field groups to save yourself some time. For this exercise we'll the default web SDK field group:

Click to Add field groups to add the field group to your schema.

You can see a number of fields are now added into your schema automatically.

Lastly we need to establish how we tie this event to our customer profile. In some cases you want to flag individual fields which store the customer identities but another option is to use the IdentityMap object.

This allows your website to submit data to this schema using any valid identity namespace. This field is also a default part of every experience event class.

When relying on this method for identity ingestion there is no need to make any other updates to your schema.