Unified Customer Profile:
Definition and How It Works

A unified customer profile is a consolidated record that brings customer information from different systems into one view. Creating it involves selecting customer data, resolving duplicates, matching records across sources, and choosing the fields to display, as described in Microsoft’s data unification overview.

Two decisions determine the result: which records belong to the same customer, and which values should appear when those records disagree. Adobe distinguishes identity stitching from the policies that prioritize conflicting data in its merge policy documentation.

What does a unified customer profile contain?#

A profile can combine relatively stable attributes with a history of interactions. Adobe describes customer record data and time-series events as separate forms of information accessible through its Real-Time Customer Profile.

A unified view can include related records without flattening every interaction into a customer row. Microsoft’s unification process separates profile information from purchases and other activities that have a one-to-many relationship with a customer, as explained in its source selection guidance.

How is it different from a CRM or CDP?#

A customer relationship management system can supply data to a unified profile. Amazon’s customer profile service, for instance, combines information from external CRM applications with contact history and exposes product, case, and contact information in one service view, according to its Customer Profiles documentation.

A customer data platform is software that can create and use the combined view; the profile is the customer information produced through that process. Adobe documents profile creation as a capability of its Real-Time Customer Data Platform.

The uses extend beyond displaying contact details. Adobe’s profile service supports audience membership based on combined customer attributes and events, while Amazon’s service presents interaction history for customer support, as described in their respective profile overview and service profile guide.

How to build a unified customer profile#

Select source records and map their fields#

Source mapping determines how incoming data becomes profile information or a related object. In Amazon’s implementation, a mapping specifies how fields populate profiles, orders, cases, assets, or loyalty records, and which keys associate those objects with a customer, according to its object type mapping documentation.

The source table’s primary key has a different role from a field used to recognize a customer across systems. Microsoft warns that using an email address instead of the table’s actual unique key can cause records sharing that value to be deduplicated and removed, as explained in its unification troubleshooting guide.

Resolve duplicates within each source#

Deduplication identifies multiple records for a customer inside one source table. Microsoft processes each table separately and selects a representative row using completeness or recency; it also supports different preferences for individual fields, according to its deduplication documentation.

A duplicate group can extend through connected matches: records linked by different rules can become one group through a shared intermediate record. Microsoft’s deduplication process documents this behavior, so examining only the group’s first and last records can miss the connection that joined them.

The representative row also need not supply every matching clue. In Microsoft’s implementation, values from alternate rows remain available for cross-source matching, including previous contact details, as described under merge preferences.

Match records across sources#

Cross-source matching connects customer records from different systems. Microsoft starts with a primary table, adds other tables in a defined order, and evaluates matching rules in sequence; both table priority and rule order are part of its matching configuration.

Exact matching compares values under the selected normalization rules. Fuzzy matching allows small differences, such as typing errors; Microsoft recommends narrowing fuzzy comparisons with an exact condition and avoiding frequently repeated default values in its unification best practices.

Normalization changes the comparison rather than the displayed customer data. Microsoft’s process can standardize variations for matching while leaving final profile values unchanged, according to the same normalization guidance.

An exact email match still needs a rule appropriate to the source data. Microsoft specifically notes that customers can share an email address and suggests adding another condition when needed in its deduplication guidance.

Matching also needs a way to handle known exceptions. Microsoft’s cross-table process supports exclusion conditions and explicit instructions that particular records must remain separate, as documented in its advanced matching options.

Choose the values that appear in the profile#

Field selection resolves conflicts after identity matching. Microsoft supports prioritizing sources, choosing values by recency, retaining separate columns, or excluding fields from the output, according to its customer column unification documentation.

Source priority and recency answer different questions. A priority rule selects the first available non-null value in the configured order, while a recency rule requires a field that defines the ordering, as explained in Microsoft’s field merge options.

Related fields may need to stay together. Microsoft supports selecting an address group as a unit to prevent individual address components from being combined into an incorrect mixture of sources, according to its grouped field guidance.

The meaning of the timestamp matters too. Adobe’s timestamp-based merge method uses the time a record was ingested into the platform, rather than a separate customer-confirmation date, as specified in its timestamp ordering documentation.

Assign a customer reference and define updates#

The unified identifier connects the resulting profile to later processing. Microsoft assigns a customer ID that normally persists across runs, but merges and splits can alter IDs; its previous-ID field records the earlier identifiers, according to the customer ID documentation.

Update behavior depends on the implementation. Adobe supports both streaming and batch ingestion into Profile, as documented in its ingestion overview.

Updating a profile and updating everything that uses it can also be separate operations. Microsoft distinguishes refreshing the profile alone from refreshing it together with dependent segments, measures, and enrichments in its unification update documentation.

How to check whether matching is working#

A match count needs to be read alongside the records behind it. Microsoft provides previews of matching rules and their conditions, results with scores, and counts of matched and unmatched records; it also allows matching to run without updating the unified profile, according to its rule evaluation documentation.

For unexpected results, Microsoft’s recommended checks include the source primary key, compared fields, normalization settings, source accuracy, and the records visible in each customer profile. Its troubleshooting guide also explains how intermediate output tables reveal the steps that produced a match.

Unmatched records deserve attention as well. In Microsoft’s implementation, an inclusion setting determines whether records without a cross-source match remain in the final output; leaving it disabled can drop those records, as explained in its unmatched record guidance.

Adding more rules also has a processing cost. Microsoft recommends introducing rules progressively, comparing the results and run time, and removing rules that add no useful matches in its unification best practices.

How permissions and retention fit into the profile#

Where the GDPR applies, personal data must serve a specified purpose, be limited to what is necessary, remain accurate, and be retained only as long as needed. Access and security controls also apply to the combined data, as explained in the European Commission’s GDPR principles.

Identity matching does not establish a lawful basis for processing. The Commission identifies several possible bases, including consent and contractual necessity; consent-based processing is limited to the purposes agreed to, according to its legal grounds guidance.

Permission therefore needs its own scope and update path within the profile’s design. Where processing relies on consent, withdrawal must be as easy as giving consent, and processing for the withdrawn purpose must stop, as stated in the Commission’s consent withdrawal guidance.