营销触达频率：把活动与自动化放在一起管理
营销触达频率应从顾客收到的消息看，而不只看每场活动发了几次。活动团队一周只发一封邮件，同一位顾客仍可能同时进入欢迎、浏览提醒、补货和唤回流程，再收到短信促销。
频率管理要回答：同一个人，在明确的时间窗口内，被哪些来源联系了多少次，下一条消息是否仍值得发送？ 本文的方法与例子为编辑建议，不提供适用于所有业务的“安全次数”。
单场排期不等于每人的总压力
内容日历管理制作和发布；触达台账还要纳入持续运行的自动化、临时群发和其他团队的发送。公开社媒发帖不能直接算成每个关注者收到一次；广告曝光也不能与可识别收件人的消息直接合并。
顾客生命周期分层能帮助选择内容，却不自动产生渠道资格。进入补货组，不代表可发短信；频率尚有余额，也不代表退订者可以重新发送。先核对各渠道可联系状态、售后情况与内容相关性，再判断频率。
同一人可能有两个邮箱、一个手机号和多个工具里的档案。台账应使用有依据的稳定顾客键，并保留来源身份映射；不能凭同名合并，也不能因合并档案就扩展渠道同意。身份尚不能连接时，分别列出已匹配与未匹配记录，不能把各平台人数相加后称为去重人数。
先说清楚“次数”指什么
| 事件 | 能回答什么 | 不能直接推断什么 |
|---|---|---|
| 计划进入发送队列 | 原本准备联系多少次 | 不代表已经尝试发送 |
| 尝试发送 | 系统作出了多少次发送尝试 | 可能失败，未必送达 |
| 平台记录为已发送 | 有多少消息进入该平台定义的发送状态 | 不保证进入收件箱或被阅读 |
| 平台记录为已送达 | 有多少消息取得该渠道的送达记录 | 不等于顾客看到、理解或记住 |
| 跳过或取消 | 哪些候选消息被挡住及其原因 | 不算实际发送，也不必然自动补发 |
不同平台的事件含义可能不同，不能只按字段名称合并。建议保留顾客键、消息键、活动或流程、渠道、用途、各事件时间、最终状态与跳过原因。重试保留独立尝试记录，但同一消息的重复状态回传不能增加消息数；若重试实际上产生第二条消息，应如实计入。
Klaviyo 的 Smart Sending 说明按尝试发送启动窗口，之后退信或被下游过滤的消息仍可能计时；在 Klaviyo 内已跳过的消息不启动窗口。这个机制说明“频率限制使用的次数”和“已送达次数”需要分账，不能用送达报表反推全部拦截决定。
自然日和滚动窗口会给出不同结果
自然日按指定时区的午夜切分。前一天 23:50 和次日 00:10 分属两天，却只隔 20 分钟。滚动 24 小时则在每次判断时回看最近 24 小时；还应写清边界，例如使用 (当前时刻 − 24 小时, 当前时刻]。
下表是假设的单人日志，时区为北京时间，A01 是已确认的同一顾客。E、S 是消息键；“—”表示没有发生对应事件。所有消息均来自已纳入的邮件与短信系统，未覆盖其他渠道。
| 候选时刻 | 消息与来源 | 用途 / 渠道 | 尝试 | 已发送 | 已送达或处理结果 |
|---|---|---|---|---|---|
| 10-10 09:00 | E1，周报活动 | 营销 / 邮件 | 是 | 是 | 已送达 |
| 10-10 09:01 | E1，重复入队 | 营销 / 邮件 | — | — | 同一消息去重跳过 |
| 10-10 13:00 | E2，浏览流程 | 营销 / 邮件 | 是 | 是 | 退信，未送达 |
| 10-10 18:00 | S1，促销活动 | 营销 / 短信 | 是 | 是 | 已送达 |
| 10-10 19:00 | E3，订单通知 | 事务 / 邮件 | 是 | 是 | 已送达 |
| 10-11 08:00 | E4，新品活动 | 营销 / 邮件 | — | — | 频率检查跳过 |
假设本例自行约定：每人滚动 24 小时最多 3 条营销消息尝试，邮件另限 2 条；事务通知另计。这只是演算规则，不是推荐阈值，也不表示某平台原生支持。
10-11 08:00 判断 E4 时，窗口内有 E1、E2、S1 共 3 条营销尝试，其中邮件 2 条，所以跳过。营销已送达只有 E1、S1 共 2 条；事务 E3 另列 1 条。重复入队的 E1 不再计一次。若只看 10-11 当日已发数，就会得到 0，忽略此前 23 小时的叠加。
渠道限制不自动成为跨渠道限制
截至核验日，Klaviyo 的官方说明明确邮件、短信与推送使用各自的 Smart Sending 窗口，邮件不会阻止短信，反之亦然。被该功能跳过的消息不会自动改期重发。因此打开各渠道的限制，不等于已经设置每人跨渠道总上限。
如果多个工具都能发送，需要核对它们能否及时共享计数及待发记录。不能共享时，可先通过互斥名单和统一排期减少冲突，并把“缺少实时跨系统拦截”写进检查结果，不能承诺绝不会超限。
并发也会制造漏洞：两条消息同时查到“还剩一次”，可能都被放行。运营验收要覆盖同时入队、延时执行和失败重试；需要技术支持时，确认系统能否在放行时占用名额，并在实际出队前重检，而不只是各自读一次旧计数。
冲突时决定舍弃什么，而不只是往后推
先排除不具备发送资格的人，再按当下需求排序。必要的履约通知、已承诺的服务回复、品类使用帮助与一般促销应有明确用途；营销内部再按相关性、时效与业务优先级选择。高价值顾客不是自动豁免理由。
跳过表示这次不发；延后表示保留候选，未来重新评估。延后必须有最晚发送时间、重新核对的资格和购买状态，以及再次碰到限制时的处理。优惠到期、顾客已经购买或消息失去上下文，就应取消，不能让积压消息在窗口释放后一起涌出。
事务类豁免需要核对内容和平台规则。Klaviyo 的事务邮件要求按具体邮件审核，并要求不含营销内容。不能把促销改名为“订单提醒”来绕过限制；必要通知即使不占营销额度，也要另记数量，避免把顾客实际收到的服务消息完全隐去。
用分布和负面反馈调整规则
平均每人两条，可能是多数人零条、少数人十几条。按固定观察人群报告 0 条、1—2 条、3—5 条、更多条的分布，并查看高频人群、最短间隔、来源组合与跳过原因；分段本身也是分析选择，应保持可比。
退订和投诉同时列出数量、分母、渠道、归属消息和观察截止时间。Klaviyo Reporting API的垃圾邮件投诉率使用收到邮件的事件作分母，而退订字段有其邮件与短信计数口径；不能拿一个渠道的负面事件除以另一个渠道的发送量，也不能混用人数和消息次数。
触达窗口与反馈观察窗口分开记录：最近 24 小时的频率，不等于发送后 7 天的退订结果。比较时让反馈有同样的成熟时间；还要检查内容、促销、投递质量和人群变化。高频与退订同时上升是调查线索，不能仅凭前后变化认定频率造成退订。落地检查见检查并调整营销触达压力。