Unifying customer data from forms, Zalo, Facebook and calls: how to do it and common mistakes

One customer can leave details through a website form, message on Zalo, click a Facebook ad and then phone you, and in your data they appear as 4 different people. Each channel gives you its own kind of identifier, and most of those identifiers cannot be joined unless you prepared for it in advance.

This article goes into the data plumbing of each channel: what each one lets you collect and what it does not, how to standardize phone numbers to use as a join key, safe rules for merging profiles, and the common mistakes. Sources include the developer documentation of Zalo, Meta and Google, read on October 21, 2026.

Click Star already has an article on CDPs (customer data platforms) explaining why merging identities helps marketing operations. This one goes into how to do it. The legal part rests on summaries and needs checking against the original text.

Key points

• Each channel gives a different kind of ID: forms give the email and phone number the customer typed, Zalo gives an ID per Official Account, Facebook Messenger gives an ID per Page, Lead Ads give form data, and calls give a phone number.
• A phone number appears in Zalo data only when the user chooses to share it, and Messenger returns neither email nor phone number. So a standardized phone number is usually the most reliable join key.
• Zalo uses numbers as 84xxxxxxxxx (its sending documentation also accepts +84), Google needs +84xxxxxxxxx (E.164), and Meta needs 84xxxxxxxxx with no + sign and no leading 0 before hashing. Store one standard form (E.164) and derive each platform's form from it.
• Leads from Meta can be downloaded only within 90 days of submission, so you need a webhook or continuous sync, not manual exports.
• A wrong merge (2 people into 1) does as much harm as no merge. Merge automatically only on certain identifiers, and flag the confidence level for the rest.
• Merging data across channels is personal data processing that must sit within the consented purposes, and Zalo's consent-withdrawal webhook must trigger deletion in your system.

What each channel lets you identify

Website forms. You get what customers type (email, phone number, name) and what the browser lets you collect at the same time: ad click IDs (gclid, fbclid) and the analytics tool's visitor ID. This is the source you control most.

Zalo Official Account. According to Zalo's documentation (developers.zalo.me), the user ID is meaningful only within one OA, and there is also an app-level ID (user_id_by_app). The same person has different IDs under different OAs. Message events sent to the webhook contain no phone number.

A phone number appears only in the shared information (shared_info) when the user agrees to share it, through the user_submit_info event. The phone number is therefore the one key that joins across OAs, but only after the user shares it.

Facebook Messenger. The user ID (PSID) is page-scoped. According to Meta's documentation, the profile API returns the ID, name and profile picture (the picture URL expires), and returns neither email nor phone number. It does not support Messenger accounts created with a phone number (error 2018218). With click-to-Messenger ads, you have no profile access until the person replies.

Facebook Lead Ads. When a customer submits an ad form, the webhook sends you the lead ID (leadgen_id), Page ID, form ID, ad ID and creation time. You use the lead ID to fetch the form content (name and value pairs such as full_name and email). Answers to a custom disclaimer sit in a separate field, not with the form data.

Calls. The only identifier is the phone number, with time and duration. Click Star found no official standard for call-log fields, so each call system has its own schema.

Phone numbers: one standard form to store, many forms to send

Each platform asks for a different number form. The documentation of Zalo's ZBS Template Message sending API requires the number with the country code, for example 0987654321 becoming 84987654321 or +84987654321. Google Ads requires the E.164 standard with a + sign (11 to 15 characters), then SHA-256 hashing.

Meta's Conversions API documentation requires removing symbols, letters and the leading 0, adding the country code, then SHA-256 hashing, so 0912345678 must become 84912345678 before hashing.

The neatest approach is to store numbers in E.164 (for example +84912345678) as the single standard form and write a function that derives the form for each platform. Google maintains the libphonenumber library (Java, C++, JavaScript and ports to other languages) for parsing, formatting and validating numbers. Click Star could not verify how well the library's metadata covers Vietnam.

Old 11-digit numbers. Vietnam converted mobile subscribers from 11 to 10 digits from September 15, 2018 (Decision 798/QĐ-BTTTT). According to summaries, the old prefixes changed as follows: Viettel 016x became 03x; VinaPhone 0123, 0124, 0125, 0127 and 0129 became 083, 084, 085, 081 and 082.

MobiFone 0120, 0121, 0122, 0126 and 0128 became 070, 079, 077, 076 and 078; Vietnamobile 0186 and 0188 became 056 and 058; Gtel 0199 became 059, and the last 7 digits were usually kept. Click Star has not opened the original text, so check it.

The practical consequence: if your CRM or old call logs still hold 11-digit numbers, apply the prefix table before using them as a join key, and check a sample by hand.

How to collect and join each channel

Web forms

Collect email and phone number in standardized form, and collect the following at the same time so the lead can be joined to advertising.

Google's offline conversion documentation advises capturing gclid, gbraid and wbraid from the landing-page URL. GA4's client_id should be stored at the moment of form submission, because the Measurement Protocol recommends joining within a 48-hour window and accepts backdating events by at most 72 hours.

Google's documentation does not instruct storing the gclid in a hidden form field. That is common practice but not official guidance. Google does not import offline conversions uploaded more than 90 days after the last click (GCLID), or 63 days for enhanced conversions for leads.

Zalo Official Account

Register a webhook to receive events. According to the documentation, you must reply HTTP 200 within 2 seconds; if it fails, Zalo retries after 30 seconds, 5 minutes, 15 minutes, 30 minutes and 1 hour, then unsubscribes the app if it still fails. The signature in the X-ZEvent-Signature header lets you verify the message came from Zalo.

Use the user detail API to fetch information and write the CRM's customer ID into the user_external_id field, so you can join back later. Consulting messages can be sent only within 7 days of the user's last interaction.

To send messages by phone number with a ZBS Template Message, the documentation requires a number with the country code and a tracking_id for reconciliation. The delivery webhook returns the phone number and tracking_id, so you can tie the result back to the right CRM row.

Facebook Lead Ads and Messenger

Register the leadgen webhook. When a new lead arrives, you receive the lead ID and call the API to fetch the content, with permissions such as leads_retrieval and pages_manage_metadata. Meta says you have at most 90 days from submission to download a lead, even under lifetime results, and advises using a CRM or regular exports.

For Messenger, treat the PSID as a temporary Page-level ID, not a person's identifier. To join it to a profile, ask for a phone number or email in the conversation with a clear request and record the consent.

Calls

Standardize incoming and outgoing numbers to E.164, apply the prefix table to old numbers, then look up the profile by number. If there is no profile, create a new one in an unverified state instead of merging into a similar one.

Safe rules for merging profiles

An article from Redpoint Global (a CDP vendor, June 12, 2026, to be read as product material) distinguishes 2 ways of matching. Deterministic matching uses exact verified identifiers such as email, phone number or customer ID, with high confidence and auditability but narrow coverage. Probabilistic matching scores name, address and date of birth, covering more but able to merge wrongly.

The article defines a false positive as when records of 2 different people are incorrectly merged.

Click Star proposes the following ladder for a small business, drawn from that distinction. It is a proposal, not a standard.

• Merge automatically: a matching verified E.164 phone number (for example a customer entering it through Zalo and then a form), or a matching email.
• Flag for a person to review: the same phone number but a different name (a shared family or company number), or several profiles with the same generic company email.
• Do not merge: only the same name and province, or only the same device.

After each run, sample 50 merged profiles and count wrong merges, and keep a provenance log of each merge so it can be reversed. Click Star found no academic or standards source for these thresholds.

Consent and data-subject rights

According to a summary of Article 9 of the Law on Personal Data Protection No. 91/2025/QH15 (in effect January 1, 2026), consent is valid only when voluntary, clear, specific, given separately for each purpose and not bundled with consent to other purposes. Silence is not consent. Merging data across channels is a processing activity, so that purpose must sit within what the customer consented to.

According to EY Vietnam (March 3, 2026) on Decree 356/2025/NĐ-CP, consent must be provable (time and content stored) and not pre-ticked. A business must respond to a data-subject request within 2 working days, carry out viewing or editing within 10 days and deletion within 20 days (more time may apply when a third party is involved).

With Zalo, the user_withdraw event reports that a user has withdrawn consent, deleted data, restricted processing or objected, and Zalo expects the partner to delete the corresponding data. This webhook must trigger deleting or hiding the profile in your merged system. Click Star could not read the official text of the decree and does not give legal advice.

A 30-day plan

• Week 1: choose the join key (E.164 phone number, email), write the standardizing function, list the fields needed for each channel and record consent.
• Week 2: connect web forms (store gclid, fbclid, client_id) and the Zalo OA (webhook, user_external_id), and test with 20 trial customers.
• Week 3: connect Lead Ads with the leadgen webhook and connect the call log; apply the prefix table to old data.
• Week 4: switch on the merge rules, sample 50 merged profiles, test the consent-withdrawal webhook, measure duplicates and wrong merges.

Click Star's view. Get phone numbers and consent right before thinking about matching algorithms. Most of a small business's data merging can be solved with one well-standardized join key and cautious merge rules.

What is not known

Click Star could not read the detailed content of Zalo's ZBS Template Message update notice, has not verified Zalo message sending hours and content policy from a primary source, and found no price for sending by UID.

No official source states plainly that the same person has different PSIDs on different Pages, although the name "page-scoped" suggests it. There is no standard for call logs, and no official Google or Meta page on consent applicable to Vietnam. The prefix list comes from summaries and has not been checked against the original decision.

Common mistakes

1. Using phone numbers in hand-typed forms, each place its own style (0912, +84912, 84 912), so they do not match.
2. Treating a Zalo ID or PSID as a person's ID, when they are per OA or per Page.
3. Waiting to export Meta leads by hand and letting more than 90 days pass.
4. Merging automatically when only a shared family or company phone number matches.
5. Ignoring old 11-digit numbers in data that predates 2018.
6. Merging data without recording consent per purpose.
7. Not handling Zalo's consent-withdrawal events, so data stays in the system.