Article summary
Understand the difference between WhatsApp Full-Format Checking and number normalization, including TXT preparation, Excel fields, use cases, and evidence limits.
WhatsApp Full-Format Checking is a batch phone-number task that returns several groups of WhatsApp-related fields. It is not an automatic country-code repair tool, and it is not another name for converting every local number into an international format. Number normalization happens before upload; Full-Format Checking happens after the input has been prepared.
Mixing these stages creates a spreadsheet with many columns but weak traceability. The reliable order is to confirm provenance and country data, build a one-number-per-line TXT file, and then select Full Format only when its broader field set is genuinely required.
The distinction: normalization determines which number you submit; Full Format determines which supported columns the completed task returns.
Which fields can WS Full Format return?
AIPushAI’s current WS Full-Format Excel output can include phone number, activity time, active days, gender, age, profile picture, skin tone, picture type, business-account status, and mapped WhatsApp number. “Full format” describes a broader output schema. It does not mean that every cell will be populated or that customer identity has been verified.
| Excel field | What it records | Reasonable use | What it does not establish |
|---|---|---|---|
| Phone number | Number processed in this task | Match the TXT row to the internal master | The verified real-world owner |
| Activity time / active days | Activity signals supported at check time | A dated channel reference | Online now or likely to reply |
| Gender / age | The corresponding task output | A governed field where a lawful purpose exists | Legal identity or exact demographics |
| Picture / skin tone / picture type | Supported image-related output | A tightly defined review workflow | Nationality, income, or purchase power |
| Business account | Business-account result returned by the task | Store separately from the original number | Business verification or buying intent |
| Mapped WhatsApp number | A mapped number returned by the task | Preserve beside the source value | Permission to overwrite the source number |
What does number normalization do?
Normalization creates a consistent, reviewable international representation for the same number. The ITU-T E.164 international numbering plan defines the international number structure and distinguishes country codes, national significant numbers, and prefixes used for domestic dialing. A country must not be inferred from length alone, and the same country code must not be blindly prepended to every row.
| Source condition | Normalization action | Reason |
|---|---|---|
| Country known; number stored domestically | Apply the country’s numbering rule and handle its domestic prefix | A domestic access prefix may not belong after the country code |
| Number already has +country code | Remove display punctuation and validate | Prevents duplicate country codes |
| Country code appears without + | Confirm against the country field before standardizing | Leading digits alone are not enough evidence |
| Country unknown or ambiguous | Send to an exception queue | A wrong code creates a different but plausible-looking number |
| Spreadsheet shows scientific notation | Return to the original text field | Digits or the plus sign may already be lost |
Keep raw phone, source country, normalized phone, and internal ID as separate columns in the controlled master file. Only normalized phone numbers go into the AIPushAI upload. That reduces submitted data and preserves the bridge needed to reconnect the Excel result.
When is Full Format the right task?
Write the business question before choosing a service. If the only question is whether numbers are registered, Registration Check is sufficient. If the question concerns supported activity signals, Activity Check is more direct. Full Format becomes appropriate only when several supported fields feed a defined and governed workflow.
| Question | Better-fit task | Current core fields |
|---|---|---|
| Is this number registered on WhatsApp? | WS Registration / Fast Registration Check | Phone number, registration status |
| Do we need high-precision registration-related and mapped fields? | WS High-Precision Registration Check | Phone, business account, mapped WhatsApp number |
| Do we need dated activity signals? | WS Activity Check | Phone, activity time, active days, mapped number |
| Do we only need picture and business fields? | WS Profile Picture Check | Phone, business account, picture, mapped number |
| Are multiple activity, demographic, and image fields necessary? | WS Full Format | Ten supported fields |
“More columns” is not a complete requirement. Every additional field creates interpretation, access-control, retention, and deletion work. If nobody can name the decision a field supports, use a smaller task.
A reviewable source-to-TXT process
- Freeze the source: retain a read-only export with source system, date, purpose, and owner.
- Confirm country evidence: use a form country, order address, or verified customer record rather than guessing from length.
- Remove display characters: clean spaces, brackets, hyphens, and extensions without blending names or notes into the phone field.
- Normalize before deduplication: two display formats may represent the same number.
- Build an exception queue: pause rows with unknown country, suspicious length, or uncertain fixed/mobile type.
- Export UTF-8 TXT: one phone number per line, without headers or extra columns. Excel and CSV are not accepted AIPushAI input formats.
Start with a representative sample. The purpose is not to estimate conversion; it is to test encoding, accepted-row counts, column names, missing values, and number mapping.
How should the Excel output be accepted?
Preserve an untouched copy of the export. Reconnect a working copy through normalized phone or an internal mapping table. Never overwrite the raw phone with the mapped WhatsApp number, and do not turn every blank cell into “no.”
| Acceptance layer | Check | If it fails |
|---|---|---|
| File | Task name, export time, column headers, worksheets | Stop the import and confirm the correct task |
| Counts | Unique TXT rows, accepted rows, results, exceptions | Explain the difference; do not fill it with defaults |
| Mapping | Source and mapped phones remain separate | Sample against the original TXT |
| Missing values | Which fields are blank and whether blanks cluster | Keep unknown and attach checked-at time |
| Governance | Purpose, access, retention, deletion | Do not send unnecessary fields downstream |
Four questions Full Format cannot answer
- It cannot prove permission. The WhatsApp Business Messaging Policy requires a business to obtain the person’s phone number and opt-in permission before contacting them and to honor opt-outs. A checking result is not an opt-in record.
- It cannot prove identity. Picture, age, or gender output does not replace first-party identity confirmation.
- It cannot predict conversion. Activity fields are not purchase intent, income, or a close probability.
- It is not permanent. The output is a point-in-time result and belongs with its task date.
A final task-choice checklist
- Does the workflow need several Full-Format fields rather than registration or activity alone?
- Does every column have a purpose, access owner, and retention period?
- Is the country code supported by source evidence?
- Is the upload UTF-8 TXT with exactly one phone number per line?
- Are the raw list, mapping table, and sample acceptance record preserved?
- Will CRM continue to decide permission and opt-out status independently?
When the requirement is ready, choose the matching task on the AIPushAI WhatsApp (WA/WS) Number Checker. Narrowing the question before expanding the schema produces output that is easier to explain, import, and govern.
