近日，在极客邦科技举办的 QCon 北京 2019 上，美团点评高级技术专家张杰为大家分享了技术如何助力美团点评实现用户增长的经验。
1
- 提 纲
- 用户增长的背景和目标
- 大众点评全链路激励系统
- 激励系统重心：用户行为和用户任务系统
- 激励系统的高可用实践
2
用户增长的背景和目标
Nike 创始人 Phil Knight 曾经说过：“If you are not growing ， then you are dying”（不再增长，就在死亡），企业增长是一个永恒的话题。在互联网红利消退的今天，单纯依靠制造一款产品，然后反复营销来驱动的商业模式已经失去市场，而以数据指引方向，实验驱动运营的“增长黑客式”模式显示出其强劲的实力；
企业的用户增长策略在不同时期会聚焦在 AARRR 模型的不同阶段，发力用户留存 (Rentention) 对于大众点评尤为重要。建立用户成长激励体系是提升留存的重要抓手。
所谓用户成长激励体系，就是平台通过激励的方式让用户在产品使用过程中的不同阶段达到不同的状态。行前的时候引导用户去看点评、看攻略，形成决策；行中的时候去排队点菜买单；行后的时候去写点评帮助更多人。
建立这个成长体系很有意义：首先它影响了用户获取成本和平台的收入，这里的收入不仅仅指现金的收入，对于大众点评而言，用户贡献的点评、攻略等内容也是宝贵的收入。用户成长激励体系将用户由大众点评的轻度使用者渐渐引导为深度使用者和内容贡献者，逐渐摊平初期公司在拉新时的成本，从而提升平台收入。其次用户成长激励体系鼓励用户做分享和传播，公司组建了非常优秀的本地化运营团队在重点城市运营 VIP 用户，这些 VIP 用户在本地的传播和扩散作用非常明显，带动了更多人来使用大众点评，贡献优质内容。
技术上如何助力用户增长、搭建成长激励体系呢？我们打造了一套全面覆盖大众点评 APP 用户场景的技术系统。
3
全链路激励系统
- 全链路激励系统的搭建，需要满足成长激励理论中的三个诉求：建模型、搭通道、促成长：
- 建模型指系统要搭建数据模型指导决策，比如平台要搭建用户生命周期模型、用户漏斗模型、用户价值模型等等；
- 搭通道指系统要搭建用户成长和用户触达的通道，比如关键页面的红点和弹窗；
- 促成长指系统要能承载多种维度的运营策略，推动用户向其高生命周期阶段演进。
全链路激励系统一站式解决了四个视角的痛点：第一个是用户视角，用户可以顺畅的在点评 APP 内领取任务，取得激励；第二个是开发视角，开发不需要自己管理任务的生命周期，只需要实现系统的几个扩展点就可以进行任务绑定、任务推荐、任务读取进度和任务状态更新；第三个是运营视角，运营在系统后台可以做可视化运营，动态圈选目标用户，实时查看用户完成的任务量和任务进度；最后一个是平台管理员视角，系统采用多租户模式管理租户，为不同的租户设置子系统权限。
系统采用广义分层的架构实现，在业务服务域主要提供全链路激励的解决方案，这一层以任务引擎为核心，结合算法模型组织业务。整个解决方案会调用多种领域服务，如触达服务、投放服务等，每个领域服务开放自己的一套高内聚的服务接口；从数据流转的角度看系统，数据在业务服务域和领域服务域中流转，通过离线、实时、近实时等方式反馈算法模型、生成数据报表。
这套全链路激励系统涉及多个核心子系统：用户行为系统、投放系统、任务系统和奖励系统。我们这里重点介绍下用户行为系统和任务系统。
用户行为系统
用户行为的定义
4W1H 定义用户行为：是谁（WHO）、在哪里里（WHERE）、是什么（WHAT）、什么时间（WHEN）、行为的属性（HOW）。我们的用户行为系统，不仅包括用户标准行为（用户在产品上的操作记录），还包括了用户的非标准行为，比如“用户在首页停留 5 秒”、“浏览了某个特定的业务元素”等极具业务定制的行为或者任何标准或者非标准行为的自由组合。
用户行为接入
分三步走，第一步是流量上报，集团通过统一打点框架，将通用行为按策略打点上报，对于实时性要求高的行为或者定制化的业务行为，我们采用做轻行为日志上报的方式，单独为其开放 MAPI 接口进行上报；第二步将流入的行为数据在 storm 集群中做一层粗分捡，并将分捡好之后的数据会按照业务维度分发给消息集群。
用户全量的行为数量巨大，处理和存储全量用户行为显然性价比较低，于是我们在流量网关中只拦截系统关注的核心行为。与此同时系统还对标准的用户行为做了扩展，比如集团打点上报了一个浏览商户行为，而全链路激励系统需要“VIP 用户浏览美食商户行为”、“用户浏览五星商户行为”。为了实现如上需求，系统通过在流量网关中设置监听器，动态插入规则表达式的方式实现；行为数据紧接着按照策略分发到不同 Topic 的消息集群中，比如将数量最大的浏览行为单独分配 Topic，重要的写点评行为单独分配 Topic。第三步数据流入 UAS-Core 做精细处理和数据持久化。
业务行为扩展
分捡好之后的用户行为数据会在 UAS-Core 里做进一步业务处理。比如针对用户纬度会做噪音过滤、业务转换、数据统计和幂等控制。以噪音过滤为例，噪音过滤算法识别出来很多爬虫流量，它会被当做噪音过滤掉，就不占用存储资源了；之后系统把用户产生的行为从存储里捞出来，按照时间线排序，再压缩放进去。最后再经过一层业务扩展层，业务把逻辑作为插件拆入到 Server container 中实现。
行为数据存储
系统采用离线和实时融合的方式进行数据存储。比如业务需要提供一位用户 30 天内的浏览行为数据，实时数据存 5 天，离线数据以 28 天的时间窗口不停滚动，通过大数据作业的方式存在 Hive 里面。接口调用时做实时融合，给业务方使用。
整体设计
用户任务引擎
用户行为搭建完成之后，就给整个全链路激励的核心系统：任务系统打造了良好的基础。用户任务引擎不仅仅指用户显式领取的任务处理，还包括如用户等级升级之类的隐式任务的生命周期管理。
IFTTT 式的任务模式
下图左侧是一个极简模型：数据分析结果显示我们的某些目标用户缺少标签数据，需要用完善个人资料的方法填补这个空白，于是系统会推送“完善个人资料任务”任务给用户。当用户在个人资料页填写完几个关键信息之后，系统判定任务完成，并且发放给用户 30 积分。整个任务的流转过程本质使用的是 IFTTT 思想。IFTTT 是”if this then that“的简称，本意是想把互联网上的所有应用链接起来，我们的全链路激励系统里借鉴了这个思想，希望把用户行为链接起来，比如说”if 用户写了一条点评”，”then 该用户贡献值增加，并且得到一张一百元的代金券“。
丰富的子任务管理
系统不仅能组织简单模型，更擅长于处理复杂的子任务模型。任务是由子任务组成的，从任务逻辑视角来看，任务是树型结构，父节点的任务含义要包括子节点的任务含义，当子结点任务完成时父节点的任务也要被标记完成；从运营视角来看，每个任务是各自的组里的，分组采用专家规则方式由运营手动干预，不同的分组会影响如推荐、投放等模块。
最后从子任务关系的视角来说，一个任务可以由多个子任务组成，如图所示，用户在并联的完成”写一条点评“、”上传视频“、”签到“任意一个任务之后，再按照顺序串联的完成”浏览 3 条点评头条“，”浏览好友动态，”拉 10 位好友到 517 吃货节活动“之后，才算完成整个任务；用户完成一个复杂的任务成本是比较高的，于是任务引擎支持分步发奖，通过读取运营人员配置的”step“信息，在完成几个子任务后用户即可收到小奖励，最终完成整个任务时收到通关大奖。在工程实践上面我们重写了一个 Google 的表达式引擎去做实现子任务管理。
多用户维度融合
灵活的任务模型和子任务管理解决了任务维度的复杂性，而用户维度的复杂性仍然是一大难题。用户按照使用大众点评的终端分为 PC 端用户、小程序端用和 APP 端用户；用户按照登录态分为登录用户和非登录用户；用户如果持有多个设备，我们还要区分是不是老用户换机或者其他场景。
用户在 PC 端开始了一个任务，在 APP 上完成了剩下的任务怎么算？激励该发放给谁？用户在登录状态下和非登录状态下的任务如何统计？这些都需要全链路激励系统在用户维度上做不小的工作。我们通过”多用户纬度融合策略“解决这些问题。例如一位用户在未登录状态下领取了任务，并且做了一部分子任务，之后该用户登录了。
这时候系统会识别出该用户为目标用户，触发以设备纬度向用户纬度融合的策略：用户登录的时刻，产生融合点，平台首先用算法猜一下这个是不是它的主设备？发现是主设备的时候会做画像融合，将用户画像和设备画像融合；用户在登陆情况下做了一些行为，平台会把他设备上做的行为和用户纬度做的行为都捞出来按照时序重排，并且把这些行为做事件重放，重新刷新任务的状态机；如果这个时候用户的任务要完成了，那就再次猜一下这个设备是不是主设备，判定是不是要发一张大额的奖励；如果是主设备并且符合风控要求，发放大额奖励，如果发现不是主设备会给他发一个兜底奖励，并且会对这张奖励做染色，方便风控团队在将来他使用这张券的时候会做风控处理。
智能仲裁解决任务冲突
最后，在解决了复杂任务模型和复杂用户维度之后，全链路激励系统又面临一个由于任务数量激增遇到的现实问题。大家都知道普鲁托原则，又叫 20/80 原则。大众点评 80% 的任务引导是承接在 20% 关键页面上的，这时就会出现很多冲突的场景。那系统是如何解决用户任务当中的任务冲突呢？我们引入了智能仲裁解决方案。我们首先了解一下仲裁场景，也就是在什么情况下需要仲裁：
同一页面场景同一模块的不同业务仲裁。比如对于商户页的写点评模块，点评平台想引导这个用户写点评要发放”宝箱“，垂直业务想要引导用户写带图点评，发放 200 积分，这时候就产生冲突了。
同一页面场景多用户行为仲裁。商户页一次性出十几个引导，既要引导用户收藏、又要引导用户去预订，很多弹窗和气泡弹出，这种用户体验是绝对不允许的，也是仲裁的场景。
多页面场景同一用户行为仲裁。比如我们可以在首页加号处引导用户写点评，在商户页也有写点评的引导，同一个用户行为引导了多次并发放多个奖励，显然性价比不高。
其次我们了解一下仲裁点，也就是仲裁的时机：对于同一时刻发生的用户标准我们才进行仲裁操作。最后在技术上是如何实现仲裁的：
基于专家规则：对于业务的配额或者临时要举办的活动，采用专家规则的方式进行配置，在特定时间段内生效，常见的方式如配置优先级、互斥分组等。
基于算法：对于非规则类的行为，实时用算法干预是技术实现的正确方向。算法的选用要符合当前的业务目标，比如我们的目标是要任务点击的 UVCTR 最高，还是以行为产生的用户价值量最大为目标。
4
激励系统的高可用实践
最后，全链路激励系统覆盖了大众点评的大量用户场景，可用性要求很高。我们在系统搭建的过程中做了很多的工作。
系统高可用方面：主要依赖公司提供的中间件和熔断降级措施，集群 QPS 过高之后的弹性扩容；RPC 中间件的智能负载均衡；降级组件的熔断策略、多机房切换等。
业务高可用方面：我们做的最重要的抽象就是任务分级：如写点评等写操作我们认为很重要，并且用户重做的成本非常高，就把其设定为高级别的任务；如浏览信息等用户重做成本低的任务，就把其设定为低级别的任务；平台识别出来任务分级之后，在故障感知时会实时监控它的发放量、历史同期的完成量、以及业务库存。在故障处理时对低级别的任务先降级甚至丢弃，对高级别的故障做额外的回补和处理。
5
写在最后的话
用户成长其实和增长一样是一个比较大的概念。我们不仅在线上有完善的全链路激励系统，在线下我们也做了很多事情：本地化运营团队在线下运营社群活动，每年举办 VIP 年终盛典，大家一起评选达人，欢度节日；公司和会员共同发起公益计划，帮助边远山区的孩子生活的更好。用户在成长的同时我们也在一同成长。
作者：张杰，文章来源： InfoQ（公众号）
本文由用户@慕斯姑娘发布于新媒体运营，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
