AI Glossary / Data engineering and architecture / Intermediate

Single customer view

Definition

A single customer view is a coherent representation of a customer assembled from relevant records across systems or channels. It connects identity, attributes, and interactions so authorized users can understand the relationship in context. “Single” refers to the unified view, not necessarily one physical database or an infallible record. The scope must define whether the subject is a person, organization, account, or household.

What it means

A support system may know a customer's recent issue, an ordering system their purchases, and a contact system their preferred address. A unified view can connect these records without requiring staff to search each source separately. The difficult part is establishing which records belong together and how conflicts should be handled. Two people can share an email address, and one person can have several addresses or accounts.

How it works

Identify source systems and the customer concept being modeled. Use documented matching rules to link records, then reconcile conflicting attributes according to evidence and ownership rules. Retain source links and relevant history rather than silently overwriting every disagreement. Update the view as source data changes and monitor incorrect merges and missed matches. Access permissions and allowed purposes should govern what each user or application sees. A technically unified profile does not create permission to use every connected attribute for every purpose.

Three practical examples

• Customer support: an authorized agent sees relevant orders and open service issues together, reducing repeated questions while still checking that the records concern the correct customer.
• Account management: a business distinguishes an organization from its individual contacts and links the appropriate contracts and interactions to each level.
• Website assistance: an authenticated service uses a customer's permitted account context to provide relevant information, without exposing another household member's records merely because an address is shared.

Think of it this way

Think of an organized customer folder with references to material held by different teams. The folder helps connect the story, but its tabs must point to the right person and retain evidence about conflicting information. The analogy is limited because digital identity matching can be uncertain and automated at scale. A neat-looking profile can conceal a mistaken merge unless its provenance and review mechanisms remain available.

Worked example

A toy dataset has three records. R1 contains customer ID C14, email maya@example.test, and phone 555-0101. R2 has the same trusted customer ID C14 but a newer phone 555-0102. R3 has customer ID C99 and the same postal address as R1. Under the stated rule that the trusted customer ID identifies the same person, R1 and R2 can link, while the newer verified phone may be selected for the current view. R3 should not automatically merge merely because the address matches. The view retains both source records and the phone's history. This illustrates explicit rules; real identifier quality and verification must be established rather than assumed.

Illustrative case study

Fictional example: Cedar Repairs finds that several family members share a contact address. Its first matching rule groups too aggressively, combining separate service histories. The team revises the rule, reviews affected profiles, and distinguishes household relationships from person identity. It also gives support staff a way to report suspected mismatches. This invented case illustrates the cost of false merges, not a measured result or a claim that one matching technique suits every customer dataset.

Common misconceptions and mistakes

Do not assume a single view is a single unquestionable truth. Do not equate shared contact details with shared identity. Avoid flattening organizations, accounts, and people into one entity type when their relationships matter. More connected data is not automatically more useful; outdated or irrelevant attributes can confuse decisions. Also distinguish a unified view from a complete lifetime history. Its coverage depends on connected sources, identifiers, retention, and permitted access.

Business use

Define the decisions the view should support before integrating every available source. Prioritize reliable identity, high-value attributes, and clear ownership of conflicts. Track false merges, missed links, freshness, and user corrections. Preserve provenance so important discrepancies can be investigated. For AI customer assistants, supply only the context appropriate to the task and make uncertain identity or conflicting records explicit. A fluent response built from the wrong person's profile is a serious quality failure even if the integration pipeline ran successfully.

People also ask

Does a single customer view require one database?

No. It can be assembled from several systems through physical consolidation or a governed access layer.

Does matching an email prove identity?

Not universally. Emails can be shared, changed, or entered incorrectly, so the evidence and use case matter.

Should old values be deleted when a new value is chosen?

Not automatically. History and source provenance may be needed to interpret or correct the unified view.

Check your understanding

Two records have the same street address but different trusted person identifiers. Should they be merged to reduce duplicates?

Answer: Not on that evidence alone. They may represent different people in one household. The matching policy must distinguish shared relationships from identity.

Related terms

• Golden record (informatics)
• Identity resolution
• master data management
• golden record
• data reconciliation
• customer data platform
• provenance
• entity resolution

Learn next

create five fictional customer records containing one genuine duplicate and one shared-address pair. Write matching and reconciliation rules separately. Explain which records link, which values appear in the current view, and what evidence remains available for review.

More in Data engineering and architecture

• Shared snapshot objects - Shared snapshot objects are concurrent data structures that let processes update components and obtain a coherent view of the components together.
• Simulation decomposition - Simulation decomposition, often called SimDec, is an uncertainty and sensitivity analysis approach that explains an output distribution by separating it...
• Simultaneous and heterogeneous multithreading - Simultaneous and heterogeneous multithreading, abbreviated SHMT, is a research approach to using different kinds of processing hardware concurrently within...
• Single-instance storage - Single-instance storage stores one physical instance of identical content while allowing several logical objects or references to use it.
• Single instruction, multiple threads - Single instruction, multiple threads, or SIMT, is an execution model in which a group of threads can execute a common instruction while each thread works...
• Single source of truth - A single source of truth is an agreed authoritative source or governed access point for a particular set of information.

Sources

Primary sources consulted: Salesforce, Identity Resolution Reconciliation Rules, https://help.salesforce.com/s/articleView?id=sf.c360_a_reconciliation_rules.htm&language=en_US&type=5; Unified Profiles and Identity Management, https://help.salesforce.com/s/articleView?id=sf.mc_pers_identity.htm&language=en_US&type=5 — product documentation excerpts consulted. These illustrate unification and reconciliation, not universal matching guarantees. Examples and business workflow are original; full editorial review remains pending.

Previous: Single-arm study design Next: Single-instance storage