For retailers and wholesalers whose customer exists in five systems

Single Customer View: One Person, Five Records, No Agreement

The same customer bought in a store under a misspelt surname, ordered online with a work email, joined the loyalty programme with a mobile number, logged a support ticket from a personal address, and appears in the CRM twice because a rep created a lead. Every system is confident it has the right record. None of them is talking about the same person.

A single customer view is what fixes that, and it is far less about buying a platform than about deciding four things: what makes two records the same person, which system wins on each field, what happens when a match is wrong, and what the customer actually consented to. This page covers all four, with the Australian obligations that attach.

Book a Customer Data Call (03) 9003 0111

Realistic ROI

No perfect key

Exists for consumer records

Email, mobile and name all fail in different and predictable ways

Merging is easy

Unmerging is the hard part

Which is why an aggressive matching rule is more dangerous than a cautious one

Consent is per channel

Not a single marketing flag

Email, message and phone consent are separate questions with separate evidence

Weeks 6 to 12

For a first working unified view

Assuming reasonable data; heavily duplicated bases take longer to reconcile

Four Decisions That Make or Break a Single Customer View

Every failed customer data project failed on one of these four, and usually on the second.

There is no reliable identifier for a consumer

Email addresses are shared between partners, changed when people leave jobs and mistyped at the counter. Mobile numbers are recycled and stored in three different formats. Names are misspelt, hyphenated, transliterated and abbreviated. Addresses are entered inconsistently, especially unit numbers. Any matching rule based on one field alone will be wrong in both directions, so real matching uses combinations with different confidence levels and accepts that a residue always needs a human.

A wrong merge is much worse than a missed one

Failing to match two records leaves you with a duplicate, which is untidy. Wrongly merging two people gives one customer sight of another’s purchase history, which is a privacy incident, and pulling the records apart afterwards is genuinely difficult once orders, loyalty points and communications have been attached to the merged identity. Bias the rules towards caution, keep the contributing source records intact, and route the uncertain cases to review rather than guessing.

Survivorship has to be decided field by field

When two records disagree about a phone number, something has to decide which one appears in the unified view. The answer differs per field: the most recently transacted address usually wins, the loyalty system may be authoritative for date of birth, finance owns the billing entity, and the support system is often the freshest source of a mobile number. Write these rules down before building, because the alternative is that whichever system synced last wins, which is not a rule at all.

Consent travels with the record and the channel

Combining data does not combine permissions. Under the Privacy Act 1988 and the Australian Privacy Principles, personal information should generally be used for the purpose it was collected for or a purpose the person would reasonably expect. Under the Spam Act 2003, commercial electronic messages need consent, accurate sender identification and a working unsubscribe. A customer who gave a service email address to arrange a delivery has not signed up to a newsletter, and a unified view must carry that distinction rather than flattening it.

How a Single Customer View Is Actually Built

Six stages. The middle two are where the entire quality of the result is determined.

Ingest

Collect from every source

Point of sale, online store, CRM, loyalty, marketing platform, support desk and any spreadsheet that turns out to be operational. Each source keeps its own identifier and its records are copied rather than moved, so the unified view is built on top of the sources rather than replacing them. That means a bad matching decision is always recoverable.

Normalise

Standardise before comparing

Mobile numbers into one consistent format regardless of whether they were entered with a leading zero, an international prefix or spaces. Emails lowercased and trimmed. Names split and case corrected. Addresses parsed into components with Australian conventions handled, including unit and street type variations. Most of the matching improvement people expect from clever algorithms actually comes from this unglamorous step.

Link

Match with graded confidence

Exact agreement on a strong identifier such as a verified email plus a matching surname is a high confidence link. Agreement on mobile plus postcode is moderate. Similar names at the same address is a candidate for review, not an automatic merge. Grading the confidence lets you automate the clear cases and put a human on the rest, which is the only approach that stays accurate as the base grows.

Golden record

Build the unified record

The unified view is assembled from the linked sources using the survivorship rules, and it records which source each field came from and when. That provenance is what makes the record trustworthy: when someone questions an address, you can show where it came from rather than defending an algorithm nobody can inspect.

Permissions

Consent and suppression

Consent status held per channel with the evidence of when and how it was given, plus suppression for unsubscribes, complaints, bounces and deceased notifications. Suppression has to be network wide and immediate, because an unsubscribe honoured in one system and not another is exactly the failure the Spam Act is concerned with.

Outbound

Publish back to the systems

The unified view is only useful if the systems that serve customers can see it: the counter knows this shopper’s online history, the support agent sees the loyalty status, the marketing platform receives a deduplicated audience with correct consent. Publishing back also needs care, since writing a merged identity into a source system can be difficult to undo.

What a Unified View Changes

Task	Traditional	Unified View	Notes
Customer at the counter	Staff see in store purchases only	Full history across channels	The most visible improvement, and the one staff notice within a day.
Support enquiry	Agent searches three systems	One record with order and loyalty context	Cuts handling time noticeably because the agent stops hunting across tabs.
Marketing audience	Exported per system, overlapping	Deduplicated with consent applied	Stops the same person receiving three versions of the same campaign.
Unsubscribe request	Honoured in the sending system only	Suppressed everywhere immediately	Directly relevant to Spam Act obligations, and a common source of complaints.
Access or deletion request	A manual hunt across systems	One lookup, defined process	Privacy Act rights are hard to honour when you cannot find every copy of a person.
Measuring customer value	Per channel, always understated	Across every channel they use	Multichannel customers are usually far more valuable than either channel shows alone.
Duplicate loyalty accounts	Merged manually on complaint	Detected and reviewed proactively	Points balances need care on merge, and the customer should be told what happened.
An ambiguous match	Merged optimistically or ignored	Held in a review queue with evidence	The design choice that determines whether you ever have a privacy incident here.

Where Customer Data Projects Cause Damage

Matching rules tuned for coverage

A rule that maximises the number of matches will merge two different people who share a common surname and a suburb, and the result is one customer seeing another’s order history. That is a privacy incident, not a data quality issue. Tune for precision instead, accept that a proportion of duplicates will survive, and give the review queue enough evidence that a person can decide quickly. A duplicate is an inconvenience; a wrong merge is a notification conversation.

Consent flattened during consolidation

Bringing five systems together tempts everyone to resolve conflicting marketing flags by taking the most permissive value. That is precisely backwards. Consent should be resolved conservatively, held per channel with its evidence, and a suppression in any source should suppress everywhere. Under the Spam Act 2003 the burden is on the sender to show consent, and a unified view that cannot produce the evidence for a given address is a liability rather than an asset.

No way to undo a merge

Merges will be wrong sometimes, and the question is whether that is a five minute correction or a week of forensic work. Keep every contributing source record intact and unmodified, treat the unified record as a derived view over them, and store the linking decisions as data. Systems that physically merge and discard the originals cannot be corrected, and the pressure to avoid ever admitting a bad match then distorts the entire operation.

Data collected because it was available

The Australian Privacy Principles direct you to collect only personal information reasonably necessary for your functions, and every additional field is something you have to secure, correct on request and delete on request. A unified view is a natural place for scope to creep, particularly with data inferred from behaviour. Decide what you actually need for the uses you have described to customers, and resist assembling a profile simply because the pipes now exist.

Deletion honoured in one place only

When a customer asks for their data to be deleted or corrected, the obligation follows their information wherever you hold it, including the marketing platform, the support desk, backups within reason, and any third party you passed it to. A unified view makes this achievable, because you can finally find every copy, but only if deletion is designed as a flow that reaches every connected system rather than a button in one of them.

Access spread wider than the role requires

Assembling a complete picture of a customer means that anyone who can open the unified record can see considerably more than they could before, including purchase history across channels and support history. Set access by role rather than by convenience, log who viewed what, use least privilege service accounts for the integrations themselves, and review the access list periodically. The concentration of data is the benefit and the risk in the same breath.

How Yes AI Approaches Customer Data Unification

We measure the duplication before proposing anything

A sample analysis across your actual systems showing how many records are duplicates, which fields are reliable enough to match on, and what the realistic match rate is. Occasionally the honest answer is that the problem is smaller than assumed and a targeted fix is enough.

Precision first, with a review queue

Matching rules tuned to avoid wrong merges rather than to maximise coverage, with graded confidence, a short review queue for the ambiguous cases, and every source record preserved so any decision can be reversed.

Built, hosted and monitored by us

Ingestion, standardisation, matching and publishing run on a managed cloud automation layer we operate, with logging of every linking decision so a merge can always be explained and, if necessary, undone.

Consent and deletion designed in

Consent held per channel with its evidence, suppression applied everywhere at once, and access, correction and deletion built as flows that reach every connected system rather than as a manual process someone has to remember.

From Five Versions of a Customer to One

Five steps. A first working unified view usually lands between weeks six and twelve.

Profile the data honestly

A sample across every system measuring duplication, field completeness and format consistency, so matching rules are designed against reality rather than against how the data is supposed to look.

Agree matching and survivorship

Which combinations constitute a confident match, which need review, and which system wins for each field. Written down, tested against real records, and approved before anything is merged.

Settle consent and access

Consent held per channel with evidence, suppression rules, who may see the unified record, and how access, correction and deletion requests will be executed across every connected system.

Build with sources preserved

Ingestion, standardisation and matching built on a managed layer with the source records left intact, linking decisions stored as data, and a review queue for anything below the confidence threshold.

Publish back and tune

The unified view exposed where it helps, at the counter, in support and in marketing, then matching thresholds tuned against real review outcomes rather than against assumptions.

FAQ

What is a single customer view?

It is one authoritative record for each real person or business, assembled from every system that holds information about them, showing their history across every channel with a defensible answer for each field. The important word is assembled. It is normally a derived view built on top of the source systems rather than a new master database that replaces them, because keeping the sources intact is what lets you correct a matching mistake later.

Do we need a customer data platform to do this?

Not necessarily, and the platform question is usually asked far too early. What you always need is agreed matching rules, agreed survivorship, a consent model and somewhere to hold the linkages. For a business with a handful of systems and a few hundred thousand records, that can be built on the integration layer you already need for other reasons. A dedicated platform earns its licence fee when you have very large volumes, real time personalisation requirements, or a marketing team that needs to build audiences without engineering help.

What should we match on?

Combinations, with graded confidence, never a single field. A verified email plus a matching surname is strong. A normalised mobile number plus a matching postcode is good. A similar name at the same address is a candidate for human review rather than an automatic link. For business customers an ABN is a genuinely strong identifier and worth capturing wherever you can. Whatever you choose, standardise the fields first, because most of the apparent matching difficulty is really formatting inconsistency wearing a disguise.

What happens when the matching gets it wrong?

It will, so design for it. If two records were wrongly linked, you need to separate them, reassign the orders, loyalty points and communications correctly, and in some cases tell the affected customers what happened. That is only feasible if the source records were preserved and the linking decisions were stored as data rather than applied destructively. Assume a small ongoing rate of correction, staff a short review queue for the ambiguous cases, and tune the thresholds from what the queue actually decides.

How does Australian privacy law affect a single customer view?

The Privacy Act 1988 and the Australian Privacy Principles are the main framework for most businesses. Practically, they push you to collect only what is reasonably necessary, to be clear at collection about what you will do with the information, to use and disclose it for the purpose it was collected for or a purpose the person would reasonably expect, to keep it accurate and secure, and to honour requests for access and correction. Combining data across systems for a new purpose is exactly the situation those principles are aimed at, so the safest position is that the unified view supports uses customers were told about. This is general information rather than legal advice.

How do we handle marketing consent across systems?

Hold it per channel with the evidence of when and how it was obtained, rather than as one marketing flag on the record. The Spam Act 2003 requires consent for commercial electronic messages, accurate identification of the sender and a functional unsubscribe that is actioned promptly, and the burden of showing consent sits with you. In an integrated environment the crucial rule is that suppression is global and immediate: an unsubscribe recorded anywhere applies everywhere, straight away, including in any platform you export audiences to.

How long does it take and where should we start?

A first useful unified view typically takes six to twelve weeks, longer where the underlying data is heavily duplicated. Start with the two systems that cause the most day to day pain, which for most Australian retailers is the point of sale and the online store, and get that link right before adding marketing, support and loyalty. A narrow unified view that staff trust is far more valuable than a complete one they do not, and each additional source is easier once the matching rules have been proven on real records.

One Customer, One Record, Consent Intact

Book a call. We profile your actual data, tell you how duplicated it really is, and give you a priced plan. The data profile is yours either way.