Review Your Data and Data Model Object
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the importance of the party subject area.
- Implement the data model object from the party data model to capture information.
Map Out Your Data
Let’s take a look at how a company might approach using data model objects and attributes from the Customer 360 Data Model. Remember, your data model isn’t already defined in the Customer 360 Data Model. It’d be great if all that work was already done, but we haven’t perfected predicting the future—yet. The Customer 360 Data Model provides standardized ways of representing certain data model objects and attributes. In other words, everyone is playing with the same types of blocks, so you know how everything is going to fit together and behave—no matter what you build. And with these blocks, you can better scale to meet future data model demands. Let’s explore an example.
Meet Pia Larson. She’s the enterprise architect for outdoor gear and apparel retailer Northern Trail Outfitters (NTO), and she’s charged with mapping out the data model for the company. NTO gets data from all kinds of different sources, including in-store sales, online sales, customer marketing journeys, website behavior, and many others. Her job is to bring it all together.
Before anything else, Pia needs to know where the data comes from. And that means she needs to search all data sources. NTO gathers information from the sales process, support interactions, marketing efforts, and more. Pia needs to talk with stakeholders in all facets of NTO’s customer journey and find out where the data is stored.
Pia determines that NTO needs a single, unified identity for contacts, and information on the actions those contacts perform. And she wants to bring the information on those actions back to the single, unified identity. After reviewing the Customer 360 Data Model, she decides that the party and engagement subject areas represent the information NTO needs to base their data model around.
Now it’s time for her to start mapping around those two data model objects. She also notes that Data Cloud requires the individual, party identification, contact point email, contact point phone, and contact point address data model objects. These common objects provide a solid foundation for common customer data that you can use to create unified profiles.
Join the Party
When it comes to our Customer 360 Data Model, the party subject area has nothing to do with politics or festivities. Instead, party represents an instance of a person or an organization. That entity could be an individual, a business, or some other institution. You can attach various types of information to a data model object, but each instance is a unique representation of that entity. The party subject area includes a few data model objects that help you identify information about a specific entity, including contact information, how that role relates to your business, and other pertinent information.
The party subject area includes data model objects that should sound familiar: Party identification, individual, and contact point email. Let’s take a look at the party subject area and its associated data model objects as it relates to one person. Specifically, NTO customer Rachel Rodriguez.
In Rachel’s case, there are some alternate spellings for her name, but imagine if you ran into somebody who also used a preferred nickname or had a name with a variety of traditional variations—like Elizabeth, Beth, Betsy, Liz, Liza, Eli, or another term. That’s a lot of information to try to bring together! Toss in a few different addresses (an old apartment, a work address, and a current living space), and the system has even more variations to consider. We won’t even get into old cell phone numbers or email addresses—we have more important things to do.
Individual in the Party Subject Area
Information on Rachel comes in from a variety of sources. NTO needs to resolve information from those sources. So Pia has to make sure they all link directly to the correct data model object and respective attributes. All of this information helps you reach the ultimate goal of creating Rachel Rodriguez’s unified profile in Data Cloud. Of all of these fields, though, one should stand out as carrying more importance than the others.
The individual ID is found in the individual DMO and helps link that DMO to other DMOs. As Pia starts to outline all of the data streams heading into her Data Cloud instance, she needs to make sure that she maps all of Rachel’s information back to individual IDs. Let’s take a look at a sample set of relationships in the individual data model object.
This example shows the individual field of the account contact data model object is related to the individual ID field. Contact point address, contact point email, and contact point phone are also related to the Individual Id field. All of these fields are related as ManyToOne cardinality, meaning that multiple addresses and phone numbers can relate to a single individual. (Don’t worry, we won’t tell people when you give out a throwaway email address). The individual ID field for the individual data model object is also related to the individual ID field for the unified link individual data model object as OneToOne cardinality. This data model object becomes available after the identity resolution process takes place (you can review this process in the Ingestion and Modeling in Data Cloud module). In this case, there can only be one value for this link, which helps preserve the unique nature of the record.
We’ll cover more about the unified link individual later in this badge.
Personalize the Party
Your data model is personalized to your Data Cloud instance, because what you put together depends on your own data needs and the data sources you use to bring that data into Data Cloud. But remember that you’re using standardized data model objects for a reason. That standardization allows Data Cloud to stand a better chance of matching up all of the information to the right unified individual. This configuration also maximizes the functionality of your data model and helps you get up and running more quickly. Plus, you can take advantage of apps from AppExchange more easily, since everybody already agrees on the types and configuration of data you’re going to use.
As you plan your data model, remember to match up identifiers correctly, but also think about which data sources should take priority over others. This information comes in handy later when you need to handle identity resolution within Data Cloud. This process makes sure that all of the correct information is linked to the correct record and prioritizes which information is used (such as full names versus nicknames, or preferred email addresses). The unique NTO membership rewards number helps bring in all the information to the unified profile, and the rules sort out which information is prioritized and used in actual customer interactions.
Sum It Up
In this unit, you explored the data model of a person within Data Cloud. Next, we’ll look at what those people do and how to capture it.
Resources