Article summary
A diagnostic tree separating format errors, telecom empty-number status, Zalo registration observations and activity observations so unknown never becomes nonexistent.
“Zalo empty number” often compresses four different events into one phrase: a format problem, telecom-network state, no observed Zalo registration, or no activity result. They have different sources and meanings. A negative Zalo Registration result is only a platform observation under the task definition; it cannot declare that the phone does not exist.
Start with a diagnostic tree
- Can the phone be parsed under country rules? If not, create format_exception.
- Does the decision require telecom state? Obtain it from a separate appropriate source.
- Is the question observed Zalo registration? Use Registration.
- Is an activity time also needed? Use Activity only for a valid purpose.
Every step has unknown and error exits rather than pushing failure into “empty.”
The boundary among four questions
| Question | Proper meaning | It cannot prove |
|---|---|---|
| Format exception | Current rule cannot parse reliably | The phone does not exist |
| Telecom empty state | State from a named telecom source | Zalo must be unregistered |
| No Zalo registration observed | Task did not return registration | The SIM is inactive |
| Activity unknown | No usable activity observation | No one uses the account |
Why a valid format is not enough
Syntax only says a phone fits a structural rule. It says nothing about assignment, reachability or ownership. Preserve phone_raw, country_evidence and normalization_version. Do not add +84 when country evidence is weak, and do not ask one regular expression to perform telecom validation.
The Zalo Registration output
AIPUSH Zalo Registration exports phone and registration result. Store it in platform_registration_observation with task_id and checked_at. A negative return never overwrites telecom data, while unknown and system error remain separate states.
When Activity is actually needed
Zalo Activity provides phone, user ID, activity time, nickname and active days. Run it only when an activity observation changes a lawful, named support or operations decision. It is not an upgraded empty-number test, and it cannot guarantee message delivery or response.
Field names influence misuse
| Avoid | Prefer | Reason |
|---|---|---|
| is_valid | format_parse_state | Format is not total validity |
| is_empty | telecom_observation | Bind source and time |
| has_zalo | zalo_registration_observed | Emphasize observation |
| active_user | zalo_activity_observed_at | Avoid permanent labels |
One TXT batch asks one question
AIPUSH input is one phone per line as TXT. Do not create a filename that vaguely combines empty, registration and activity. The manifest names task_type; returned Excel is accepted against its expected schema and joins through the crosswalk rather than row position.
Handling contradictory results
A telecom anomaly may coexist with historic Zalo observation, or registration may be explicit while activity is unknown. That does not automatically mean system failure. Migration, timing, cache, account change and source definitions can differ. Preserve both layers and times, then route to review instead of overwriting one.
Business rules use combinations
A support queue may require valid source, current permission and a fresh Zalo registration observation while allowing activity unknown. A phone-governance job may care only about formatting. Each purpose selects its layers; never create one company-wide valid_phone=true field.
The accurate answer to “how do I detect empty numbers?”
First decide whether the question concerns telecom state or Zalo platform state. Telecom empty status requires telecom evidence. Zalo Registration answers platform-registration observation, and Activity answers another time-bound account question. Precise wording selects the right task, produces the right interpretation and prevents wrongful customer deletion.
