Entities that represent individuals in your Sitecore implementation

Version: 10.4
Warning

This Privacy Guide provides technical guidance on how your developers can choose to configure your Sitecore product implementation to support you with data privacy compliance. This guide does not provide exhaustive guidance, and should not be construed or used as legal advice about the content, interpretation, or application of any law or regulation. You, the customer, will always be in the best position to assess your own risks, and must seek your own legal counsel to understand the applicability of any law or regulation to your business, including how you process personal information. Your resulting implementation is based entirely on your own configuration choices.

An individual is represented by four separate entities across the platform:

  • As contacts in an Experience Platform (XP) context.

  • As enrollments in the Marketing Automation database.

  • As users in an Experience Manager (XM) context.

It is also represented as form metrics data in the xDB Reporting database, which links to form submission data in the Forms database.

Each entity has the potential to store sensitive personal information and entities are linked directly or indirectly by IDs or other identifiers. When securing the platform and implementing functionality that supports the individual’s rights, you must consider all representations of the individual across the platform and how they are linked.

Where and how data is stored

The following tables describe the purpose of each entity, where the entity is stored, and what data can be associated with each entity.

Important

The exact data that is collected by you depends on your implementation. These tables describe the model for collecting data that is available by default. Where it is stored depends on whether you are self-hosting or hosting in the Managed Cloud environment.

Contacts

Purpose

Central storage for data relevant to marketing activities such as personalization, automation, and email.

Storage

Collection database, xDB index

Data

If collected, the following data is available in the Collection database and the xDB index (assuming indexing of personal information is enabled):

  • Contact identifiers

  • Contact facets, including personal information such as:

    • First and last name

    • Address

    • Email address, including a historical list of emails for EXM

  • Interactions, including:

    • Events

    • Outcomes

    • Goals

    • Page views

  • Interaction facets

API

xConnect Client API

Default facets and events

See the  xConnect collection model reference for a list of all default xConnect facets and events. Facets with personal information are marked [PIISensitive].

Email Experience Manager facets and events

The Email Experience Manager (EXM) EmailAddressHistory contains personal information. This facet is marked [PIISensitive].

Enrollments

Purpose

Represents a contact's enrollment in an automation plan or activity.

Storage

Marketing Automation database

Data

The following data is available in the Marketing Automation database:

  • Contact ID

  • Plans or activities that the contact is enrolled in.

Plan or activity names might reveal sensitive information about the individual's interaction with a brand or organization.

Note

You can add custom data to enrollments. We recommend that you do not add personal information such as email addresses to an enrollment.

API

Marketing Automation Operations API

Users

Purpose

Authentication and authorization.

Storage

The default implementation of ASP.NET Membership stores users in the Core database. There is no default provider for ASP.NET Identity.

Data

  • Username

  • ASP.NET membership profile data

API

ASP.NET Membership API or ASP.NET Identity API

Forms

Purpose

Metrics such as form submission successes and failures are aggregated into the xDB Reporting database. Each record includes a ContactId, InteractionId, and FieldId. Form submissions are stored in the Forms database, and include a FieldItemId.

The records can be linked to a contact in the Collection database as follows. Refer to the table in the next section, Links between individual entities, for more information.

Storage

xDB Reporting database, specifically:

  • Fact_FormMetrics table (includes ContactID and InteractionID)

  • Fact_FormFieldMetrics table (includes InteractionID)

Forms database, specifically:

  • FieldData table (includes form submission data)

Data

Form submission data is customizable and can include personal information such as an individual’s name and email address.

API

Reporting API, SQL

Do you have some feedback for us?

If you have suggestions for improving this article,