01
Today's move · 今日一招
建全局对照组(Global Control Group),服务类消息按标签放行
全局对照组是从全部用户里随机留出的一小批人,长期不收营销 Campaign / Canvas。拿他们和收到消息的人比留存、复购,得到的才是触达带来的真实增量,而不是把「本来就会回来的人」也算成功劳。
具体做法:
- 定比例:Braze 可设 1–15% 的整数,官方建议对照组不少于 1,000 人;CleverTap 的 System Control Group 每个账户只有一个,比例 2–5%,新用户按同比例自动分入。
- 先放行服务类:Braze 在排除设置里按标签放行,打了该标签的 Campaign / Canvas 对照组照样收到;CleverTap 要在单条活动里移除 System Control Group,官方建议只对交易类消息这么做,并提醒会影响报表。
- 注意通道例外:Braze 的 API Campaign 不受对照组约束,但 API 触发的 Content Card 仍受约束。
- 定周期:Braze 建议先观察 1–3 个月,重抽最多约每月一次;重抽或关闭前先导出名单 CSV,关闭后旧名单无法找回。
- 看指标:用报告里的 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 个月里收到过营销消息吗?