Article summary
TG Registration answers a narrow platform-state question; TG Activity returns a broader account and activity schema. Compare fields and use cases.
TG Registration and TG Activity are not low- and high-accuracy versions of one service. They are different tables for different questions. Registration is appropriate when a team needs a narrow Telegram registration-state result. Activity is appropriate when a justified workflow requires UserID, username, offline time, active days and other account fields. Writing the business decision first usually makes the task choice obvious.
Define each question in one sentence
| Task | What it answers | What it does not answer |
|---|---|---|
| TG Registration | Whether this phone returned a Telegram registration state in the run | When it was active, its username or whether contact is welcome |
| TG Activity | Account and activity-related fields for grouping and reconciliation | Verified identity, purchase intent or communication permission |
Compare the actual Excel schemas
| TG Registration | TG Activity |
|---|---|
| Phone | Phone, TG UserID, username |
| Registration result | Offline time, active days |
| — | First Name, Last Name |
| — | TG VIP state, frozen state |
More headers do not automatically make a result better. Registration is easier to explain when support routing only needs a basic platform-state cleanup. Activity becomes relevant when the organization has a defined need for dated activity observations.
Task choice in four operating scenarios
- Channel inventory: to review whether an existing customer’s chosen platform may be available, begin with Registration.
- Activity grouping research: when offline time or active days are necessary and approved, use Activity.
- Username reconciliation: when known Telegram accounts must be reconciled with internal records, Activity’s UserID and username are relevant.
- Marketing permission: neither task answers this; consult the independent opt-in and opt-out system.
Why one sample may produce different records over time
Run time, account-state changes, number reassignment, formatting errors and platform visibility can all affect observations. Do not overwrite one run with another as if one were timeless truth. Preserve task_name, batch_id, checked_at and the raw return value. Any comparison should state which task observed what and when.
Begin with TXT without uploading the CRM
AIPUSH accepts phone numbers in TXT only. Keep phone_raw, phone_normalized, contact_id and acquisition evidence inside the company’s own environment. The upload contains only the numbers needed for this run, one per line. When Excel is available, load it into staging and reconnect the result through contact_id or a controlled phone mapping.
Design two field groups in the CRM
A registration result can populate tg_registration_state and registration_checked_at. Activity belongs in separate fields such as tg_user_id, tg_username, tg_offline_time, tg_active_days and activity_checked_at. A single “TG status” column should never mix registration, activity and permission. Otherwise an operator can easily interpret “active” as authorization to contact.
Handle missing values and collisions explicitly
- Keep a missing value missing with a reason; do not silently convert it to not registered.
- Place a phone without country evidence in a format exception queue.
- Stop automatic merging when one contact_id maps to several UserIDs.
- Manually review a UserID that appears under multiple contacts.
- Retain previous observations and expose the latest through a dated view.
Choose the smallest schema that completes the decision
A broader task means more personal data to govern, more missing values to interpret and more permission controls to maintain. When registration alone completes the current cleanup, collecting usernames and activity data merely to look comprehensive creates unnecessary work. TG Registration fits a narrow platform-state question. TG Activity fits an approved broader question. Their value is determined by purpose, not column count.
