Configuration and initialization in Real-Time 2.0 cover how you set up id stitching, define events and attributes, and prepare batch data for use in real-time. This section outlines the key behaviors, limits, and best practices to help you configure Real-Time 2.0 correctly from the start.
| Category | Limit / Behavior | Notes |
|---|---|---|
| ID Stitching Keys | Up to 100 IDs can be defined as stitching keys; stitching keys must have string values | Examples: email, user_id, td_client_id. Used to link events to profiles. |
| Batch ID Sync (Initialization) | Optional. Batch ID graphs can be imported into real-time to ensure continuity | Recommended when existing batch identities need to be available in real-time. |
| Profile Key (Primary ID) | Defined at Parent Segment creation; cannot be changed later | Determines the main join key across batch and real-time data. |
| Event Tables | Maximum 100 event tables per Parent Segment | Applies to both batch and real-time event tables. |
| Event Definitions | No hard limit | Aggregate filter length across definitions must be ≤1000 characters. |
| Attribute Backfill | Supported for batch attributes | Use backfill to pre-populate RT attributes with values from existing batch data. |
| Importing Batch Attributes | Supported | Newly added fields in batch tables become available after segment refresh. |
| New Event Fields | Automatically available in the database | Must be explicitly configured as RT attributes to use in personalization or triggers. |
| Multi-Account Deployment | Supported via CI/CD pipeline | Configurations can be exported from one environment and reused in another. |
Batch ID Sync: Not mandatory, but recommended when migrating existing batch identities into real-time.
Profile Keys: Chosen during Parent Segment setup and remain fixed afterward.
Attributes: Backfill lets you populate RT attributes with historical values. New fields automatically flow into the system but require explicit configuration to be used in activations or personalization.
Deployment Across Accounts: Supported through CI/CD processes to ensure consistent configuration across multiple environments.
When uploading the batch ID graph, exclude the following — they serve no purpose in Real-Time 2.0 and add unnecessary overhead:
- Batch keys that are not used as Real-Time 2.0 stitching keys — identifiers from the batch layer that are not configured as Real-Time 2.0 stitching keys cannot participate in real-time identity resolution.
- Batch Unification IDs that have no associated Real-Time 2.0 stitching keys — profiles without any real-time stitching key cannot be matched to incoming real-time events and do not need to be uploaded.
Plan your profile key strategy before enabling real-time to avoid rework.
Use attribute backfill when enabling real-time for existing batch segments.
Manage configurations with CI/CD to simplify multi-environment deployments.
Regularly review new batch or event fields to decide if they should be promoted as RT attributes.