Schema building blocks

In this video, I’ll give you a quick overview of the key elements in Experience Data Model or XDM schemas. Here are the key elements of schemas. Thank you and good luck. Kidding. I liked this visualization of the elements because I think it does a great job of capturing the frequency with which these things occur in a typical platform implementation. I’ll go through this diagram from the bottom up. At the bottom are fields, these are the most granular elements, fields model and individual data point. Each piece of data that you bring into Experience Platform has to add here to a schema field. There are standard fields and you can define your own fields using all kinds of options but fields can’t be created independently. They have to be added through data types, field groups or classes. Let’s go to the UI now and look at these elements. Select Schemas from the navigation and you’ll see tabs for all three. Let’s start with Data types, the most granular of those three. You’ll see there are a lot of data types provided out of the box. Data types are like little logical groupings of fields. Let’s look at an innocuous data type like email address. You might think, “Hey, isn’t this just one field?” The great thing about data types and field groups in Experience Platform is that a lot has been thought through in a lot of detail. Basically, everything you could want is in here, from the address itself to the type of email address, the status of the email address, maybe it’s not working and there’s an undeliverable response coming back and so on. So, a data type is a group of fields. They can be used in any type of schema and you can create your own. Like fields though, they don’t get added directly to schemas but can be added to classes and field groups, which is why at the top of our diagram we have Schema = Class + Field Groups. Classes and field groups include the data types and the fields, field groups are also groups of fields, they contain both fields and data types. There is the mechanism used to add most fields to schemas. Although technically, you don’t actually need to have any, you could have a schema consisting of just the class. Note how in this field group there’s a field called Personal email, which uses the email address data type and contains those same fields we’re just looking at. Field groups can be created in this schema of creation workflow and they’re tied to a specific class, which leads me to Classes. A class and only one class is required in every schema. They define what a schema represents like a person, a product, an event occurring on a website, a classification if you will. Classes have fields built into them. Representing the minimal shared fields needed in any schema using the class, like every insurance policy schema is going to have an owner and a beneficiary attached to it. So, these types of essential fields are just built in. In addition to the out-of-the-box classes, you can also create your own.

So, we’re now at the top of our bizarre round pyramid thing, which is Behavior. Behavior refers to the type of class you’re using. There are two types, record for classes describing things and time-series for describing things that happened. You might’ve seen this slide in another video. When you create new classes and select one of these types, a set of fields may be added to that new class. For example, all time-series classes have an event id, eventType and timestamp fields in them.

So, that’s a walkthrough of the elements of schemas. I hope that helps your understanding and good luck building your own schemas. -