我去线上把 455 条 campaign 全拉出来看了。你说的四种滥用——按月、找不到人、换平台、换国家—— 全都能在真实数据里指出来。但真正的问题不是滥用本身,而是: Java 那边从上到下三层,没有任何一层是稳定的。
455 条 campaign 里,402 条(88%)不是第一次尝试,平均 attempts = 14.2。 下面是 capcut-yt-2605-53 这一个 group 的真实记录,按 attempts 排序:
换国家那一类在 MiniMax 上最典型——同一个活动,一个国家一条记录:
这不是有人乱来。「换一个国家/平台就得开一条新 campaign」是那个系统的建模方式决定的—— 因为 campaign 同时承担了「投放对象定义」和「一次招募尝试」两个职责,而这两件事的变更频率差一个数量级。
Coordinator 的 schema 其实已经预留了分层: products(= scheduler 的 project)→ campaign_groups → campaigns, 而且 campaigns.attempts 就是重试计数器。设计者预见到了这件事。
问题是上面两层同样在按地区/品类/平台裂开。 以 Temu 为例:
| product(= scheduler project) | campaign 数 | 裂开的维度 |
|---|---|---|
| Temu ME April | 48 | 中东 + 月份 |
| Temu-东南亚 | 24 | 地区 |
| Temu日本IG | 17 | 国家 + 平台 |
| Temu-中欧 | 13 | 地区 |
| Temu-美国-USTT | 12 | 国家 + 平台 |
| Temu-科技 | 10 | 品类 |
| Temu-玩具 | 10 | 品类 |
| Temu-IG女装 | 9 | 平台 + 品类 |
| …以及另外 20 多个 Temu 相关 group | ||
| 合计:一个客户 Temu | 216 | 32 个 group · 8+ 个 product |
不是「上游数据脏、我们清洗一下」。而是——那个稳定实体在上游任何一层都不存在。 product 和 group 看起来像分层,实际上是同一种裂变的另外两个副本。 所以这不是同步策略问题,是一个上游根本没有建模的概念,只能由我们建。
上一版我说「19% 的达人同时在 2+ 活动上,跨活动身份冲突是常态」。 但你这个背景一说,我立刻意识到这个数字可能是假的——如果 5 月找不到人 6 月重开一条, 同一个人被重新触达一次,那不是复购,是重投。所以我把它拆开算了。
占多活动达人的 30.7%。同一个客户,不同 campaign 记录,同一个人被再次触达。 这是滥用造成的真实伤害——对达人是骚扰,对我们是重复成本。
占 69.3%。不同客户、不同商业意图,同一个达人。 这是真资产,复购的故事成立——只是今天没有任何实体把它表达出来。
口径:按 group_slug 归一到品牌前缀后统计(455 campaign → 49 brand)。 以 group_slug 原样统计则是 1,144 / 5,809,结论方向一致。
① 复购是真的,4,819 人。上一版关于 creator-as-record 的结论不变。
② 但顺带发现了一个今天没人看得见的问题:2,134 个达人被同一个客户重复触达过。
统一之后,「这个人这个客户已经聊过了」变成一次 SELECT,而今天它需要人去记。
| 是什么 | 变更频率 | 谁拥有 | |
|---|---|---|---|
| Program 合作项目 |
客户 × 产品 × 商业意图。稳定,是「我们和 Temu 在做的事」 | 季度级 | Coordinator 本地,运营维护 |
| Sourcing batch 招募批次 |
一次找人尝试:某月、某国、某平台、放宽条件重试 | 周级,可以随便开 | Java campaign 的只读镜像 |
关键:不要试图去修 Java 那边。 让他们继续随便开 campaign—— 那本来就是招募批次该有的行为。我们只是不再假装它是「合作项目」。
program(id, label, client, product, intent, -- 本地,稳定,~49 条 created_by) -- 运营建,不碰 Java sourcing_batch(id, program_id, -- 多对一映射到 program external_campaign_id, -- Java campaign 的镜像 attempt_no, region, platform, period, synced_at) -- 只读,永不回写 collaboration.program_id ← 稳定的归属。复购、金额、看板都按它汇总 collaboration.sourcing_batch_id ← 来源,只用于追溯「这个人是哪一批找来的」
product 和 campaign_group 几乎是 1:1 (112 product / 87 有 campaign 的 group)。所以归类可以在 product 这一层做,一条 product 带走它下面全部 campaign。 112 行人工归类到 ~49 个 program——半天的活,不是一个项目。
| 动作 | 工作量 | 谁做 |
|---|---|---|
| 存量:112 个 product → ~49 个 program | 112 行 | 运营一次性,可用品牌前缀预填后人工确认 |
| 增量:新同步进来的 campaign | 每条 1 次 | 按 product 自动继承;product 是新的才需要人点一下 |
| 未归类的兜底 | — | 必须允许存在。归到 program = null,不阻塞收信,进待归类队列 |
最后一行很重要:归类不能是入库的前置条件。今天 "Legacy (Scheduler)" 这个占位 product 下面挂着 24 条 campaign, 就是因为上游没给 project 时系统必须编一个出来。新模型里那种情况直接进待归类队列,不用编。
你说得对,而且这正好补上了我上一版指出的那个洞: 8,586 个进行中的交付合作里,4,461 个(52%)一条 deliverable 记录都没有。 原因就是交付物要等合同签署后才播种,而在那之前合作是「无形」的。
创建 collaboration 时立刻建一条 provisional 交付物 (渠道待定、数量 1)。谈判期它显示谈判状态,条款谈成时再按价格条目细化成 N 条。 合作从第一天起就有形、可推进、可被催办。
量级没问题:51,175 条合作 × 至少 1 条 = 5 万多行,今天是 4,740 行。对 Postgres 不算什么。 真正的收益是看板从第一天起就是完整的,而不是等签约后才突然出现。
最后那一行是统一后白送的能力:2,134 个被重复触达的达人, 在按 program 汇总之后自动可见。
数据取自生产库直查(2026-07-25):campaigns / campaign_groups /
products / coordinator_engagements。
品牌归一口径为 group_slug 去尾号 + 去地区/平台/月份后缀,455 → 49。
相关:Research/coordinator-vnext/04-vnext-architecture.md