这是这轮讨论里最大的一处结构变化——它把整个层级倒过来了。 我去线上算了翻转之后的实际形态:好消息是身份 100% 可解析,零孤儿; 坏消息是有一类记录会直接把模型撑爆,必须在设计里处理掉。
能不能单独出一张提报表 / 进度表来审核 —— 实质上就是「对接人是不是同一批」。
这个定义的好处是它不是分类学,是组织边界:一个 Campaign = 一个审核面 = 一批客户侧对接人。 分类学会永远争论「Temu 日本 IG 算不算独立的」,而「谁来审这张表」是个有确定答案的事实问题。
落到今天的数据上:112 个 product 里,像 Temu-东南亚 / Temu-中欧 / Temu日本IG 这种按地区裂开的, 很可能是同一批对接人 → 合并;而 Temu-科技 / Temu-玩具 / Temu-IG女装 这种按品类裂开的,大概率是不同对接人 → 保持独立。
所以最终 Campaign 数会落在 49(纯品牌)和 112(现有 product)之间, 我估 60–80。而且这个判断只有运营能做——正因为如此,归类必须是一次人工动作, 不能指望规则自动切。112 行,半天。
100% 的存量 engagement 都能被「邮箱 or handle」识别到一个达人身份。 不存在无法归属的记录。这比我上一版估计的(33% 需要兜底)乐观得多—— 因为兜底键 creator_handle 的覆盖是完整的。
按邮箱聚合后,单个「达人」名下的会话数分布:
| p50 | p90 | p99 | 最大 | 说明 |
|---|---|---|---|---|
| 2 | 16 | 105 | 8,725 | 平均 9.2 —— 但尾部完全失控 |
去查那个 8,725 是谁,结果非常明确——全是 MCN / 经纪公司的公共邮箱:
| 域名 | 该域邮箱数 | 关联 engagement | 单个最大会话数 |
|---|---|---|---|
| slogansocial.com | 63 | 233 | 8,725 |
| influint.co | 22 | 151 | 7,604 |
| dolfincontent.com | 4 | 65 | 2,133 |
| tiddle.io | 25 | 162 | 1,904 |
| stride-social.com / influencernexus.com / purecreative.cz … | 各 1–5 | 14–29 | 684–867 |
一个经纪公司的邮箱代表的是很多个达人,不是一个。 如果按邮箱无差别合并,slogansocial.com 会变成一条名下有 233 次合作、 8,725 条会话的「超级达人」——这条记录在界面上打不开,在业务上也没有意义。
但要害不在于「需要一种新的 Engagement」,而在于——这个邮箱不该被当作身份合并键。 问题出在渠道那一层,不在合作主体那一层。
好在这类记录数量很少,可以精确圈出来:
Agency 是一种沟通渠道类型,不是一种合作主体。 我们只是给某个邮箱打一个标注,说「这是经纪渠道」——它和 Engagement 没有结构关系。
contact_channel(id, kind, address, label, channel_type, -- 'personal' | 'agency' | 'shared_inbox' mergeable) -- ← agency / shared_inbox 默认 false -- 身份合并只吃 mergeable = true 的渠道。 -- slogansocial.com 打上 agency 之后,它就不再是合并键, -- 它名下那 233 条合作各自按 creator_handle 归属到真正的达人。
① Engagement 不需要类型字段,永远只有一种:达人。
② 泳道模型不用开特例——泳道始终基于交付物,只是「联系方式」那一栏可能指向一个经纪邮箱。
③ 标注是渐进的。今天打 14 个,明天发现新的再打,不需要一次性把身份图算对。
≤5 次合作的邮箱自动合并(29,003 条,占邮箱身份 99.3%); >5 次的 197 条进队列,人只做一个判断:这是不是经纪渠道? 是就打标记退出合并,不是就正常合并。
一两个小时的活,而且判断内容非常轻——只看一眼域名就够了, 不需要理解业务上下文。
今天 Campaign(455,乱) ──▶ Engagement(活动×达人,51,402) ──▶ Deliverable(4,740, 52% 缺失) 同一个人在 8 个活动里 = 8 条互不相干的记录 之后 Engagement(达人本身) ├── identity[] email / phone / handle,可 merge / unmerge ├── kind individual | agency └── Collaboration[] 一次协同 = 一个 Campaign × 一轮 ├── campaign_id ← 稳定的归属(客户×产品线) ├── scouting_id ← 来源:哪一批找来的,只用于溯源 ├── reference_id ← Java 的 campaign×creator 键,挂在这一层 └── Deliverable[] 泳道。创建即至少一条
reference_id 是 Java 侧的「campaign × creator」键,今天它挂在 engagement 上, 还有一条唯一索引 coord_eng_active_ref_uq(活跃 engagement 内唯一)。 翻转后它必须下沉到 Collaboration 层——因为一个达人名下会有多个 reference_id。 这条索引的迁移是整个改造里最容易出事的地方,因为入站路由正依赖它。
| 阶段 | Engagement 是什么 | Tab 1 泳道 | Tab 2 CRM | Agent |
|---|---|---|---|---|
| 阶段一 Inbox 关 |
已经是达人级,名下多条会话 | 灰掉 / 只读 | 主力界面,纯人工沟通 | 停 suppress_received_channel_agent_runs |
| 阶段二 切回开启 |
同上,加 Collaboration + Deliverable | 主力界面,实时推进 | 继续可用,人随时插手 | 新版本,从消息重建状态 |
身份翻转只做一次,在阶段一就做完。 阶段一不需要 agent,所以翻转出问题时 影响面只有「界面上这个人的记录对不对」,而不会变成「把错的价格发给错的人」。 等身份稳定了、运营用顺了,再把 agent 装回来——这时它读的是一个已经被人工验证过的身份图。
数据取自生产库直查(2026-07-25):coordinator_engagements ·
engagement_channel_identities · coordinator_engagement_chat_threads ·
campaigns / products。
相关:Research/coordinator-vnext/04-vnext-architecture.md