数据中台实战:以圆猿买手为案例谈如何从0到1搭建实时标签引擎

0 评论 2721 浏览 12 收藏 14 分钟

导语:在上一篇数据中台的实战文章《数据中台:从0到1打造一个离线推荐系统》中,作者为我们讲了如何打造一个支撑N条产品线的标签平台,这篇文章,作者分享了如何从0到1打造一套可以实时计算的标签引擎。

最近公司开了个新的产品线叫:圆猿买手,大家都知道我公司搭了一个B2B的女装批发平台,主要服务的是全国做服装批发生意的采购商、供应商。圆猿买手这个产品是从B2B平台独立出来专门服务二批采购商的产品。

什么是二批采购商?简单来说就是大客户,他们一般在二级的服装批发市场如郑州银基等有自己的档口,主要去一级的批发市场(一级的批发市场如广州十三行、杭州四季清等)拿货,拿完货后销售给自己的所在城市的终端门店或者三批采购商。

作为二批采购商,他们每次拿货(采购)的量都是非常大的,因为是我们的大客户,所以我司配备专门的买手给二批采购商提供一对一的推款、找款、发货的服务。

买手是活跃在批发市场的一类角色,他们的核心竞争力就是对市场的档口、档口的新款、爆款比较熟悉,而且他们是常驻在批发市场的,这样二批采购商拿货就不用每次都长途跑到一批市场,只用和我们的买手沟通,就能拿到市场的新款、爆款。

为什么圆猿买手这个业务能够存在?

我觉得有2点原因:

1)由于买手的存在,大大降低了采购商的交易成本

交易成本就是买卖双方所付出的时间和金钱成本,交易类产品是否能够存在,都可以用这个交易成本这个理论来衡量,交易成本理论是诺贝尔奖获得者科斯老爷子很多年前提出来的。

二批采购商一般都在二三线城市的批发市场,每次跑到如广州十三行这种一级批发市场,来回都要很多的时间,路费也是一笔不少的钱,有了买手的存在大大节省了他们的时间和钱。

2)买手的存在让人货匹配更加精准

这里的人是指二批采购商,货是指一级批发市场的商品。电商产品的创新很重要的一点就是提高人货匹配的效率,我提供的商品刚好是你需要的,这样买卖双方付出的时间成本最低。

一个经验丰富的服装买手对市场中的档口和档口的新款、爆款都是非常熟悉的,而且由于买手长期和采购商沟通,这样他会非常清楚当前服务的这个采购商的偏好,这种情况下买手推的商品会更能命中二批采购商的口味。

由于买手的存在,交易模式从二批采购商到市场去找商品,到买手精准的推给采购商大致符合他口味的商品,采购商从买手推的商品中挑一个商品就好了,这种模式好像搭建了一个人肉的推荐系统。

一、产品方案

这篇文章我们讲的主题是实时标签,什么是实时标签?

比如一个用户新注册、首单、复购、复购金额达到1000/3000/5000…..立即给用户发不同的优惠券,从而刺激用户首单及再次复购。有的同学会说,这还不简单,用户每次下单时计算当前用户的指标,然后再触发发券不就行了嘛。

当然如果你的产品运营策略只有如新注册、首单后给用户发券这两种简单的策略而且不会发生变动,这种简单的策略我们通过前端应用计算当前用户的标签,然后调用优惠券的接口给用户发券就行了。

但当你面对几十种不同的策略,未来可能是几百种发券测试时,而且这个策略可能会随时调整,难道你的业务逻辑还要写在应用端吗?

当时我们的策略有这么N多种:新注册、首单、复购、复购金额满XX元、当月支付金额满XX元、沉默召回(距离上一次支付时间超过XX天的用户)、以老带新(成功推荐一个新用户注册,并且新用户完成了首单支付)…

每新增一个策略你就需要改代码,重新测试、发布,这样是非常痛苦的。

当时我们团队看到运营拿过来的几十种发券策略,一开始也比较懵,但经过分析后,我们定了3个目标:

  1. 这个实时发券的功能,一定要独立出来,不能影响应用端的主业务流程;
  2. 要能够做到实时发券,如果用户达到某个策略(比如新注册、首单等),隔天再去发券,这样体验很不好;
  3. 简单的策略要可以实现配置化,比如复购金额满XX元,这个完全要在界面可以配置出来,新增一种类似的策略不用修改代码,就可以完成策略的上线。

产品功能层面是通过现有的标签平台(可以看之前的文章:数据中台实战(八):如何打造可以支撑N条产品线的标签平台)完成人群的初始化。

比如新注册、已首单用户,增加一种标签的类型叫实时标签,通过监控用户的注册、支付等行为,实时的检查用户现有的标签,实时的计算这个行为该打上那个标签、该撕掉那个标签,然后通过消息队列的方式通知营销系统,完成用户新增标签的优惠券发放。

二、技术方案

下图就是实时标签的技术实现方案,要想看懂这个方案,可以先温习一下之前写的一篇标签平台的文章(数据中台实战(八):如何打造可以支撑N条产品线的标签平台):

(原创)数据中台实战:以圆猿买手为案例谈如何从0到1搭建实时标签引擎

首先是离线标签处理的流程:

  1. 群组的数据,比如已首单用户这个用户群下都有哪些人打上了这个标签;
  2. 标签规则数据,已首单的规则就是 用户支付次数这个指标=1;
  3. 用户的数据,这里存放的是用户宽表中的各种指标,比如用户的基础信息、当前的支付次数、支付金额等等。

接下来是实时打标签的处理过程:

  1. 首先是通过CDC (捕获数据变化)工具如Debezium监控数据库库表的变化情况;
  2. 通过如Debezium等工具告知kafka数据库的变化情况;
  3. 筛选对打标签有用的事件如注册、支付等事件;
  4. 读取给用户打标签的规则(如首单的规则是判断用户当前的支付次数是否等于1);
  5. 实时打标签的过程,比如用户由未首单打上已首单的标签:可以缓存用户已计算好的指标,加快打标签速度,比如缓存用户的支付金额这个指标,当用户下了新的一单,就可以通过计算好的支付金额+当前单的支付金额,计算出用户当前最新的支付金额这个指标。;
  6. 得到用户最新标签结果(某些用户也可能撕掉了某个标签);
  7. 更新标签库中用户的标签到最新状态;
  8. 通过MQ向营销系统发送消息,由营销系统执行发券操作(需在营销系统提前建好优惠活动参考:数据中台实战(九):如何搭建全渠道自动化的营销平台)。

三、实战案例

接下来我们通过一个简单的案例:给新注册、已首单的用户实时打标签,实时发券的业务场景,来看一下实时标签引擎的整体流程。

针对这个案例,我们先分析一下用户标签,第一个是新注册未首单用户,第二个是已首单用户,这两个标签涉及到的指标为:用户的注册天数、用户的支付次数,可以开发相应的用户数据指标存放在用户宽表中,然后把这个宽表的数据缓存到实时引擎当中。

比如新注册用户标签的定义是注册时间<1天且支付次数=0,已首单的用户标签的定义是用户支付次数=1。通过标签平台指标的组合和简单的运算,可以配置出2个用户标签:新注册未首单用户、已首单用户。

(原创)数据中台实战:以圆猿买手为案例谈如何从0到1搭建实时标签引擎

针对这个案例我们需要监控注册表及订单表(支付表),当用户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 协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!