Bulk Zalo Number Checker: CSV Upload and Result Export Guide
The CSV is not a way to get numbers into the tool. It is the deliverable, and on a Zalo file the country column is the main key. Drop it and the export becomes a list of numbers with no market story, and someone will run a campaign off a meaningless percentage. Bulk Zalo Number Checker is the ZelNum page covering this job: Zalo Number Checker.
Quick answer
Each row of the CSV carries one phone number, a stable record ID, and a country column that is actually filled in. Upload, check, and export with the on-Zalo status per row. Read the export by country, not as one number, because Zalo's reach is a Vietnam story and the rest of the file is a different conversation.
Vietnam number format traps
Most input problems on a Zalo file are Vietnam-specific, so fix them before the upload:
- The leading-zero trap. Vietnamese mobile numbers are written locally as
0901 234 567. Spreadsheets strip the leading zero and turn the number into a nine-digit fragment. Keep the number column as text in Excel, or store values in E.164 (+84901234567) from the start. - The
+84country code. If your source system omits it, the checker has to infer the country, and inference is where mixed files go wrong. A filled country column plus a clean country code beats guessing. - Old number formats. Vietnam renumbered its mobile ranges years ago; older CRM exports can still carry pre-migration values. If a file comes from a system that has not been touched since, spot-check a few rows before the bulk upload.
Keep the original value in an input_number column no matter what. When a result looks wrong, the first question is always "what exactly was uploaded", and the original column is the only honest answer.
Build the CSV so it survives the round trip
- One number per row. No notes column inside the list, no merged cells, no hidden rows.
- Keep
record_idas text. A CRM id that looks numeric can lose leading digits in a spreadsheet. - Keep the country column, filled. This is the field that makes the export readable.
- Leave duplicates in. The duplicate count is a signal in itself, and the checker reports status per row.
The two-market read
A mixed file comes back with two very different shapes:
| Part of the file | Typical on-Zalo share | What it means |
|---|---|---|
| Vietnam rows | 78-84% | Zalo is the campaign channel. |
| Regional rows | 3-6% | Zalo is not the channel; route to SMS. |
(These ranges are illustrative, not a measured benchmark.)
A flat overall number hides this. The export should show the country split explicitly, either as a column or as separate result segments, so the reader cannot miss it.
What belongs in the export
| Column | Why it is there |
|---|---|
record_id |
Connects each result to its source file. |
input_number |
The original value, unchanged. |
normalized_e164 |
The value in a comparable form. |
on_zalo |
The channel signal this check exists to produce. |
country_or_region |
The key that decides how to read the row. |
status / reason |
The routing decision and why. |
checked_at |
The timestamp that makes re-checks comparable. |
Routing the export
Split the export into named segments instead of one file with a status column nobody filters:
zalo_vn_ready— Vietnam rows with on-Zalo status. Straight to the Zalo workflow.vn_sms_fallback— Vietnam rows, valid, not on Zalo. The number is good; the channel is SMS.regional_sms— everything outside Vietnam, regardless of on-Zalo status.repair_or_suppress— invalid rows, with the reason attached.retry_queue— unknown rows, held for the next run.
Route in the file, not in your head. The whole point of the export is that each row carries its decision, and a named segment makes the decision survive the handoff to whoever runs the campaign.
Re-check mechanics
Keep the same record IDs across runs. The interesting report is not the current snapshot but the movement: rows that flipped from on-Zalo to not-on-Zalo, unknowns that resolved, the Vietnam share drifting quarter over quarter. Two exports with stable IDs turn into that report with one pivot table. Two exports with regenerated IDs turn into nothing, because nothing joins.
Mistakes to avoid
- Dropping the country column to save space. That is the column that gives the file its meaning.
- Letting the spreadsheet eat leading zeros. Import as text, or normalize to E.164 upstream.
- Reading one percentage for the whole file. It’s the Vietnam figure that drives the campaign decision, while the regional figures act as warnings.
- Treating the export as a one-time result. Without a re-check schedule, the file quietly goes stale.
FAQ
Why is the country column the main key for Zalo?
Because Zalo's reach is concentrated in Vietnam. The on-Zalo signal means one thing in the Vietnam rows and another in the regional rows, and the country column is what separates them.
What if my file is all Vietnam numbers?
Then the market read is simpler: the on-Zalo share is directly the campaign signal. Keep the country column anyway for consistency across files.
Can I re-check the same CSV?
Yes. Keep the same record IDs and compare the on-Zalo status between runs. The movement between runs is the report that matters.
What do I do with unknown rows?
Hold them for retry and re-check. Unknown is a queue, not a dead end, on a Zalo file.
Should I merge duplicates before uploading?
No. Keep them in — the checker reports on each row individually, and the duplicate count is itself data.
Related ZelNum pages
- How to Use Zalo Number Checker for Bulk List Checks walks through the workflow step by step.
- Zalo Number Checker Use Cases maps result rows to team decisions.
Ethan works on phone-number normalization, E.164 formatting, country-code rules, carrier metadata, and line-type detection. His editorial work turns verification signals into practical workflows for CRM cleaning, SMS preparation, lead review, and bulk data operations.
View full author profile →