钱包、TG账号和手机号能放在一张表吗？Web3线索的三实体模型

把钱包地址、TG用户名和手机号塞进同一行，会给人一种“这三个标识一定属于同一个人”的错觉。Web3营销更需要关系表，而不是更宽的联系人表：每种标识独立存在，关联必须带证据和日期。

三种实体回答三种问题

问题出在“一行一人”假设

一个人可能管理多个钱包，一个团队可能共用运营账号，手机号也可能被重新分配。单行模型只能覆盖这些现实，不能表达它们；最后只能靠覆盖旧值维持表面整洁。

关系边应该带哪些证据

保存from_entity、to_entity、evidence_type、captured_at、source与confidence。用户签名、登录绑定、客服人工确认和表单自报不是同一强度；推测关系必须与已验证关系分开。

TG筛号放在账号观察表

TG筛开通返回手机号与是否开通；TG筛活跃可返回UserID、用户名、离线时间、活跃天数、姓名、VIP和冻结观察。它们更新Telegram观察，不自动创建phone_owns_wallet关系。

一个典型的错误合并

营销表里某手机号对应用户名A，活动表里用户名A填写钱包B，于是系统宣布手机号持有人控制钱包B。若用户名曾更改、共享或录入错误，三个系统都被误合并。正确做法是保留两条来源边并等待更强证据。

Web3分层应该看组合，而非身份猜测

• 已验证关系＋明确许可：进入相应用途；
• 链上事件＋无联系许可：只做聚合研究；
• TG观察＋钱包关系未知：不拼接画像；
• 标识冲突：交人工或重新验证。

TXT上传保持单一职责

每行只放需要检测的手机号。钱包、UserID、社区角色和许可留在企业内部，以batch_row回连Excel。任务文件不应成为完整的Web3身份图谱副本。

给关系设置失效机制

账号改名、手机号回收、钱包转移或授权撤回都会使边失效。关系表应保存valid_from、valid_to和revoked_reason，而不是只保留一个永远正确的current_owner。

营销团队真正需要的视图

运营视图显示可用渠道、许可用途、最近业务事件和需要复核的冲突；分析视图尽量聚合链上行为。两者都不需要宣称已经识别了链上地址背后的真实个人。

模型的价值在于允许说“不知道”

Telegram的隐私政策说明平台数据有自己的处理语境。三实体模型同样把未知当成正常状态：缺少证据时不补关系，反而让后续验证更可靠。