Zalo Number Checking for Beginners: Registration, Activity and Demographic Tasks

A beginner needs only three questions to choose a Zalo number-checking task: was platform registration observed, what activity observation exists, and does an approved analysis genuinely need profile fields? Each question has a different task. The most common beginner mistake is to combine all three into one vague idea of a “valid number.”

Meet three different answer sheets

Task	Main question	AIPUSH export
Zalo Registration	Observed platform-registration state	Phone, registration result
Zalo Activity	Account activity observation	Phone, user ID, activity time, nickname, active days
Zalo Gender and Age	Limited profile observation	Prior fields plus gender, age, avatar, people count, type and skin tone

Question one: are you mapping channel coverage?

If a well-sourced Vietnam customer list only needs an observed Zalo registration state, begin with Registration. It does not prove that a SIM remains in service, the account belongs to the original contact, the person will reply or a marketing message is permitted.

Question two: does the work queue need a time signal?

Choose Activity only when activity time and active days would change support or sales scheduling. Store the result with checked_at and an expiry. Recent activity is not purchase intent, and long-term unknown is not proof that a customer has no value.

Question three: which approved decision needs a profile?

Gender and Age is suitable for limited coverage studies or aggregate creative tests, not verification of personal identity. Age, gender, avatar, skin tone and avatar type can be unknown, change or relate to someone other than the phone holder. If no one can name the decision, do not collect the fields.

The first lesson in +84 preparation

Keep phone_raw and create separate phone_normalized and country_evidence fields. Do not guess a country from the first digits alone, and do not mix national trunk prefixes, country codes and legacy rules in one blind replacement. Uncertain rows become format_exception until a person or reliable source supplies evidence.

Prepare the smallest possible TXT

AIPUSH accepts TXT with one phone per line. Do not include name, email, order, nickname, conversation or permission label; those remain in internal CRM. Maintain a controlled crosswalk from TXT row to contact_id so returned Excel can be reconciled accurately.

Inspect structure on the first export

Check	What to inspect	Common misunderstanding
Task	Matches the selected question	Expecting profile fields every time
Rows	Unique inputs, returns and errors	Counting duplicates as coverage
Nulls	Unknown, error and no result are distinct	Treating blank as “no”
Reconciliation	Every row joins the original record	Pasting by spreadsheet order

Put a clock on every observation

User ID, nickname, activity and profile are observations rather than permanent facts. Store task, checked_at, schema_version and expiry. Append new history instead of overwriting old values, and stop automatic updates when mapping conflicts appear.

Separate “usable data” from “contact allowed”

Zalo registration or activity does not create permission. The message queue still checks source, channel scope, purpose, opt-out and frequency. A customer who refused marketing belongs in suppression even if activity appears recent.

A safe first project

Choose one country, one known source, one clear task and a small group of phones. Write expected fields and stop conditions, then review reconciliation, unknowns and exceptions before expanding. Do not connect multiple countries, several tasks and automatic marketing on day one.

A short task-selection rule

For “was registration observed?” choose Registration. For “what activity time was observed?” choose Activity. Choose Gender and Age only for a named, approved and non-high-risk aggregate study. Always treat telecom reachability, Zalo platform state, activity observation and contact permission as four separate matters.