1 customer, 3 profiles: how CDP identity resolution can fail

A customer (customer A) views a water purifier on a website from a laptop, leaves a phone number in a form, then asks for a price on Zalo. After 1 week the system holds 3 profiles: 1 anonymous cookie, 1 phone number and 1 Zalo ID. This is an illustrative example, not a real measurement.

This article draws on documentation from Twilio Segment, Adobe, RudderStack, Google Analytics, Meta and WebKit, checked on November 3, 2026. Zalo OA documentation needs JavaScript, so Click Star could not read it and does not use it as evidence.

It answers 3 questions: how a CDP (customer data platform) links those profiles, what wrong or missed matches cost, and which minimum rules to set so the result can be measured.

Key points

• Identity resolution means recognizing that different IDs (cookie, email, phone, channel ID) belong to the same person and merging them into 1 profile.
• Per its Unify FAQs, Twilio Segment matches only deterministically (on exact keys), not probabilistically.
• 2 errors exist: a false merge (2 people in 1 profile) and a missed match (1 person in 2). Segment warns false merges are costly once profiles feed an email tool.
• 3 guards limit false merges: blocked values, a cap on keys per profile and a priority order.
• Click Star proposes "minimum matching rules" and a hand-checked sample to measure false merges. It is Click Star's own framework, not an industry standard.

What identity resolution is, and why 1 customer becomes many profiles

Identity resolution is the CDP step that finds the IDs of a single person and gathers them into 1 profile.

Each place issues different IDs. There are 4 common groups:

• Browser ID: the anonymous cookie. Per Google's "Reporting identity" page (no date shown, read November 3, 2026), on websites the GA4 device ID takes its value from the client ID. Click Star understands the client ID is usually stored in a cookie.
• User ID issued by the business: login ID, customer ID in the CRM.
• Contact ID: email, phone number.
• Messaging-channel ID: according to Meta's Messenger overview (no date shown, read November 3, 2026), each person who messages a Facebook Page receives an ID unique to that Page.

So customer A becomes 3 profiles: the laptop cookie, the phone number in the form and the ID in the messaging channel. No key links them yet.

Anonymous cookies also multiply. Per "Tracking Prevention in WebKit" (no date shown, read November 3, 2026), Safari deletes JavaScript-created cookies and other script-written data after 7 days without user interaction with the site. Click Star's inference: a Safari user returning after more than 7 days may get a new anonymous ID, if it sits in a script-created cookie.

How it works: find matching keys, then connect them into a graph

When a new event arrives, the system looks for profiles with the same key. Per Twilio Segment's "Identity Resolution Onboarding" (no date shown, read November 3, 2026), there are 3 outcomes.

• No profile matches: create a new profile.
• 1 profile matches: add the event and the new IDs to that profile.
• Several profiles match: check the administrator's rules, then try to merge.

A RudderStack blog post (December 16, 2025, a vendor post, so secondary) describes each ID as a node, each relationship as an edge, and connected nodes sharing 1 virtual ID. Click Star's inference: if A links to B and B links to C, A and C share a profile without ever appearing together, so 1 shared key can pull many people into 1 profile.

Unmerging can be harder than merging, depending on the platform. Unify FAQs (no date shown, read November 3, 2026) says Segment's external IDs cannot be changed or removed from a profile. Yet Segment has a "Delete Profile Identifier API" (beta, Business plan, enabled per space, 1 ID per call, merge history kept).

Adobe differs: per "Identity Optimization Algorithm" (updated October 21, 2026, read November 3, 2026), a violated limit makes the algorithm remove the link joining 2 people.

Deterministic or probabilistic matching

Deterministic matching merges only when keys match exactly, such as an email or login ID. Probabilistic matching infers a link from signals such as IP address or browser traits (RudderStack post above).

Segment chose the first: Unify FAQs says most marketing automation needs certainty that the recipient is the right person, so it does not support probabilistic matching.

False merges and missed matches: 2 errors, different costs

A false merge puts 2 people in 1 profile. A missed match leaves 1 person in 2 profiles.

Documented causes of false merges: shared devices and junk values. Per Segment's "Identity Resolution Settings" (for spaces created before September 27, 2020, no date shown, read November 3, 2026), an iPad set up in a store for customer sign-up can merge many people through the same device ID.

Adobe's "Identity Graph Linking Rules" page (updated October 21, 2026, read November 3, 2026) adds family computers, airport kiosks and call-center agents logging in for customers.

Per Google ("Measure activity across platforms with User-ID", no date shown), giving 2 people the same ID makes reports show 1 person who viewed both product A and product B.

Click Star's inference: a false merge can send an offer or invoice to the wrong person; a missed match double-counts customers and doubles messages.

3 guards against false merges

The examples below come from Segment.

Guard 1: block junk values

Segment advises blocking values that often cause mass merges: strings of only zeros and dashes (^[0-]*$), -1, null, anonymous, plus hard-coded test values such as void or abc123. A blocked value stays in the raw event but is not used as a key.

Guard 2: limit keys per profile

A limit is the maximum number of values of 1 ID type on 1 profile within a period, such as user_id 1 ever, anonymous_id 5 weekly. Segment's defaults: user_id 1, other IDs 5.

Guard 3: priority order

Priority decides which ID is dropped when a limit is exceeded. Segment's example: a profile has user_id abc123 and 1 email, and a new event carries user_id abc456 with the same email. As user_id is capped at 1, Segment demotes the email and searches again on abc456; no profile matches, so it creates a new one instead of merging.

By default user_id ranks 1, email ranks 2 and other IDs follow alphabetically.

Normalizing email and phone before matching

2 different strings can be the same key, so normalize before comparing. Segment treats all IDs as case-insensitive.

Phone numbers also need a standard form: 0901000001 and +84901000001 (illustrative example) are the same number.

Merging profiles and privacy

Click Star understands merging profiles as data processing, so check whether the original consent covers the merge. Click Star does not give legal advice.

A summary on the Ha Tinh provincial government portal (posted January 5, 2026, secondary source) says Vietnam's Law on Personal Data Protection No. 91/2025/QH15 took effect on January 1, 2026. Clause 1 of Article 4 lists the rights to be informed, to consent or withdraw consent, to view, to correct and to request deletion. Check the original text.

Click Star's inference: when a customer withdraws consent or asks for deletion, you need a process that reaches every merged ID. The law has exceptions: a secondary full text on ketoananpha.vn (not checked against the official portal) shows Articles 10, 14 and 19 allow not complying in some cases. Ask a lawyer.

What this means for businesses in Vietnam

Click Star's view: Vietnamese businesses may receive customers from the website, Zalo, Facebook and phone at once, and the phone number may be the key shared across channels, so treat an unverified phone number as a weak key.

A Facebook ID is tied to each Page, so a customer who messages 2 Pages of the same business has 2 IDs. For Zalo, Click Star could not read the documentation and does not describe Zalo ID behavior.

Click Star's view. Identity resolution is a data governance decision, not just a software setting. Each matching rule is a promise: how much the business trusts a key before treating 2 profiles as 1 person.

Click Star sells CRM and CDP services, so it has an interest here. Technically: start strict, match less than you could, and loosen only on evidence, because unmerging can be harder than merging.

Minimum matching rules and how to measure the false-merge rate

This is Click Star's reference framework, not taken from an outside source. The minimum rules are 5:

• Match automatically only on login ID, verified email and verified phone number.
• Link an anonymous cookie to a profile only when the customer leaves a key in the same session.
• Block junk values before matching.
• Each profile holds only 1 login ID.
• Past a limit, do not merge further.

Measuring false merges with a hand-checked sample takes 4 steps:

1. Draw N merged profiles at random from 2 or more sources.
2. Have 2 people review them independently, comparing name, address and order history.
3. Count the clearly wrong, the uncertain and the correct profiles.
4. The false-merge rate is wrong profiles divided by N, with a margin of error.

Illustrative example, not a measurement: N = 200 and 4 wrong profiles give 2.0%, with a 95% Wilson interval of about 0.8% to 5.0%, so a small sample gives only a rough conclusion. To check missed matches, sample customers known to be 1 person (same order) and see whether they were split.

The 2 SQL queries below help pick a sample: profiles with more than 1 login ID (with the default user_id cap of 1, usually no rows), and the 20 most repeated values, case-insensitive. Table links stores each profile's IDs and table raw_ids stores raw IDs before matching. Click Star ran them on SQLite 3.54 with fake data, not on a real CDP.

SELECT profile_id, COUNT(DISTINCT id_value) AS so_ma
FROM links
WHERE id_type = 'user_id'
GROUP BY profile_id
HAVING COUNT(DISTINCT id_value) > 1;

SELECT id_type, LOWER(id_value) AS gia_tri, COUNT(*) AS so_ban_ghi
FROM raw_ids
GROUP BY id_type, LOWER(id_value)
ORDER BY so_ban_ghi DESC, id_type, gia_tri
LIMIT 20;

What to do in 10 days

Click Star's reference plan, not an industry standard.

• Days 1 to 3: list every ID type collected, then normalize email and phone numbers.
• Days 4 to 7: run the most-repeated-values query, block junk values, set limits and priority order.
• Days 8 to 10: draw a hand-checked sample, record the false-merge rate as a baseline, schedule a quarterly recheck.

Common mistakes

1. Matching on an unverified phone number and treating it as 1 person.
2. Not blocking junk values such as null, anonymous or strings of zeros.
3. Keeping defaults without looking at customers who share devices.
4. Tightening rules after profiles exist, which Segment's Settings page advises against.
5. Sending personalized email before measuring the false-merge rate.
6. No process that handles withdrawal of consent or deletion across all merged IDs.

What is not known

No Vietnam measurement exists for how often phone numbers or emails are shared, for platforms' false-merge rates, or for the accuracy of each matching method. The documents read all come from vendors, not independent evaluations.

It is unclear how a Zalo ID changes across OAs and apps, because Zalo OA documentation needs JavaScript and Click Star could not read it. It is also unclear whether Segment's ID-removal API suffices to split 2 wrongly merged people; ask the vendor.