Identity namespace explained

Another way to better understand the concept of namespace is to consider real world examples such as cities and their corresponding states. For example, Portland, Maine and Portland, Oregon are two different places in the United States. While the cities share the same name, the state operates as a namespace and provides necessary context that distinguishes the two cities from each other.

Applying the same logic to Identity Service:

  • At a glance, the identity value of: 1-234-567-8900 can look like a phone number. However, from a system perspective, this value could have been configured as a CRMID. Identity Service would have no way of applying the necessary context to this identity value without a corresponding namespace.
  • Another example is the identity value of: john@gmail.com. While this identity value can be easily assumed to be an Email, it is entirely possible that it’s configured as a custom namespace CRMID. With namespace, you can distinguish Email:john@gmail.com from CRMID:john@gmail.com.

Components of a namespace

A namespace consists of the following components:

  • Display name: The user-friendly name for a given namespace.
  • Identity symbol: A code used internally by Identity Service to represent a namespace.
  • Identity type: The classification of a given namespace.
  • Description: (Optional) Any supplemental information that you can provide regarding a given namespace.

Identity type

One element of an identity namespace is the identity type. The identity type determines:

  • Whether an identity graph will be generated:

    • Identity graphs are not generated for the following identity types: non-person identifiers and partner ID.
    • Identity graphs are generated for all other identity types.
  • Which identities are removed from the identity graph when system limits are reached. For more information, read the guardrails for identity data.

The following identity types are available within Experience Platform:

Identity type
Description
Cookie ID
Cookie IDs identify web browsers. These identities are critical for expansion and constitute the majority of the identity graph. However, by nature they decay fast and lose their value over time.
Cross-Device ID
Cross-device IDs identify an individual and usually tie other IDs together. Examples include a login ID, CRMID, and loyalty ID. This is an indication to Identity Service to handle the value sensitively.
Device ID
Device IDs identify hardware devices, such as IDFA (iPhone and iPad), GAID (Android), and RIDA (Roku), and can be shared by multiple people in households.
Email address
Email addresses are often associated with a single person and therefore can be used to identify that person across different channels. Identities of this type include personally identifiable information (PII). This is an indication to Identity Service to handle the value sensitively.
Non-people identifier
Non-people IDs are used for storing identifiers that require namespaces but are not connected to a person cluster. For example, a product SKU, data related to products, organizations, or stores.
Partner ID
  • Partner IDs are identifiers used by data partners to represent people. Partner IDs are often pseudonymous so as to not reveal a person’s true identity, and may be probabilistic. In Real-Time Customer Data Platform, Partner IDs are used primarily for expanded audience activation and data enrichment, and not for building identity graph linkages.
  • Identity graphs are not generated when ingesting an identity that includes an identity namespace specified as Partner ID type.
  • Failure to ingest partner data using the identity type of Partner ID could result in reaching system graph limitations on Identity Service, as well as unwanted merging of profiles.
Phone number
Phone numbers are often associated with a single person and therefore can be used to identify that person across different channels. Identities of this type include PII. This is indication to Identity Service to handle the value sensitively.