Bulk Viber Activity Checker: CSV Upload and Result Export Guide
Activity data goes stale faster than any other signal in this stack. A format from March is still a format in July. An activity tier from March is a guess. So the CSV from a Viber Activity check is more than a result table. It is an activity archive with timestamps, and the columns you keep decide whether it stays useful. Bulk Viber Activity Checker is the ZelNum page tied to this job: Viber Activity Checker.
Quick answer
Build the CSV with one number per row, a record ID, an activity column, and a checked timestamp. The export keeps each row's tier: active, inactive, or not on Viber. Read active as reachable, inactive as a win-back list, not-on-Viber as another channel. Without the timestamp, the archive stops meaning anything the moment it is exported.
Two columns that make the file an archive
- Activity as its own column. Do not merge it into a status string. The activity tier is a decision input, and it needs its own place.
checked_aton every row. This is the column that turns the export into a time series. Without it, an active tier from March is a guess in July.
Keep both, and the file is worth re-reading. Drop either, and it is a table of numbers that used to mean something.
CSV setup
| Column | Why it is there |
|---|---|
record_id |
Joins the result back to the source. |
input_number |
The original value, unchanged. |
activity_tier |
Active / inactive / not on Viber. |
country_or_region |
The market read, if the list spans regions. |
checked_at |
The timestamp that makes re-checks comparable. |
Keep record_id as text. A numeric-looking ID can lose leading digits in a spreadsheet, and then the file cannot be joined back.
Example batch
Say a file holds 9,800 numbers. The export comes back 4,400 active, 2,900 inactive, 1,800 not on Viber, and 700 unknown. (All figures are illustrative examples, not performance benchmarks.)
The 2,900 inactive rows are the interesting part. A registration check would have called them reachable. Here they are a re-engagement list, and next quarter's run will show how many of them moved back to active. That movement, between this file and the next, is the report.
The four transitions that matter
With stable record IDs across two runs, every row lands in one of four transitions, and each has a different owner:
| Transition | What it means | Who acts |
|---|---|---|
| Active → Active | Stable, reachable, worth full-price sends. | Campaign team, no action. |
| Active → Inactive | Going quiet. Catch it early and the win-back is cheap. | Retention or lifecycle team. |
| Inactive → Active | Came back. The win-back sequence worked, or the account revived on its own. | Campaign team; promote back to the main list. |
| Inactive → Inactive | Two quarters dormant. The win-back has failed twice. | Downgrade to SMS or suppress. |
The Active → Inactive transition is the one worth alerting on. A single run cannot show it, which is the whole argument for keeping the archive and re-running on a schedule.
Routing the export
- Active → the Viber campaign.
- Inactive → re-engagement sequence or SMS.
- Not on Viber → another channel.
- Unknown → retry.
Route in the file, with the reason and timestamp on every row.
Joining with the registration check
The activity check answers "in use"; the registration check answers "account exists." Joined on record ID, they produce a two-by-two that routes more precisely than either alone. Registered and active is the main campaign list. Registered but inactive is the win-back list. In the usage check but not registered is rare and worth eyeballing, because it usually means a data issue in one of the two runs rather than a real account state.
Mistakes to avoid
- Treating the activity snapshot as permanent. The active tier from March is a guess in July. The re-check schedule is what keeps the file honest.
- Dropping the timestamp to keep the file tidy. That is the column that makes the archive an archive.
- Merging activity into a status string. A tier buried in a status field cannot be sorted, filtered, or compared.
- Suppressing the twice-dormant rows immediately. They are one run away from a decision; keep them in a downgrade bucket first, with the history attached.
FAQ
Why does activity data go stale faster?
Because activity is a behavior, not a property. A format does not change on its own; an account goes quiet on its own. The check window decides what the tier means, and the window moves.
What columns should the export have?
Record ID, original number, activity tier, country if relevant, reason, and checked timestamp. The timestamp is the non-negotiable one.
How do I compare two runs?
Keep checked_at on every record and aggregate by tier. The movement between runs is the report: how many inactive came back, how many active went quiet.
What do I do with inactive rows?
Route them to re-engagement or SMS. They are a win-back list, not a dead list.
Can I join this with a registration check?
Yes, on record ID. The registration check tells you on-Viber, the activity check tells you in-use. Together they give the full picture.
Related ZelNum pages
- Viber Activity Checker API Workflow for scheduled runs.
- How to Use Viber Activity Checker for Bulk List Checks with click-by-click steps.
- Viber Activity Checker Use Cases with per-team readings of the same output.
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 →