Sitecore xConnect Collection Model

Sitecore has great documentation which I used to get to know the key components of xConnect. This article is meant to quickly retrieve the key components at any time I need a global overview of the terms and to document learnings from experimenting with xConnect. Maybe the article can help somebody else, but be sure to always check out the official documentation to get the latest and most detailled information.

Collection model

The structure of the experience data is defined in the collection model which ships with Sitecore. Since Sitecore 9 the model is architected in a way that supports an omnichannel strategy. Before Sitecore 9 it was very webbased and the model was dependent on (web) page events. That’s not the case anymore. Now a contact just has a collection of interactions and each interaction can hold a collection of events. So it’s very straight forward and flexible.

A couple of important models are:

The Sitecore documentation also describes calculated facets, but since it’s recommended to use this sparingly I won’t cover information related to this type of facet in this article.

The core collection model consists of the base entities and attributes collected by xDB. The other models display the additional information that can be stored related to the specific Entity (such as Contact or Interation). The collection model is very extensible so you can add your own models. We will talk about extending the model in a another article.

The diagram shown here is an extremly oversimplified representation of the model structure and only covers the main classes and key-properties on which the Collection model is based on.

sitecore collection model overview

Main classes

Base class for entity types stored in xDB.

The device profile is used to identify the same device over time so that the contact can be inferred. It represents a specfic device, browser or similar that a Contact uses to interact with a brand. It specifies a mapping between a specific user agent instance and the most recent contact to use it. That is to say - the ID can be stored as a cookie on a browser and is then used to identify the returning contact even if they’re anonymous.

The contact represents the individual for which interactions (with a brand) are collected. A contact contains the best-known information used to personalize the individual's experience. Contacts may merge over time if it turns out they represent the same individual.

It specifies a set of activities that took place during a web session, phone call or some other interaction between a contact and a brand. Therefor it represents an interaction between a contact and a brand in the form of context, and events that took place.

This class specifies an activity from a contact occurring during an interaction. Some examples are clicking a button on a web page, swiping right on a mobile app, completing a form, or purchasing a product. The events are sequenced by their timestamp. Events can also be goals or outcomes. 

Goal - is a special action executed by a contact during an interaction. Goals can be a logical choice for actions where conversion rates are sensibly defined. A conversion rate in this sense is: the percentage of users who take a desired action. 

Outcome - is a significant event where money usually changes hands.


Through the concept of a Facet extra information can be stored. Facets can be related to either a Contact or an Interaction. A summary of the most commonly used Facets grouped by the entity their providing additional information for is listed below.

Contact Facets

  • AddressList
  • Avatar
  • Classification
  • ConsentInformation
  • EmailAddressList
  • ListSubscriptions
  • PersonalInformation
  • PhoneNumberList

Interaction Facets

  • IpInfo
  • LocaleInfo
  • ProfileScores
  • UserAgentInfo
  • WebVisit