企业微信营销系统怎么设计

分界线：最小单位是一次发送，还是一个活动

企业微信营销工具的最小单位是一次发送：选名单、选内容、点发送，结束。企业微信营销系统的最小单位是一个活动，它有名字、有负责人、有目标、有分到的打扰额度、有生命周期，也有复盘。这个差别听着像术语之争，但它决定了几个基础问题能不能被回答。

• 这个人为什么会收到这条消息？工具答不了，因为名单是一份已经丢掉来源的快照；系统能答，因为受众是一个可重放的定义。
• 这周他一共被打扰了几次？工具答不了，因为它不知道别的发送存在。
• 这次的效果怎么算？工具只能按时间窗猜，系统在发出的那一刻就写下了归因。
• 出事了怎么停？工具只能停整个队列，系统能停一个活动，其余照常。

三种常见的「看起来是系统、其实是工具」：界面很完整但每次活动都要重新导名单；有自动化流程但流程之间互不可见；有数据看板但看板口径和执行口径对不上。这三种都能靠加功能缓解，缓解不掉，因为缺的不是功能，是那个对象。

受众是一个可重放的定义，不是一份名单

把名单从「传进来的一个数组」改成「一段可以重新执行的查询」，是从工具到系统最实的一步。可重放带来三件工具做不到的事：随时能解释某个人为什么入选、活动跑到一半能重新求值拿到增量、复盘时能拿到当时的口径而不是今天的口径。

受众定义里最该被认真对待的不是选择条件，是排除条件。选择决定活动的上限，排除决定它会不会伤人，而后者在多数系统里根本没有独立位置，全靠运营在导名单时手工筛。

• 最近 N 天被同类内容触达过的：排除掉，否则高价值人群会被所有活动反复选中，因为他们在每张名单里都排前面。
• 已经完成本次活动目标的：转化了还在收催单，是最直接的负面体验，也是最容易避免的一种。
• 显式退订、投诉过、处于静默期的：硬排除，不接受任何活动覆盖，也不给「本次特殊情况」开口子。
• 一线标记为敏感的客户：给销售一个能把人从自动触达里摘出来的入口，成本极低，能挡掉大部分部门冲突。

求值时机要显式声明：提交时求值一次（名单冻结，适合有审核流程的活动）还是执行时逐批求值（名单跟着变化走，适合长周期流程）。两种都对，但必须写在活动定义里，而不是由实现顺手决定。求值结果存成快照并带上 ID，发出的每条消息带着它；后续用 wecomapi 的事件回调收到响应或关系变更时，就能直接关回是哪一版受众。

冲突检测要做在提交时，不是发送时

两个活动同时想找同一批人，这件事在发送时才发现就已经晚了 —— 那时能做的只有让一条排队或丢掉，而运营完全不知道自己的活动被谁挤了，只看到数据比预期少了一半。

可行的做法是把冲突检测前移到活动提交那一刻：新活动提交时，拿它的受众定义和已排期的活动做一次重叠度估算，重叠超过阈值就要求提交人选择处理方式 —— 改时间、改受众，还是接受降级（重叠部分只发优先级高的那条）。这一步只需要估算，不需要精确，目的是让冲突在人还有余地的时候暴露出来。

• 营销日历要是一张真表，不是共享文档。排期冲突得能被程序查询，才谈得上自动检测。
• 优先级定在活动上，不定在单条消息上。同一活动内的消息共享优先级，只有跨活动才需要比较。
• 被挤掉要记账，而且要通知提交人。悄无声息地丢弃是运营不再信任这套系统的起点，之后他们会绕过系统自己发。

归因要在发出的那一刻写下

事后靠时间窗关联转化，是营销系统里最常见的自欺。同一个人这周被三个活动碰过，转化算给谁取决于你用了几天的归因窗口，而这个参数换一个值结论就翻过来 —— 更糟的是，换参数这件事通常发生在结论不好看的时候。

唯一稳的做法是发送时就把归因写死：活动 ID、受众快照 ID、内容资产 ID 加版本、渠道、发送时刻。这五项跟着执行记录一起落库，后续所有响应事件都关到这条记录上。做完这一步，即使还全靠手工提交活动，复盘也已经站得住了。

const exec = {
  execId:     "ex_20260816_88f1",     // 同时作为幂等键
  activityId: "act_autumn_reactivate",
  audienceAt: "aud_v12",              // 受众快照版本
  contentId:  "cnt_1042@v3",          // 内容资产 + 版本
  sentAt:     null,
};

// 出口调用（示意，精确字段与端点以线上接口文档为准）
await post("https://manager.wecomapi.com/message/sendText", {
  guid:    account.guid,
  toId:    customer.toId,
  content: rendered,
});

// 归因字段只写进 exec，不进消息正文

归因信息不要塞进消息内容里。往文案后面挂一串追踪参数会污染阅读体验，而且客户转发时会一起带出去。正确的位置是自有库里的执行记录：调用 wecomapi 的发送接口时用执行记录 ID 作幂等键，响应和事件回来时按同一个键回写，一条链路从头到尾只有一个标识，排查时也不用在三张表之间对时间。

该盯的指标不是打开率

打开率、回复率这类指标有个共同的毛病：可以靠提高频次刷上去。一套企微营销系统如果拿它们当北极星，它会一路优化到把客户发跑为止，而在流失显现出来之前，所有报表都是绿的。

两个更难被刷的指标：单位打扰的产出（周期内的转化价值除以总触达条数），以及关系存量的净变化（净新增好友、净入群、净退订）。前者在加频次的当天就会变差，后者是这套系统真正的资产负债表。它们的共同点是分母会随着乱发而变大，所以刷不动。

• 单位打扰产出要按活动和按内容位分别看。总数只能告诉你在变好还是变差，分维度才知道该砍掉哪个。
• 关系存量看净值和趋势，不看单日绝对数。单日数噪声太大，容易引发过度反应。
• 给这两个指标设的是下限告警，不是上限。它们跌破线时的正确动作是停投放，而不是换一批文案再试一轮。

还有一个容易被忽略的口径问题：单位打扰产出的分母必须包含所有出口，包括销售在系统外手工发的那部分。分母漏记会让这个数虚高，而虚高的方向恰好是鼓励继续加量。两边口径对不齐的时候，先修分母，再看结论。

打开率仍然有用，只是位置不对：它是内容 A/B 的裁判，不是系统级目标。放在活动内部比两条文案，它很准；放到看板顶上当北极星，它会带着整个团队往错的方向走半年。

建设顺序：编排器放在末尾

最常见的错法是一上来就上流程编排器。在没有活动对象、没有受众定义的时候上编排器，得到的是一堆无名发送加了分支 —— 分支越多，越没人说得清哪条流程正在给谁发什么，最后只能整个关掉重来。

1. 1活动对象：名字、负责人、时间窗、优先级、状态。一张表就够，但必须先有，后面所有东西都挂在它上面。
2. 2受众定义：可重放的查询加排除条件，结果存快照。
3. 3归因字段：把活动、受众版本、内容版本写进每一条执行记录。做完这三步，即使全靠手工提交，也已经是一套能复盘的系统了。
4. 4冲突检测与营销日历：活动数量上到两位数之后再做，早做没必要，也校准不出合适的阈值。
5. 5流程编排放在末尾。这时候它编排的是有名字、有归因、有额度的动作，才谈得上价值。

至于是自研还是买一个企业微信营销平台，判断标准就一条：活动对象、受众定义、归因记录这三样能不能留在你自己的库里。能留住，上层用什么工具都可以换；留不住，三年后换供应商时，你的历史数据一起走。