Article summary
Connect contact_id mapping, TXT upload, Viber task selection, Excel staging and collision handling without overwriting the customer master.
Connecting Viber checking to CRM is not about “importing the spreadsheet.” It is about creating a reversible observation layer. Task results are dated, can be missing and may differ from history. They must not overwrite customer-provided phone, nickname or permission. contact_id mapping, staging and conflict queues come first.
Start with an internal key, not the phone
Create contact_id and retain phone_raw, phone_normalized, country_evidence, source and permission. Phones may repeat, be shared, be reassigned or change notation; they cannot serve as a permanent identifier alone.
| Layer | Main fields | Write pattern |
|---|---|---|
| Customer master | contact_id, customer-provided data | Human/business workflow |
| Phone relationship | raw, normalized, valid_from | Versioned history |
| Task observation | task, batch, checked_at, return values | Append only |
| Permission | channel, scope, opt_out | Independent veto |
Keep a crosswalk when creating TXT
AIPUSH accepts TXT with one phone per line. The upload contains no contact_id, name or order, so store export_row, normalized phone and contact_id internally. Record the TXT hash, count and cleaning-rule version.
Choose the Viber task by business question
| Task | Actual fields | Use |
|---|---|---|
| Viber Registration | Phone, registration result | Platform registration state |
| Viber Activity | Phone, active days, mid, user offline time | Dated account observation |
| Viber Gender and Age | Phone, skin tone, gender, nickname, active days, mid, offline time, avatar people/type, age, avatar | Approved wider-field study |
Load Excel into raw staging first
Preserve column names and missing values, then append ingested_at, batch_id, task_name and source_file_hash. Convert types in a standardized view afterward. If an import rule fails, the original evidence remains available.
Give blanks and errors separate states
Not returned, unknown, unavailable, format error and explicit negative remain distinct. An empty registration cell must not become false automatically, and blank user offline time does not mean “always online.”
mid is a platform identifier, not the CRM master
mid may support reconciliation inside the task domain, but it does not replace contact_id without governance. One phone with several mids, several contacts sharing a mid or a historical mid change enters identity_conflict with every observation retained.
Place profile fields in a restricted domain
Skin tone, gender, age, avatar and nickname should not appear in every support view. They may be missing, inaccurate or unrelated to the account holder and must not support identity, credit, employment or sensitive targeting decisions.
Expire activity observations
active days and user offline time carry checked_at and refresh_after. After expiry, mark them stale and stop using them for ranking rather than automatically rechecking all CRM records. Rerun only a minimal subset with a continuing lawful purpose.
Permission cannot be merged with platform results
Viber registration, recent activity and an existing mid do not create marketing permission. Query provenance, Viber scope and suppression before a contact queue. A fresh workbook never revives an opt-out.
Rehearse rollback before launch
Use a small batch to test row count, duplicate, unmatched, one-to-many, blank and encoding paths. Confirm that deleting this observation batch restores the previous CRM view without losing the customer master. Only a reversible integration is ready to scale.
