联系人列表中的 Telegram 不活跃账户：如何识别与分段

本文介绍了一种实用的工作流程，即利用注册结果和“最后活跃天数”的近似数据来识别联系人列表中的 Telegram 不活跃账户，并根据各团队自行设定的阈值进行处理。

要识别联系人列表中的 Telegram 不活跃账户，首先需要将完全没有 Telegram 账户的号码与已注册的号码区分开，然后查看每个已注册账户沉寂了多久。TG Validator 的批量活跃度服务 (tg_active_batch) 会返回注册状态以及 activedays（自上次活跃以来的近似天数），以便团队将联系人归入其自定义的活跃度区间。这些区间有助于规划清理或重新互动工作；它们代表的是近似的历史记录，而非实时的在线状态，且截止点由团队自行选择。

Telegram 联系人列表中的“不活跃”含义

针对此问题的多数搜索结果都在解释个人用户如何查看 Telegram 应用中的“最后上线时间”标签。而处理 CRM 导出数据或潜在客户列表的团队则面临不同的挑战：面对成百上千个电话号码，无法逐一打开每个个人资料，且需要决定如何处理每条记录。

对于列表处理而言，“不活跃”通常涵盖三种需要不同处理方式的情况：

随着时间推移，第四种情况也至关重要。根据 Telegram FAQ，如果账户在设定的期限内未上线，系统会自动将其删除；用户可在设置中更改该期限，FAQ 给出的默认值为 18 个月。因此，一年前注册的号码在后续检测中可能会返回 未注册 的结果。将每次检测结果视为有时效性的数据，而非永久结论，有助于保持列表的准确性。

为什么仅靠 Telegram 应用无法实现活跃度审查的规模化

在应用内部，联系人的活跃度显示为“最后上线时间”标签，且 Telegram 允许用户隐藏具体时间。Telegram FAQ 描述了显示的近似标签：“最近”涵盖从刚才到两三天前，“一周内”和“一个月内”涵盖更长的时间间隔，而“很久以前”意味着超过一个月。用户可在其隐私和安全设置中选择谁能看到此信息。

这种设计对列表所有者产生了两个影响：

• 人工审查速度缓慢。 仅为了读取标签而将号码添加到手机通讯录对于任何有规模的列表都不可行，且会将业务数据混入个人设备。
• 数据本质上是近似的。 即使是完美的人工审查，对于许多联系人也只能得出宽泛的范围。

TG Validator 针对其自身的活跃度数据也记录了同样的局限性：activedays 是自上次活跃以来的天数，当 Telegram 隐藏了确切的最后上线时间时，该数值可能是近似值。任何分段计划都应围绕范围构建，而非追求单日精度。

哪些 TG Validator 服务返回活跃度数据

TG Validator 提供一种单次响应检测和五种异步批量服务。其中只有部分服务包含活跃度信息，因此服务的选择决定了是否能够进行不活跃度审查。

对于少量号码，仪表板的“单次检测”或实时“批量检测”选项卡（最多可粘贴 500 个号码）可在同一会话中显示注册状态，这对于抽查非常有用。完整列表的活跃度区间来自批量活跃度任务，这是一种“上传-等待-下载”的工作流程，而非单次响应检测。如果 activedays 等列为空，请将该记录视为“活跃度未知”，而非不活跃。

分步指南：识别联系人列表中的 Telegram 不活跃账户

1. 仅导出任务所需数据。 提取电话号码（或用户名）以及您的 CRM 键值，以便后续关联结果。上传文件中请勿包含姓名、电子邮件和备注。
2. 将电话号码标准化为 E.164 格式。 每行应包含加号、国家代码和国家内号码，且不含空格或主干前缀，例如英国手机号码应写为 +447700900123。
3. 按国家/地区拆分。 电话号码批量任务需要选择一个国家/地区，且文件应主要由该国家的号码组成；包含大量其他国家代码的文件将被拒绝。用户名文件无需国家/地区信息，且接受带或不带 @ 的用户名。
4. 创建任务。 在仪表板的“批量检测”区域，或通过 POST /api/v1/bulk-tasks，上传每行一个条目的 TXT 或 CSV 文件，并选择 tg_active_batch（电话）或 tg_username_profile_batch（用户名）。各产品的文件限制适用；当前 API 文档中列出了这些限制。
5. 等待并适度轮询。 使用 GET /api/v1/bulk-tasks/{id} 检查任务状态，频率不要超过每 30 秒一次，直到报告成功或失败。任务没有单号码进度显示。
6. 下载 result.csv。 该文件包含标识符和 activated 列，以及所选服务的额外列；部分额外值可能为空。
7. 关联并分段。 通过标识符将每行结果关联回 CRM 记录，然后应用下述团队自定义的活跃度区间。
8. 记录检测日期。 存储活跃度数据的生成时间，以免后续决策基于过时的号码。

设置您自己的活跃度阈值

TG Validator 不定义何为不活跃。阈值是一项业务决策，取决于列表的目的、销售周期和团队的许可规则。下表中的区间仅供内部讨论参考，而非产品建议：

以下准则有助于保持区间的实用性：

• 使用宽泛的范围。 由于 activedays 可能是近似值，30 天与 31 天的界限意义不大。宽泛的区间可以吸收这种不确定性。
• 对照您自己的互动数据。 如果您的 CRM 回复集中在某个区间，请根据该证据调整截止点，而非遵循通用规则。
• 将注册结果分开处理。 没有 Telegram 账户的记录并非“非常不活跃”；它属于工作流程中的不同分支。
• 按列表分别决策。 社区重新激活列表和销售潜在客户列表可能需要不同的区间。

清理 Telegram 不活跃联系人时的常见错误

• 将活跃度解读为实时在线。 activedays 描述的是检测时的近似历史记录。它并不说明某人现在是否在线或是否会阅读消息。
• 将注册结果为 已注册 视为互动。 单号码检测仅返回 Telegram 注册状态。这只是一个账户存在信号，因此活跃度问题需要批量活跃度数据。
• 直接删除记录。 沉寂的 Telegram 账户并不能说明电子邮件或电话的可达性。归档记录中的 Telegram 渠道通常比删除联系人更安全。
• 在同一个电话文件中混合国家/地区。 上传前请按国家/地区拆分导出文件，以免任务被拒绝。
• 轮询过于频繁。 轮询频率超过每 30 秒一次会增加负载，且不会加快结果获取速度。
• 忽视许可。 在 Telegram 上存在并不代表拥有联系对方的许可；外呼仍取决于团队针对该渠道所持有的许可。
• 永久保留活跃度数据。 活跃度值会迅速老化。请存储检测日期，并按计划刷新或丢弃旧值。

重新检测频率与数据处理

活跃度数据会随着时间的推移而失去价值，且账户在长期不活跃后可能会被删除，因此一次性审查会逐渐过时。一种常见的模式是在每次大型活动前或按固定的季度周期重新运行批量活跃度任务，并且仅对实际将要联系的记录进行重新检测。

数据保护规则也决定了结果的保存期限。根据 GDPR 第 5 条，个人数据应限于实现目的所必需的范围，并保持准确和最新。在实践中，这意味着存储区间和检测日期，而不是存储每一列原始数据；如果工作流程未使用头像或个人资料估算值，则应将其丢弃，并记录存在活跃度字段的原因。来自 tg_profile_batch 的结果包含基于头像的年龄、性别和肤色值，这些是估算值而非已验证的身份，这也是在仅关注活跃度时选择 tg_active_batch 的另一个原因。

对于首次评估该服务的团队，注册用户可联系支持团队获取 100 次免费检测，当前计划详情请见 定价页面。

常见问题解答

团队如何在不打开每个个人资料的情况下判断 Telegram 联系人是否不活跃？

将列表作为批量活跃度任务上传（电话号码使用 tg_active_batch，用户名使用 tg_username_profile_batch），并读取 result.csv 中的 activedays 列。它提供了每个匹配账户自上次活跃以来的近似天数，随后可将其归入团队自定义的区间。

什么样的阈值应被视为不活跃的 Telegram 账户？

没有产品定义的阈值。团队通常从宽泛的区间开始，例如 0-30、31-90、91-365 和 365 天以上，然后根据其自身 CRM 数据中回复和转化实际发生的位置调整边界。

为什么 activedays 数值有时为空或为近似值？

TG Validator 记录了当 Telegram 隐藏确切的最后上线时间时，activedays 可能是近似值，且根据所选服务，额外列可能为空。空值应存储为“活跃度未知”并留待后续审查，而不应视为沉寂。

单号码 Telegram 检测显示活跃度吗？

不显示。通过仪表板或 POST /api/v1/check 进行的单次响应检测仅返回 Telegram 注册状态。活跃度数据来自批量活跃度和个人资料服务，这些服务作为异步文件任务运行。

联系人列表应多久重新检测一次 Telegram 活跃度？

在每次大型活动前或按季度等固定周期进行检测对许多团队有效。仅对将要联系的记录进行重新检测可以降低数据量，而存储检测日期可以明确何时区间已过时，不宜再作为参考。

了解更多

选择适合您工作流程下一步的产品信息。

• 查看产品文档 →
• 联系团队 →