NexCheck-筛号平台
假设你手上有一份从 CRM 导出的联系人名单，五六千条手机号，混着几个国家，有的带 +，有的带本地前导 0，还有同一个人登记了两次。业务方想知道：这里面哪些人在用 Telegram，哪些人最近还在用。
结论先说：Telegram 筛号能告诉你号码是否对应可检索到的 Telegram 账号，以及这个账号大致多久前在线过。但它给出的活跃度是模糊区间，不是精确时间。另外，查不到的号码不一定就没注册。名单要先清洗再提交，结果按“有效 / 无效 / 活跃程度”分组后回写。
处理顺序
- 统一格式：所有号码转成国际 E.164 写法。
- 去重：用规范化之后的号码去重，不要用原始字符串去重。
- 按国家拆分：每个国家或地区代码单独成一批。
- 提交检测：通过控制台上传，或者调用 API 提交。
- 读结果：先看是否开通，再看在线区间。
- 分组回写：把检测结果和检测日期写回 CRM，原始号码保留不动。
下面按这个顺序说明每一步要注意什么。
提交前：格式、去重、拆分
E.164 的写法是 + 加国家代码加用户号码，去掉本地拨号用的前导 0，中间不留空格、横杠或括号。例如英国本地写法 07700 900123，规范化后是 +447700900123。
去重要放在格式统一之后做。+44 7700 900123 和 07700900123 是同一个号码，只有统一格式以后才能识别出来。如果带着重复项提交，同一号码会被检测两次，费用也算两次。去重的具体规则和常见坑，可以参考号码去重：先统一成 E.164 再按规范号码去重，多国名单的格式纠错见号码格式错误的 E.164 标准写法与多国名单规范化顺序。这两篇虽然以 WhatsApp 为例，格式规则对 Telegram 名单同样适用。
按国家拆分有两个好处。一是不同国家的号码长度和特殊编码规则不同，分开处理更容易发现格式异常。二是结果出来后可以直接按市场对比开通率，不用事后再拆。各国号码格式和当地主流平台，可以在区域页面查到。
清洗时把转换失败的号码单独放一个文件，比如位数不对、国家代码缺失的号码。这些号码先回去核对来源，不要硬塞进检测批次。
提交检测：网页端还是 API
在 NexCheck 里，这份清洗好的名单有两种提交方式：
- 控制台上传 txt 或 csv：适合一次性或不定期处理名单的运营和市场同事，上传后按有效与无效分组导出结果。
- REST API 提交：适合要把检测接进 CRM 或数据管道的开发者。单批不限量，结果可以通过 Webhook 异步回推，不用轮询。
计费按条，检测项和单价以平台价目表为准。Telegram 具体能查哪些字段、每项怎么收费，可以在 Telegram 平台检测页查看。检测项会调整，以页面当前内容为准。名单是你自己的数据，平台只在任务范围内处理，来源和用途是否合法需要你自己保证。
读结果：在线状态是区间，不是时间点
判断活跃度时，最常用的依据是 Telegram 的“最后在线时间”（Last seen）。用户隐藏了精确时间，或者查看方不是对方的联系人时，Telegram 只显示四档模糊状态：
| 状态 | 大致含义 | 对名单的意义 |
|---|---|---|
| Last seen recently | 最近 2~3 天内在线过 | 近期活跃 |
| Last seen within a week | 大约 2~3 天到 7 天 | 一周内用过 |
| Last seen within a month | 大约 6~7 天到 30 天 | 一个月内用过，活跃度在下降 |
| Last seen a long time ago | 超过一个月；被对方拉黑时也会显示这一档 | 沉睡风险高，需要谨慎对待 |
各档之间的边界故意设计成重叠、不精确，这是 Telegram 的隐私保护。所以分组时不要把“recently”理解成“今天在线”，也不要据此推算具体天数。比较稳妥的做法是把四档直接作为四个标签存下来。
“A long time ago”这一档还要结合 Telegram 的账户自动注销机制来看。账户在设定周期内完全没有上线，就会被平台永久删除。这个周期默认是 6 个月，用户可以改成 1 到 24 个月之间。所以长期停在这一档的号码，有较大可能已经是沉睡号，甚至会在之后的复查中变成未开通。建议给这类号码设一个复查时间，不要直接当作有效联系人长期保留。
是否开通和在线区间之外，注册时间、性别年龄这类属性能不能查，取决于平台当前提供的检测项，也受用户公开资料设置的影响。这些属性在 Telegram 上没有统一的判定基准，以平台页的说明为准。用作参考字段比较合适，不建议作为硬性筛选条件。
隐私边界：“查不到”不等于“没注册”
Telegram 注册需要手机号，但用户可以在“隐私与安全”里设置谁可以通过手机号找到我。如果用户把范围收紧到只有自己的联系人，外部系统即使持有这个号码，也可能在平台内匹配不到对应账号。在检测结果里，这类号码可能表现为无结果或未开通。
不同检测接口对这类高隐私用户怎么标记，目前没有统一规范。有的单独标出来，有的直接归入未开通。因此建议这样处理：
- 把检测结果里的“未开通”在 CRM 里记为 “Telegram 未检索到”，不要写成“确认未使用 Telegram”。
- 有其他渠道证据表明对方在用 Telegram 的号码，比如客户自己提供过用户名，以那条证据为准，不要被检测结果覆盖。
- 不要尝试用自建脚本或其他手段绕过对方的隐私设置。检测只读取平台对外可得的状态。
分组与回写
导出后，建议至少回写这几个字段：
tg_status：已开通 / 未检索到tg_last_seen：recently / within_week / within_month / long_ago（只对已开通号码填写）tg_checked_at：检测日期- 原始号码和 E.164 号码各占一列，方便日后追溯
检测日期很重要。Telegram 的在线状态会持续变化，加上自动注销机制，一个月前标为“within a month”的号码，现在可能已经掉档。可以按业务需要设定复查周期。“long ago”和“未检索到”这两组复查间隔短一些，“recently”这组可以长一些。
用 API 接入的团队，可以让 Webhook 回推的结果直接触发 CRM 字段更新。用控制台的团队，按有效、无效两个文件导出后，用 E.164 号码作为匹配键回写，不要用原始号码匹配，否则清洗前格式不一致的记录会对不上。
名单清洗好之后，可以先到 Telegram 平台检测页确认当前检测项和单价，再决定走控制台还是 API。
评论(0)