Guardrails for Identity Service data
This document provides information on use and rate limits for Identity Service data to help you optimize your use of the identity graph. When reviewing the following guardrails, it is assumed that you have modeled the data correctly. If you have questions on how to model your data, please contact your customer service representative.
IMPORTANTGet started
The following Experience Platform services are involved with modeling Identity data:
- Identities: Bridge identities from disparate data sources as they are ingested into Experience Platform.
- Real-Time Customer Profile: Create unified consumer profiles using data from multiple sources.
Data model limits
The tables below provide guidance on guardrails for static limits as well as validation rules to consider for identity namespaces.
Static limits
The following table outlines static limits applied to identity data.
| Guardrail | Limit | Notes |
|---|---|---|
| Number of identities in a graph | 50 | When a graph with 50 linked identities is updated, Identity Service will apply a “first-in, first-out” mechanism and deletes the oldest identity to make space for the newest identity for this graph (Note: Real-Time Customer Profile is unaffected). Deletion is based on identity type and timestamp. The limit is applied at the sandbox level. For more information, read the section on understanding the deletion logic. |
| Number of links to an identity for a single batch ingestion | 50 | A single batch could contain anomalous identities that cause unwanted graph merges. To prevent this, Identity Service will not ingest identities that are already linked to 50 or more identities. |
| Number of identities in an XDM record | 20 | The minimum number of XDM records required is two. |
| Number of custom namespaces | None | There are no limits to the number of custom namespaces you can create. |
| Number of characters for a namespace display name or identity symbol | None | There are no limits to the number of characters of a namespace display name or identity symbol. |
Identity value validation
The following table outlines existing rules you must follow to ensure a successful validation of your identity value.
| Namespace | Validation rule | System behavior when rule is violated |
|---|---|---|
| ECID |
|
|
| Non-ECID |
|
|
Identity namespace ingestion
Starting March 31, 2023, Identity Service will block the ingestion of Adobe Analytics ID (AAID) for new customers. This identity is typically ingested through the Adobe Analytics source and the Adobe Audience Manager source and is redundant because the ECID represents the same web browser. If you would like to change this default configuration, please contact your Adobe account team.
Performance guardrails
Identity Service continuously monitors incoming data to ensure high performance and reliability at scale. However, an influx of experience event data in a short period may lead to performance degradation and latency. Adobe is not responsible for such performance degradation.
Understanding the deletion logic when an identity graph at capacity is updated
When a full identity graph is updated, Identity Service deletes the oldest identity in the graph before adding the latest identity. This is to maintain accuracy and relevance of identity data. This process of deletion follows two primary rules:
Rule #1 Deletion is prioritized based on the identity type of a namespace
The deletion priority is as follows:
- Cookie ID
- Device ID
- Cross-Device ID, Email, and Phone
Rule #2 Deletion is based on the timestamp stored on the identity
Each identity linked in a graph has its own corresponding timestamp. When a full graph is updated, Identity Service deletes the identity with the oldest timestamp.
When a full graph is updated with a new identity, these two rules work in tandem to designate which older identity will be deleted. Identity Service first deletes the oldest Cookie ID, then the oldest Device ID, and finally the oldest Cross-Device ID/Email/Phone.
NOTEImplications on implementation
The following sections outline the implications that the deletion logic has to Identity Service, Real-Time Customer Profile, and WebSDK.
Identity Service: Custom namespace identity type changes
Please contact your Adobe account team to request a change in identity type if your production sandbox contains:
- A custom namespace where the person identifiers (such as CRMIDs) are configured as cookie/device identity type.
- A custom namespace where cookie/device identifiers are configured as cross-device identity type.
Once this feature is available, graphs that exceed the limit of 50 identities will be reduced down to up to 50 identities. For Real-Time CDP B2C Edition, this could result in a minimal increase in the number of profiles qualifying for an audience, as these profiles were previously ignored from Segmentation and Activation.
Real-Time Customer Profile: impact to addressable audiences
Deletion only happens to data in the Identity Service and not Real-Time Customer Profile.
- This behavior could consequently create more profiles with a single ECID, because the ECID is no longer part of the identity graph.
- In order for you stay within your addressable audience entitlement numbers, it is recommended to enable pseudonymous profile data expiration to delete your old profiles.
Real-Time Customer Profile and WebSDK: Primary identity deletion
If you would like to preserve your authenticated events against the CRMID, then it is recommended that you change your primary IDs from ECID to CRMID. Read the following documents for steps on how to implement this change:
