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.
Get started
The following Experience Platform services are involved with modeling Identity data:
- Identities: Bridge identities from disparate data sources as they are ingested into 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.
Identity value validation
The following table outlines existing rules you must follow to ensure a successful validation of your identity value.
- The identity value of an ECID must be exactly 38 characters.
- The identity value of an ECID must consist of numbers only.
- If the identity value of ECID is not exactly 38 characters, then the record is skipped.
- If the identity value of ECID contains non-numerical characters, then the record is skipped.
- The identity value cannot exceed 1024 characters.
- Identity values cannot be 鈥渘ull鈥, 鈥渁nonymous鈥, 鈥渋nvalid鈥, or be an empty string (for example: " ", 鈥溾, " ").
- If the identity value exceeds 1024 characters, then the record is skipped.
- The identity will be blocked from ingestion.
Identity namespace ingestion
Starting March 31, 2023, Identity Service will block the ingestion of 蜜豆视频 Analytics ID (AAID) for new customers. This identity is typically ingested through the 蜜豆视频 Analytics source and the 蜜豆视频 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 蜜豆视频 account team.
Performance guardrails 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. 蜜豆视频 is not responsible for such performance degradation.
Understanding the deletion logic when an identity graph at capacity is updated deletion-logic
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.
Implications 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 蜜豆视频 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:
Example scenarios
Example one: typical large graph
Diagram notes:
t= timestamp.- The value of a timestamp corresponds with the recency of a given identity. For example,
t1represents the first linked identity (oldest) andt51would represent the newest linked identity.
In this example, before the graph on the left can be updated with a new identity, Identity Service first deletes the existing identity with the oldest timestamp. However, because the oldest identity is a device ID, Identity Service skips that identity until it gets to the namespace with a type that is higher on the deletion priority list, which in this case is ecid-3. Once the oldest identity with a higher deletion priority type is removed, the graph then gets updated with a new link, ecid-51.
- In the rare case that there are two identities with the same timestamp and identity type, Identity Service will sort the IDs based on XID and conduct deletion.
Example two: 鈥済raph split鈥
Diagram notes:
- The following diagram assumes that at
timestamp=50, 50 identities exist in the identity graph. (...)signifies the other identities that are already linked within the graph.
In this example, ECID:32110 is ingested and linked to a large graph at timestamp=51, thereby exceeding the limit of 50 identities.
As a result, Identity Service deletes the oldest identity based on timestamp and identity type. In this case, ECID:35577 gets deleted only from the identity graph.
As a result of deleting ECID:35577, the edges that linked CRMID:60013 and CRMID:25212 with the now deleted ECID:35577 also get deleted. This deletion process leads to the graph being split into two smaller graphs.
Example three: 鈥渉ub-and-spoke鈥
Diagram notes:
- The following diagram assumes that at
timestamp=50, 50 identities exist in the identity graph. (...)signifies the other identities that are already linked within the graph.
By virtue of the deletion logic, some 鈥渉ub鈥 identities can also get deleted. These hub identities refer to nodes that are linked to several individual identities that would otherwise be unlinked.
In the example below, ECID:21011 is ingested and linked to the graph at timestamp=51, thereby exceeding the limit of 50 identities.
As a result, Identity Service deletes the oldest identity only from the identity graph, which in this case is ECID:35577. The deletion of ECID:35577 also results in the deletion of the following:
- The link between CRMID: 60013 and the now-deleted ECID:35577, thus resulting in a graph split scenario.
- IDFA: 32110, IDFA: 02383, and the remaining identities represented by
(...). These identities get deleted because individually, they are not linked to any other identities and therefore, cannot be represented in a graph.
Finally, the deletion process yields two smaller graphs.
Next steps
See the following documentation for more information on Identity Service:
See the following documentation for more information on other Experience Platform services guardrails, on end-to-end latency information, and licensing information from Real-Time CDP Product Description documents:
- Real-Time CDP guardrails
- End-to-end latency diagrams for various Experience Platform services.