导语：在上一篇数据中台的实战文章《数据中台：从0到1打造一个离线推荐系统》中，作者为我们讲了如何打造一个支撑N条产品线的标签平台，这篇文章，作者分享了如何从0到1打造一套可以实时计算的标签引擎。
最近公司开了个新的产品线叫：圆猿买手，大家都知道我公司搭了一个B2B的女装批发平台，主要服务的是全国做服装批发生意的采购商、供应商。圆猿买手这个产品是从B2B平台独立出来专门服务二批采购商的产品。
什么是二批采购商？简单来说就是大客户，他们一般在二级的服装批发市场如郑州银基等有自己的档口，主要去一级的批发市场（一级的批发市场如广州十三行、杭州四季清等）拿货，拿完货后销售给自己的所在城市的终端门店或者三批采购商。
作为二批采购商，他们每次拿货（采购）的量都是非常大的，因为是我们的大客户，所以我司配备专门的买手给二批采购商提供一对一的推款、找款、发货的服务。
买手是活跃在批发市场的一类角色，他们的核心竞争力就是对市场的档口、档口的新款、爆款比较熟悉，而且他们是常驻在批发市场的，这样二批采购商拿货就不用每次都长途跑到一批市场，只用和我们的买手沟通，就能拿到市场的新款、爆款。
为什么圆猿买手这个业务能够存在？
我觉得有2点原因：
1）由于买手的存在，大大降低了采购商的交易成本
交易成本就是买卖双方所付出的时间和金钱成本，交易类产品是否能够存在，都可以用这个交易成本这个理论来衡量，交易成本理论是诺贝尔奖获得者科斯老爷子很多年前提出来的。
二批采购商一般都在二三线城市的批发市场，每次跑到如广州十三行这种一级批发市场，来回都要很多的时间，路费也是一笔不少的钱，有了买手的存在大大节省了他们的时间和钱。
2）买手的存在让人货匹配更加精准
这里的人是指二批采购商，货是指一级批发市场的商品。电商产品的创新很重要的一点就是提高人货匹配的效率，我提供的商品刚好是你需要的，这样买卖双方付出的时间成本最低。
一个经验丰富的服装买手对市场中的档口和档口的新款、爆款都是非常熟悉的，而且由于买手长期和采购商沟通，这样他会非常清楚当前服务的这个采购商的偏好，这种情况下买手推的商品会更能命中二批采购商的口味。
由于买手的存在，交易模式从二批采购商到市场去找商品，到买手精准的推给采购商大致符合他口味的商品，采购商从买手推的商品中挑一个商品就好了，这种模式好像搭建了一个人肉的推荐系统。
一、产品方案
这篇文章我们讲的主题是实时标签，什么是实时标签？
比如一个用户新注册、首单、复购、复购金额达到1000/3000/5000…..立即给用户发不同的优惠券，从而刺激用户首单及再次复购。有的同学会说，这还不简单，用户每次下单时计算当前用户的指标，然后再触发发券不就行了嘛。
当然如果你的产品运营策略只有如新注册、首单后给用户发券这两种简单的策略而且不会发生变动，这种简单的策略我们通过前端应用计算当前用户的标签，然后调用优惠券的接口给用户发券就行了。
但当你面对几十种不同的策略，未来可能是几百种发券测试时，而且这个策略可能会随时调整，难道你的业务逻辑还要写在应用端吗？
当时我们的策略有这么N多种：新注册、首单、复购、复购金额满XX元、当月支付金额满XX元、沉默召回（距离上一次支付时间超过XX天的用户）、以老带新（成功推荐一个新用户注册，并且新用户完成了首单支付）…
每新增一个策略你就需要改代码，重新测试、发布，这样是非常痛苦的。
当时我们团队看到运营拿过来的几十种发券策略，一开始也比较懵，但经过分析后，我们定了3个目标:
- 这个实时发券的功能，一定要独立出来，不能影响应用端的主业务流程；
- 要能够做到实时发券，如果用户达到某个策略（比如新注册、首单等），隔天再去发券，这样体验很不好；
- 简单的策略要可以实现配置化，比如复购金额满XX元，这个完全要在界面可以配置出来，新增一种类似的策略不用修改代码，就可以完成策略的上线。
产品功能层面是通过现有的标签平台（可以看之前的文章：数据中台实战（八）：如何打造可以支撑N条产品线的标签平台）完成人群的初始化。
比如新注册、已首单用户，增加一种标签的类型叫实时标签，通过监控用户的注册、支付等行为，实时的检查用户现有的标签，实时的计算这个行为该打上那个标签、该撕掉那个标签，然后通过消息队列的方式通知营销系统，完成用户新增标签的优惠券发放。
二、技术方案
下图就是实时标签的技术实现方案，要想看懂这个方案，可以先温习一下之前写的一篇标签平台的文章（数据中台实战（八）：如何打造可以支撑N条产品线的标签平台）：
首先是离线标签处理的流程：
- 群组的数据，比如已首单用户这个用户群下都有哪些人打上了这个标签；
- 标签规则数据，已首单的规则就是 用户支付次数这个指标=1；
- 用户的数据，这里存放的是用户宽表中的各种指标，比如用户的基础信息、当前的支付次数、支付金额等等。
接下来是实时打标签的处理过程：
- 首先是通过CDC (捕获数据变化)工具如Debezium监控数据库库表的变化情况；
- 通过如Debezium等工具告知kafka数据库的变化情况；
- 筛选对打标签有用的事件如注册、支付等事件；
- 读取给用户打标签的规则（如首单的规则是判断用户当前的支付次数是否等于1）；
- 实时打标签的过程，比如用户由未首单打上已首单的标签：可以缓存用户已计算好的指标，加快打标签速度，比如缓存用户的支付金额这个指标，当用户下了新的一单，就可以通过计算好的支付金额+当前单的支付金额，计算出用户当前最新的支付金额这个指标。；
- 得到用户最新标签结果（某些用户也可能撕掉了某个标签）；
- 更新标签库中用户的标签到最新状态；
- 通过MQ向营销系统发送消息，由营销系统执行发券操作（需在营销系统提前建好优惠活动参考：数据中台实战（九）：如何搭建全渠道自动化的营销平台）。
三、实战案例
接下来我们通过一个简单的案例：给新注册、已首单的用户实时打标签，实时发券的业务场景，来看一下实时标签引擎的整体流程。
针对这个案例，我们先分析一下用户标签，第一个是新注册未首单用户，第二个是已首单用户，这两个标签涉及到的指标为:用户的注册天数、用户的支付次数，可以开发相应的用户数据指标存放在用户宽表中，然后把这个宽表的数据缓存到实时引擎当中。
比如新注册用户标签的定义是注册时间<1天且支付次数=0，已首单的用户标签的定义是用户支付次数=1。通过标签平台指标的组合和简单的运算，可以配置出2个用户标签：新注册未首单用户、已首单用户。
针对这个案例我们需要监控注册表及订单表（支付表），当用户A完成注册，实时标签引擎发现用户A的注册天数<1且用户A的支付次数是=0的，这个时候可以调用标签平台的接口实时的给用户A打上新注册未首单的标签。
同时通过MQ告知营销系统，用户A新增了新注册未首单的标签，因为营销活动的配置中针对这类用户是发券的，再通过营销系统调用给用户发券的接口完成实时的发券。
当用户A下了首单后，这时实时标签引擎实时计算用户A的支付次数发现=1，并且发现用户A已经不满足注册天数<1且用户A的支付次数是=0这个规则。
这个时候实时标签引擎通过调用用户打标签接口及撕标签接口，给用户新打上了已首单用户的标签，同时撕掉了用户A新注册未首单用户的标签，然后再通过MQ告知营销系统用户A新增了已首单用户的标签，因为营销活动的配置中针对这类用户是发券的，再通过营销系统调用给用户发券的接口完成实时的发券。
四、最后的话
实时标签引擎还是一个非常有用的系统，一些通用的策略如首单、复购等，几乎任何的互联网产品都会涉及到。
同时实时标签的玩法也属于数据智能的应用，从案例中你可以看到所有的策略配置后都是由机器自动完成，运营人员要做的更多是策略的优化。因为有了实时标签引擎大大提高了用户的体验，用户达到某个策略值时可以无延迟的收到优惠券，这样就进一步促进了用户的复购机率。
还有一些更复杂的玩法比如某段时间内的用户的支付金额满XX元、沉默召回（距离上一次支付时间超过XX天的用）、以老带新（成功推荐一个新用户注册，并且新用户完成了首单支付）等策略，做起来思路也类似，但实现起来就更加繁琐一点，欢迎留言与我讨论。
#相关阅读#
《数据中台实战（二）：基于阿里OneData的数据指标管理体系》
《数据中台实战（一）：以B2B点电商为例谈谈产品经理下的数据埋点》
#专栏作家#
Wilton董超华，微信公众号：改变世界的产品经理，人人都是产品经理专栏作家。畅销书《数据中台实战》作者，曾任职科大讯飞，现任富力环球商品贸易港数据中台产品负责人。主要分享商业、产品、运营、数据中台相关原创文章。
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
文章评论