用户运营 · 每日干货 · 2026.10.27 · VOL.007

全局对照组:先留一批「不发营销」的人,才说得清触达的增量

Braze 和 CleverTap 都能在全账户留出一个长期不收营销消息的对照组,服务类消息靠标签或单条开关放行;Flo 按「实验名 + 用户 ID」哈希分组,并单独看推送送达率,把「没送到」和「送到了没效果」分开。

今日四件事 · 读完可合上
  1. 今日一招建全局对照组(Global Control Group),服务类消息按标签放行
  2. 标杆与竞品Flo:每个实验按「实验名 + 用户 ID」做 md5 哈希分组,并单独盯推送的 fill rate。
  3. 对照我的规划今天把「是否支持账户级对照组、能否按标签放行服务类消息、对照组名单能否导出」三项加进 Braze / Klaviyo / Customer.io 的选型对比表。
  4. 自测一题如果明年要向 CEO 说清「生命周期触达让 M5 smart 用户的 90 天留存提高了多少」,你们现在拿哪批人作对照?
01
Today's move · 今日一招

建全局对照组(Global Control Group),服务类消息按标签放行

全局对照组是从全部用户里随机留出的一小批人,长期不收营销 Campaign / Canvas。拿他们和收到消息的人比留存、复购,得到的才是触达带来的真实增量,而不是把「本来就会回来的人」也算成功劳。

具体做法:

  1. 定比例:Braze 可设 1–15% 的整数,官方建议对照组不少于 1,000 人;CleverTap 的 System Control Group 每个账户只有一个,比例 2–5%,新用户按同比例自动分入。
  2. 先放行服务类:Braze 在排除设置里按标签放行,打了该标签的 Campaign / Canvas 对照组照样收到;CleverTap 要在单条活动里移除 System Control Group,官方建议只对交易类消息这么做,并提醒会影响报表。
  3. 注意通道例外:Braze 的 API Campaign 不受对照组约束,但 API 触发的 Content Card 仍受约束。
  4. 定周期:Braze 建议先观察 1–3 个月,重抽最多约每月一次;重抽或关闭前先导出名单 CSV,关闭后旧名单无法找回。
  5. 看指标:用报告里的 Incremental Uplift 和 Change from Control,盯留存、复购等核心事件,不只看打开率。
在我们这边App 子域名发的服务类消息统一打一个服务类标签放行,只让旅程和营销消息受对照组约束,避免把该收的服务通知也拦掉。

需要核实:候选工具里 Klaviyo、Customer.io 是否有同等的账户级对照组和按标签排除能力。

02
Peers & rivals · 标杆与竞品

标杆与竞品

Flo:每个实验按「实验名 + 用户 ID」做 md5 哈希分组,并单独盯推送的 fill rate。 Flo 工程团队公开的流程是:PM 和分析师先定假设、受众和指标,分析师算样本量和时长,开发再配动态开关;哈希结果换算成百分比,同一用户在同一实验里始终落在同一组。他们还建议看 fill rate,比如推送「发出 vs 实际展示」,确认消息真的到了用户手里。

同类做法对照Braze 的全局对照组按每个用户固定的随机桶号划分,官方提醒其他实验如果也按随机桶号圈人,可能和对照组重叠;Flo 按实验名各自哈希,不同实验的分组互不牵连。Flo 还明确不用第三方实验工具,理由是用户隐私和原始数据可控。
对我们的启发M5 smart 旅程的实验报表里把送达率单独列一行,效果差时先查是不是没送到(推送关闭、邮件退信),再判断文案和时机。
03
Against my plan · 对照我的规划

对照我的规划

对应四大基建里的「策略与实验」,也是推送 / 排程工具选型的一道必问题。今天把「是否支持账户级对照组、能否按标签放行服务类消息、对照组名单能否导出」三项加进 Braze / Klaviyo / Customer.io 的选型对比表。

04
Self-check · 自测一题

自测一题

如果明年要向 CEO 说清「生命周期触达让 M5 smart 用户的 90 天留存提高了多少」,你们现在拿哪批人作对照?这批人过去 3 个月里收到过营销消息吗?