Planning for Real-Time Customer Profile enablement

Use this page to confirm that your schema and dataset are ready before you enable them for Real-Time Customer Profile. Complete this planning review after you design your schema fields but before you enable the schema for Profile. Profile enablement applies permanent behavioral changes to your data model. You cannot reverse schema enablement, and enabling a dataset affects how its records are processed within Real-Time Customer Profile. Review this guidance to avoid unintended enablement, data quality issues, or long-term constraints in your schema design.

Enabling Profile determines how your data is stitched, merged, and activated across Experience Platform. Planning ensures that your schema structure, identity configuration, and dataset purpose are correct before you make the change. After you complete this planning review, you can proceed to enable data for Profile in the Schema Editor or Dataset UI.

Prerequisites

Before using this planning guide, ensure you have:

If you have not completed these prerequisites, start with the schema creation tutorial before proceeding with this planning guide.

Why planning matters why-planning-matters

Profile enablement permanently changes how Experience Platform treats your data. The following permanent changes apply to schemas and datasets.

Schemas: When you enable a schema for Profile, you cannot disable or delete it. You also cannot remove or rename fields from the schema after data is ingested. This permanence means your schema design must be complete and stable before you enable Profile, as you cannot reverse the decision or simplify the structure later.

Datasets: When you enable a dataset for Profile, Real-Time Customer Profile uses its records to build and update profiles. Review the dataset enablement behavior in the dataset user guide. Unlike schemas, you can disable or delete the dataset later, but doing so removes associated profile records and may affect segmentation or activation workflows. Consider the downstream impact before you make changes to an enabled dataset.

Because these changes affect downstream processes, verify that a schema and its datasets are appropriate for Profile before you enable them.

Understanding the enablement workflow

You must enable both the schema AND the datasets that use that schema for Profile. Enable resources in the following order:

You cannot enable a dataset for Profile if its schema is not already enabled. The schema acts as a prerequisite for dataset enablement. This two-step process ensures that your data model is validated before Real-Time Customer Profile begins processing records.

When to enable a schema or dataset for Profile when-to-enable

Review the criteria below to confirm Profile enablement is appropriate for your data.

Enable Profile in the following situations:

When not to enable a schema or dataset for Profile when-not-to-enable

Avoid enabling Profile in the following cases:

Enabling Profile in these scenarios may create unnecessary profiles, increase license usage, or introduce long-term schema constraints.

Key considerations before enabling Profile key-considerations

Review the considerations in this section to ensure that your schema and dataset support Profile use cases and long-term data governance. Before enabling Profile, verify your schema structure, identity configuration, and dataset purpose.

Schema readiness

Review the schema structure to confirm that it supports Profile requirements. The schema must contain the fields required for segmentation and activation, while excluding fields that are experimental or not needed long-term. Remember that any additional fields you add after enablement must be additive (see schema immutability constraints for details). This restriction means you should validate your field selection carefully before you enable Profile. For details on allowable updates, see the schema evolution rules.

Identity configuration

Identity configuration determines how Profile stitches records across datasets. Start by confirming that a valid primary identity is selected—this field must be stable, unique, and consistently populated across all records. Verify that identity namespaces are assigned correctly to prevent stitching errors. If you use secondary identities, confirm that they support your use cases without causing profile collisions, which can occur when different individuals share the same identity value. Real-Time Customer Profile resolves collisions by applying merge policies that determine which data takes precedence when conflicting records are stitched together.

Dataset purpose

Enable a dataset for Profile only when it contributes directly to profile attributes or Experience Events used in downstream workflows. Avoid enabling datasets that contain lookup or reference data not used in segmentation, test or sample data, or operational system-generated records not intended for activation. These data types do not contribute to unified customer profiles and create unnecessary storage overhead. If a dataset does not contain identity fields or customer behavior data that supports segmentation and activation, do not enable it for Profile.

Example:

You enable a “Customer Purchase Events” dataset that contains transaction data with customer IDs. Real-Time Customer Profile uses these events to build customer timelines and enable segmentation based on purchase behavior.

You do NOT enable a “Product Catalog” dataset that only contains SKU reference data without customer identifiers. Enabling this type of dataset creates unnecessary storage overhead without contributing to unified customer profiles.

Pre-enablement checklist pre-enablement-checklist

Use this checklist to confirm readiness before enabling a schema or dataset for Profile. Complete each item before you enable Profile.

Schema-level checks

Begin by validating that your schema design is complete and stable. Review your schema to confirm that all required fields for your use case are present and that no experimental or temporary fields are included. Consult the schema design best practices to ensure your schema follows recommended patterns. Obtain approval from your team on the final field list (see schema immutability constraints).

Next, verify that your primary identity configuration is correct. Open your schema in the Schema Editor and locate the field marked with the identity icon. Confirm that this field is consistently populated in your source data and that the identity namespace is appropriate for your use case. The primary identity must be stable, unique, and reliably present across all records to ensure proper profile stitching.

Finally, confirm that you do not need to rename or reorganize the schema structure. Schema structure changes are limited to additive updates only (see schema immutability constraints). Any long-term ambiguity in naming or organization cannot be corrected later, so resolve these issues before enablement.

Dataset-level checks

For each dataset you plan to enable, start by confirming that it contains profile-relevant data. Review sample records to verify they contain customer or event data rather than purely operational or reference information. Ensure that records include identity values that link to customer profiles. Datasets without identity fields or customer behavior data should not be enabled for Profile.

Determine whether the dataset should contribute to identity stitching or segmentation by understanding how its identity values relate to other datasets in your Profile-enabled environment. Consider whether records in this dataset should stitch with existing profiles or create new profile fragments. Review the merge policy documentation to understand how Real-Time Customer Profile stitches records across datasets and how this dataset fits into your overall identity strategy.

Before enabling the dataset, estimate the number of unique identity values it contains and verify that these identity values represent actual customers rather than test accounts or system identifiers. Confirm that enabling this dataset aligns with your license entitlements, as each unique identity contributes to your addressable audience count. Profile enablement increases storage and processing costs, so ensure the dataset provides value that justifies this investment.

Completing this checklist helps prevent issues that cannot be reversed after enablement.

Enabling Profile for your schema and dataset enable-profile

After completing the pre-enablement checklist, follow these steps to enable Profile. As explained in Understanding the enablement workflow, you must enable the schema before you enable any datasets that use that schema.

Enable your schema for Profile

Enable Profile on your schema first:

For detailed instructions, see the schema enablement guide in the Schema Editor documentation.

Enable your datasets for Profile

After your schema is enabled for Profile, enable each dataset that should contribute to unified profiles:

Repeat this process for each dataset that should contribute to Real-Time Customer Profile. For detailed instructions and API enablement options, refer to the dataset user guide referenced in the Prerequisites section.

Why order matters

As explained in Understanding the enablement workflow, you must enable the schema before enabling datasets. This ensures that Real-Time Customer Profile validates the schema structure supports profile operations before allowing dataset enablement, and that all datasets using the schema inherit the correct field definitions for segmentation and identity stitching.

After you enable both the schema and datasets, Real-Time Customer Profile begins processing records and building unified customer profiles. Records ingested before enablement are not included in profiles unless you reingest the data.

Next steps next-steps

You have reviewed the permanent effects of Profile enablement, confirmed that your schema and datasets are ready, and validated that your identity configuration supports your use cases. To deepen your understanding of schema structure and field relationships, review the Basics of schema composition, which explains schema evolution rules and how fields interact within the data model. If you encounter issues during or after enablement, consult the XDM troubleshooting guide for common problems and solutions. To learn more about how identity namespaces affect profile stitching and resolution, review the Identity namespaces overview.