作者：闲鱼技术-骆彬
在Omega实时触达系统的系列技术文章中，已经对行为采集中心、CEP规则中心、用户触达中心三个子系统进行了详细介绍。Omega实时触达系统的核心能力是基于用户行为实时推送给用户感兴趣的内容，但是频繁的触达对用户体验是巨大的伤害，因此，对于一个实时触达系统，如何做到对用户友好的触达，是一个十分关键的问题。
常见的优化方式有触达素材的择优和疲劳机制的控制，本文会主要介绍在用户触达疲劳控制方面，我们是如何设计灵活精细的疲劳控制策略去处理在触达过程中对用户造成打扰的问题。
实践中遇到问题
在用户触达中心的设计上，我们采用了灵活的可插拔设计，每个业务可以根据自己的需求配置不同的过滤器组合，但接入的业务都必须配置疲劳控制策略来避免对用户的打扰。在接入早期疲劳控制能力的业务中，我们发现某些用户会在相邻两天收到相同的触达内容；在一个周期允许触达多次的场景中，某些用户的触达时间比较集中。这些问题会对用户造成一定的打扰，会影响到用户的使用体验，可能导致用户屏蔽通知甚至是卸载app。
metaq：是阿里内部使用的MQ框架；
hermes：为Omega提供素材管理与择优的能力；
定位问题的原因
在疲劳机制1.0版本的设计中，我们使用了疲劳窗口的概念，疲劳窗口的时长即为疲劳周期，每个业务拥有各自的疲劳周期。如下图所示，由于疲劳周期的划分起点是相同的常量，因此，每个时间点都可以根据业务的疲劳周期换算出对应的疲劳窗口，进而实现对业务疲劳的控制。
出现相邻两天收到相同触达内容的原因是因为在疲劳机制的设计上，疲劳周期一旦确定，每个疲劳窗口就随之固定下来，两个疲劳窗口是紧邻的，分属两个疲劳周期的触达就可能先后两天成功触达；另外，在动态调整疲劳周期时，原有的疲劳数据会瞬时全部失效，这也会导致用户短时间内收到相同的触达内容；而在一个周期允许触达多次的场景中，存在触达可能比较集中的问题，是因为用户在某段时间的操作多次触发了业务规则，而疲劳机制中没有对触达间隔进行限制，最终会出现某些用户的触达时间比较集中的问题。
新疲劳机制的设计
在通用的用户疲劳度设计中，大多会根据系统承载业务的特点，进行分层处理多维度控制，以满足不同场景的需求。比如，某些营销投放系统，其对应的是投放展位，它将疲劳控制分为：展位、方案、单元三层进行控制。其中，一个展位可以投放多个营销方案，而一个营销方案则包含多个投放广告，营销投放系统更关注的是展位的疲劳控制，业务方关注的则是营销方案的疲劳控制，分层控制有利于多方疲劳控制的协调处理。
在疲劳机制2.0的设计中，我们参考了这种设计理念，对于实时触达系统的核心是用户在哪些场景下触达哪些业务。其中实时触达系统更侧重于用户和场景的控制，因此根据不同的控制维度划分出了三个疲劳控制维度：
• 用户维度：用户每日可接收触达的总次数，默认必须校验；
• 场景维度：每个场景可触达的次数，用于不同场景域的控制；
• 业务维度：每个业务自己的疲劳频次，提供n天m次最小触达间隔t秒的能力；
对于相邻两天触达相同内容的问题，我们的解决方案是不在使用固定的疲劳窗口起始点，每个疲劳窗口的起点是其在用户未疲劳的情况下的首次触达时间，即在第一次触达后的一个周期内不允许再次触达。
另外，查询疲劳的key也改为由用户和业务决定，而非疲劳周期决定，这样设计的优点在于动态切换疲劳周期时，不会影响到已经疲劳的用户，已疲劳的用户会在下次疲劳时使用新的疲劳周期。
对于一个周期多次触达场景中出现的触发比较集中的问题，我们采用了最小触达时间间隔的概念，在疲劳检验时同时校验与上次触发的时间间隔，两次触达时间差小于最小触达时间间隔的校验不通过。
通过灵活的疲劳窗口起始时间、多维度管理以及最小触达时间间隔的控制，从控制机制上解决了疲劳机制1.0中出现的问题。另外，为了验证疲劳机制2.0的实际效果，也为了给业务优化提供基础数据，我们将用户的触达记录接入到了数据统计模块，通过对日志清洗、解析，产出了业务的数据漏斗和报表。
应用效果
在经过多个业务场景接入疲劳机制2.0的设计后，通过分析触达日志和数据报表，我们拿到如下结论：
- 接入业务没有再出现相邻两天收到相同触达内容的情况；
- 业务疲劳周期动态变更时，未出现短时间触达相同内容的情况；
- 一个周期允许多次触达的接入业务，用户触达记录分布更加离散；
目前，疲劳机制2.0累计接入的业务已有三十多个，qps峰值在6000左右，运行状态稳定。
后续计划
由于疲劳机制2.0的通用性和配置的灵活性，已经有其他业务在使用2.0版的疲劳服务，后续考虑将该疲劳服务优化后作为对立组件输出到其他业务；另外，提供将疲劳等过滤节点的数据回流到算法的能力，帮助接入业务优化触达策略。
