AEP Identity: Why Casing Matters

[#1]

The Problem

A B2B RT-CDP customer recently noticed what seemed like “ghost profiles” entering their Adobe Journey Optimizer (AJO) journeys, more journey entrants than the number of profiles qualifying for the audience. This issue appeared across multiple journeys, skewing analytics and measurement.

Typically, journey entrants are fewer than the audience size due to eligibility criteria, re-entry rules, or profiles leaving the audience before a journey starts. The customer’s data ingestion was standard: batch ingestion via a source connector from their enterprise data warehouse into Adobe Experience Platform (AEP). However, they also heavily relied on the Custom Upload feature to import audiences from CSV files that powered some of their AJO journeys and campaigns.

The Cause

To determine why AJO reported more entrants than expected, we examined profile snapshots and journey datasets. We found multiple profiles for the same person, created because of inconsistent casing in identity values. The uploaded CSV files had the identity values in a different letter case from those stored in AEP’s data lake.

This behavior results from how the Custom Upload process maps identity values:

• If a CSV identity value exactly matches an existing AEP identity value (including casing), audience data merges with the existing profile.
• If it does not match an existing identity value, even due to case differences, AEP creates a new profile.

As a result, audiences uploaded via CSV files with mismatched casing caused duplicate profiles.

Examples

The following examples illustrate how casing differences between uploaded CSV identity values and those stored in Adobe Experience Platform (AEP) lead to duplicate profiles:

• B2B Person Key Identity: Suppose the uploaded CSV contains an identity column mapped to a B2B person key with mixed-case characters, such as “JohnDoe@sourceID-1234.abc.” However, the corresponding identity in AEP’s profile store is normalized to all lowercase, “johndoe@sourceid-1234.abc.” Because identity values in AEP are case-sensitive, these differently cased values are treated as distinct identities, resulting in separate profiles for John Doe.
• Email as an Identity: Similarly, if email addresses are used as identities in the CSV, for example, “John.Doe@domain.com” (with uppercase letters),while AEP stores email identities in lowercase, “john.doe@domain.com”, casing mismatches can create duplicate profiles for John Doe.

The Impact

Duplicate profiles caused by casing mismatches have serious downstream effects:

• Journey Orchestration Breakdowns: One person may enter AJO journeys multiple times, receiving overlapping communications and triggering duplicate events. This disrupts seamless customer experiences. Note: This issue only arises when the journey uses an identity namespace affected by casing (such   as email). If the journey relies on namespaces without casing sensitivity, such as ECID or numeric CRM IDs, the problem does not occur.

• Segment and Analytics Inaccuracy: Segment counts and audience sizes become inflated. Behavioral and journey analytics get fragmented, reducing targeting precision and effectiveness.
• Consent and Preference Fragmentation: Consent data may be split across profiles, complicating enforcement in campaigns and risking privacy non-compliance due to inconsistent consent states.
• Increased Profile Counts Affect Licensing: Each duplicate profile consumes part of your licensed profile volume in AEP. Inflated profile counts reduce your available license capacity, limit your ability to onboard and engage real customers, and may increase costs.
• Downstream System Conflicts: Duplicate data exported from AEP leads to errors in CRM, advertising platforms, and analytics tools, causing operational inefficiencies and poor reporting.
• Costly Data Hygiene: Resolving casing issues involves complex profile merges and stitching, which might never fully unify fragmented profiles.

The Best Practice

The importance of consistent casing for identity values in Adobe Experience Platform (AEP) is agnostic of data source. Whether identity data is ingested via batch files (such as CSV uploads), collected in real time from website interactions using the Adobe WebSDK, or integrated from other systems, inconsistent casing (e.g., John.Doe@email.com vs. john.doe@email.com) can result in duplicate profiles for the same individual.

To ensure accurate identity stitching, audience measurement, and seamless customer experiences, organizations should implement casing normalization and validation policies across all data ingestion pipelines and interfaces. Here are best practices to prevent duplicates and unify customer data in Adobe Experience Platform:

• Maintain strict identity casing consistency across all data sources.
• Before upload, ensure identity columns (e.g., emails, CRM IDs, etc.) match AEP’s stored casing exactly, as small differences can cause profile splits.

• Establish company-wide standards for identity data, including technical validation in data pipelines and clear documentation for teams working with uploads.
• Use automated checks to catch casing or formatting issues before data ingestion.

Additional Casing Considerations

Casing sensitivity in Adobe Experience Platform applies not only to individual identity values but also to identity namespaces and audience names. Because AEP treats these as case-sensitive, even minor differences in letter case can lead to data duplication, mismatches, and operational errors across your marketing and data workflows.

• Identity Namespaces are Case-Sensitive:
  In Offer Decisioning, the identity namespace is specified within the identityMap of API or SDK payloads sent during offer delivery and event tracking. While namespaces can be selected from dropdowns in UI configurations (such as datastream setups), the critical requirement for exact casing occurs programmatically in these payloads. If the namespace value in the payload does not exactly match the IMS Org’s configured namespace (for example, “MyNamespace” vs “mynamespace”), Offer Decisioning treats them as distinct, resulting in inconsistent capping behavior and profile mismatches. To ensure proper application of capping limits and stitching logic across all message placements, it is essential to maintain exact casing for identity namespace values in your payloads. (Reference)
• Audience Names Are Case-Sensitive:
  Audience names within Adobe Experience Platform are also case-sensitive—e.g., NAME_1 and name_1 are recognized as two distinct audiences by the system. This case sensitivity can lead to duplicate audience entries and inaccurate reporting or analytics. To avoid problems such as double-counting and confusion in campaign management, ensure that audience names are standardized and consistently referenced throughout workflows, APIs, and integrations. Maintain consistent casing practices across teams and systems for reliable audience management and accurate measurement. (Reference)

Summary

Consistent casing is essential for reliable data management in Adobe Experience Platform. Whether you're working with identity values, identity namespaces, or audience names, mismatched casing can create duplicate profiles, split audiences, and disrupt analytics and workflows. To prevent confusion and maintain unified customer data, it’s important to standardize and validate casing at every stage, from data ingestion to API integrations. Clear casing practices help ensure accurate audience targeting, smooth customer journeys, and trusted reporting throughout AEP.