۶Ƶ Experience Platform enables you to deliver personalized cross-channel experiences based on behavioral insights and customer attributes in the form of Real-Time Customer Profiles. To support this new approach to profiles, Experience Platform uses a highly denormalized hybrid data model that differs from the traditional relational data model.
IMPORTANT
Check your license entitlements in your Sales Order and corresponding on actual usage limits in addition to this guardrails page.
This document provides default use and rate limits to help you model your Profile data for optimal system performance. 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.
NOTE
Most customers do not exceed these default limits. If you would like to learn about custom limits, please contact your customer care representative.
Getting started
The following Experience Platform services are involved with modeling Real-Time Customer Profile data:
Identities: Bridge identities from disparate data sources as they are ingested into Platform.
Schemas: Experience Data Model (XDM) schemas are the standardized framework by which Platform organizes customer experience data.
Audiences: The segmentation engine within Platform is used to create audiences from your customer profiles based on customer behaviors and attributes.
Limit types
There are two types of default limits within this document:
Guardrail type
Description
Performance guardrail (Soft limit)
Performance guardrails are usage limits that relate to the scoping of your use cases. When exceeding performance guardrails, you may experience performance degradation and latency. ۶Ƶ is not responsible for such performance degradation. Customers who consistently exceed a performance guardrail may elect to license additional capacity to avoid performance degradation.
System-enforced guardrails (Hard limit)
System-enforced guardrails are enforced by the Real-Time CDP UI or API. These are limits that you cannot exceed as the UI and API will block you from doing so or will return an error.
NOTE
The limits outlined in this document are constantly being improved. Please check back regularly for updates. If you are interested in learning about custom limits, please contact your customer care representative.
Data model limits
The following guardrails provide recommended limits when modeling Real-Time Customer Profile data. To learn more about primary entities and dimension entities, see the section on entity types in the Appendix.
Primary entity guardrails
Guardrail
Limit
Limit Type
Description
XDM Individual Profile class datasets
20
Performance guardrail
A maximum of 20 datasets that leverage the XDM Individual Profile class is recommended.
XDM ExperienceEvent class datasets
20
Performance guardrail
A maximum of 20 datasets that leverage the XDM ExperienceEvent class is recommended.
۶Ƶ Analytics report suite datasets enabled for Profile
1
Performance guardrail
A maximum of one (1) Analytics report suite dataset should be enabled for Profile. Attempting to enable multiple Analytics report suite datasets for Profile may have unintended consequences for data quality. For more information, see the section on ۶Ƶ Analytics datasets in the Appendix.
Multi-entity relationships
5
Performance guardrail
A maximum of 5 multi-entity relationships defined between primary entities and dimension entities is recommended. Additional relationship mappings should not be made until an existing relationship is removed or disabled.
JSON depth for ID field used in multi-entity relationship
4
Performance guardrail
The recommended maximum JSON depth for an ID field used in multi-entity relationships is 4. This means that in a highly nested schema, fields that are nested more than 4 levels deep should not be used as an ID field in a relationship.
Array cardinality in a profile fragment
<=500
Performance guardrail
The optimal array cardinality in a profile fragment (time-independent data) is <=500.
Array cardinality in ExperienceEvent
<=10
Performance guardrail
The optimal array cardinality in an ExperienceEvent (time series data) is <=10.
Identity count for individual profile Identity Graph
50
System-enforced guardrail
The maximum number of identities in an Identity Graph for an individual profile is 50. Any profiles with more than 50 identities are excluded from segmentation, exports, and lookups.
Dimension entity guardrails
Guardrail
Limit
Limit Type
Description
No time-series data permitted for non-XDM Individual Profile entities
0
System-enforced guardrail
Time-series data is not permitted for non-XDM Individual Profile entities in Profile Service. If a time-series dataset is associated with a non-XDM Individual Profile ID, the dataset should not be enabled for Profile.
No nested relationships
0
Performance guardrail
You should not create a relationship between two non-XDM Individual Profile schemas. The ability to create relationships is not recommended for any schemas which are not part of the Profile union schema.
JSON depth for primary ID field
4
Performance guardrail
The recommended maximum JSON depth for the primary ID field is 4. This means that in a highly nested schema, you should not select a field as a primary ID if it is nested more than 4 levels deep. A field that is on the 4th nested level can be used as a primary ID.
Data size limits
The following guardrails refer to data size and provide recommended limits for data that can be ingested, stored, and queried as intended. To learn more about primary entities and dimension entities, see the section on entity types in the Appendix.
NOTE
Data size is measured as uncompressed data in JSON at time of ingestion.
Primary entity guardrails
Guardrail
Limit
Limit Type
Description
Maximum ExperienceEvent size
10KB
System-enforced guardrail
The maximum size of an event is 10KB. Ingestion will continue, however any events larger than 10KB will be dropped.
Maximum profile record size
100KB
System-enforced guardrail
The maximum size of a profile record is 100KB. Ingestion will continue, however profile records larger than 100KB will be dropped.
Maximum profile fragment size
50MB
System-enforced guardrail
The maximum size of a single profile fragment is 50MB. Segmentation, exports, and lookups may fail for any profile fragment that is larger than 50MB.
Maximum profile storage size
50MB
Performance guardrail
The maximum size of a stored profile is 50MB. Adding new profile fragments into a profile that is larger than 50MB will affect system performance. For example, a profile could contain a single fragment that is 50MB or it could contain multiple fragments across multiple datasets with a combined total size of 50MB. Attempting to store a profile with a single fragment larger than 50MB, or multiple fragments that total more than 50MB in combined size, will affect system performance.
Number of Profile or ExperienceEvent batches ingested per day
90
Performance guardrail
The maximum number of Profile or ExperienceEvent batches ingested per day is 90. This means that the combined total of Profile and ExperienceEvent batches ingested each day cannot exceed 90. Ingesting additional batches will affect system performance.
Number of ExperienceEvents per profile record
5000
Performance guardrail
The maximum number of ExperienceEvents per profile record is 5000. Profiles with more than 5000 ExperienceEvents will not be considered for segmentation.
Dimension entity guardrails
Guardrail
Limit
Limit Type
Description
Total size for all dimensional entities
5GB
Performance guardrail
The recommended total size for all dimensional entities is 5GB. Ingesting large dimension entities may affect system performance. For example, attempting to load a 10GB product catalog as a dimension entity is not recommended.
Datasets per dimensional entity schema
5
Performance guardrail
A maximum of 5 datasets associated with each dimensional entity schema is recommended. For example, if you create a schema for “products” and add five contributing datasets, you should not create a sixth dataset tied to the products schema.
Dimension entity batches ingested per day
4 per entity
Performance guardrail
The recommended maximum number of dimension entity batches ingested per day is 4 per entity. For example, you could ingest updates to a product catalog up to 4 times per day. Ingesting additional dimension entity batches for the same entity may affect system performance.
Segmentation guardrails segmentation-guardrails
The guardrails outlined in this section refer to the number and nature of audiences an organization can create within Experience Platform, as well as mapping and activating audiences to destinations.
Guardrail
Limit
Limit Type
Description
Audiences per sandbox
4000
Performance guardrail
An organization can have more than 4000 audiences in total, as long as there are less than 4000 audiences in each individual sandbox. This is inclusive of batch, streaming, and edge audiences. Attempting to create additional audiences may affect system performance. Read more about creating audiences through the segment builder.
Edge audiences per sandbox
150
Performance guardrail
An organization can have more than 150 edge audiences in total, as long as there are less than 150 edge audiences in each individual sandbox. Attempting to create additional edge audiences may affect system performance. Read more about edge audiences.
Edge throughput across all sandboxes
1500 RPS
Performance guardrail
Edge segmentation supports a peak value of 1500 inbound events per second entering the ۶Ƶ Experience Platform Edge Network. Edge segmentation may take up to 350 milliseconds to process an inbound event after it enters the ۶Ƶ Experience Platform Edge Network. Read more about edge audiences.
Streaming audiences per sandbox
500
Performance guardrail
An organization can have more than 500 streaming audiences in total, as long as there are less than 500 streaming audiences in each individual sandbox. This is inclusive of both streaming and edge audiences. Attempting to create additional streaming audiences may affect system performance. Read more about streaming audiences.
Streaming throughput across all sandboxes
1500 RPS
Performance guardrail
Streaming segmentation supports a peak value of 1500 inbound events per second. Streaming segmentation may take up to 5 minutes to qualify a profile for segment membership. Read more about streaming audiences.
Batch audiences per sandbox
4000
Performance guardrail
An organization can have more than 4000 batch audiences in total, as long as there are less than 4000 batch audiences in each individual sandbox. Attempting to create additional batch audiences may affect system performance.
Account audiences per sandbox
50
System-enforced guardrail
You can create a maximum of 50 account audiences in a sandbox. After you reach 50 audiences in a sandbox, the Create audience control is disabled when trying to create a new account audience. Read more about account audiences.
The recommended maximum membership of an audience is 30 percent of the total number of profiles in the system. Creating audiences with more than 30% of the profiles as members or multiple large audiences is possible but will impact system performance.
Expected availability
The following section outlines the expected availability for audiences and merge policies in downstream services such as Real-Time CDP destinations:
Sandbox type
Time
Existing sandboxes
1 hour
New sandboxes
2 hours
Newly reset sandboxes
2 hours
Appendix
This section provides additional details for the limits in this document.
A primary entity, or profile entity, merges data together to form a “single source of truth” for an individual. This unified data is represented using what is known as a “union view”. A union view aggregates the fields of all schemas that implement the same class into a single union schema. The union schema for Real-Time Customer Profile is a denormalized hybrid data model that acts as a container for all profile attributes and behavioral events.
Time-independent attributes, also known as “record data” are modeled using XDM Individual Profile, while time-series data, also known as “event data” is modeled using XDM ExperienceEvent. As record and time-series data is ingested in ۶Ƶ Experience Platform, it triggers Real-Time Customer Profile to begin ingesting data that has been enabled for its use. The more interactions and details that are ingested, the more robust individual profiles become.
Dimension entity
While the Profile data store maintaining profile data is not a relational store, Profile permits integration with small dimension entities in order to create audiences in a simplified and intuitive manner. This integration is known as multi-entity segmentation.
Your organization may also define XDM classes to describe things other than individuals, such as stores, products, or properties. These non-XDM Individual Profile schemas are called “dimension entities” (also known as “lookup entities”) and do not contain time-series data. Schemas that represent dimension entities are linked to profile entities through the use of schema relationships.
Dimension entities provide lookup data which aids and simplifies multi-entity segment definitions and must be small enough that the segmentation engine can load the entire data set into memory for optimal processing (fast point lookup).
Profile fragments
In this document, there are several guardrails that refer to “profile fragments.” In Experience Platform, multiple profile fragments are merged together to form the Real-Time Customer Profile. Each fragment represents a unique primary identity and the corresponding record or complete set of event data for that ID within a given dataset. To learn more about profile fragments, refer to the Profile overview.
Merge policies merge-policies
When bringing data together from multiple sources, merge policies are the rules that Platform uses to determine how data will be prioritized and what data will be combined to create that unified view. For example, if a customer interacts with your brand across several channels, your organization will have multiple profile fragments related to that single customer appearing in multiple datasets. When these fragments are ingested into Platform, they are merged together in order to create a single profile for that customer. When the data from multiple sources conflicts the merge policy determines which information to include in the profile for the individual. A maximum of five (5) merge policies that use the _xdm.context.profile schema are allowed per sandbox. To learn more about merge policies, please read the merge policies overview.
۶Ƶ Analytics report suite datasets in Platform aa-datasets
Multiple report suites can be enabled for Profile as long as all data conflicts are resolved. You can use the Data Prep functionality to resolve data conflicts across eVars, Lists, and Props. To learn more about how to use the Data Prep functionality, please read the ۶Ƶ Analytics connector UI guide.
Next steps
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:
