武汉的开发者们注意啦!AI技术战略、框架以及最佳实战尽在Azure OpenAI Day 了解详情
写点什么

一个周内上线 50 个增长策略,竟然能这么高效

  • 2019-12-05
  • 本文字数:3167 字

    阅读完需:约 10 分钟

一个周内上线50个增长策略,竟然能这么高效


导读:年初的一个晨会上,用户增长负责人湘翁问我说:一个周内上线 50 个增长策略,技术兄弟们能做到么?

✪ 在闲鱼用户增长业务上的实验 ✪

闲鱼的用户增长业务具有如下现状:


  • 闲鱼的卖家都是普通小卖家,而非专业的 B 类商家。因此无法统一组织起来参加营销活动带来买家活跃。这一点是与淘宝/天猫的差别。

  • 我们目前 DAU 已经突破到 2000W ,如何承接好这么大体量的用户,对运营同学是个很大的考验。

  • 为了能更好地做好用户增长,在今年年初时,我们在用户增长下做了多个实验,希望提高用户停留时长。用户浏览时间越长,就越有可能发现闲鱼上还有很多有趣的内容,无论是商品宝贝还是鱼塘内的帖子。从而达到吸引用户下一次还能再回来的目的,最终带来用户增长。其中两个实验如下:


我们做的实验上线后大部分都取得了不错的业务效果,但是在过程中也暴露了两个问题:


  • 研发周期长 一开始,我们先用最快的实现方案来做,主要是为了快速验证规则策略的有效性,并没有做大而全的设计,每个需求都是 case by case 地写代码来实现。那么从开始开发真正能到上线,很可能就是三周,主要因为客户端发版是有窗口的。

  • 运营效率慢 因为上线慢,导致获取业务数据后再分析效果就很晚了,然后还要根据数据再去做调整那就更晚了。这样算下来,一年也上不了几个规则策略。

✪ 工程化解法——基于事件流的规则引擎 ✪

针对上述问题,我们先做了一层业务抽象。运营先通过对用户的各种行为进行一个分析和归类,得出一个共同的具体的规则,再将这个规则实时地作用到用户身上进行干预。



针对这层业务抽象,我们再做了工程化,目的就是为了提升研发效率和运营效率。这样就有了第一个方案——基于事件流的规则引擎,我们认为用户的行为是一串顺序的行为事件流,使用一段简单的事件描述 DSL ,再结合输入和输出的定义,就可以完整地定义一个规则。



以上述用户增长的第二个实验为例,如下图所示的 DSL 即可简单表达出来:



✪ 规则引擎的局限性 ✪

该规则引擎可以很好地解决之前用户增长业务下的几个策略,随后我们进行了内部推广,准备在闲鱼 C2C 安全业务下也落地。在 C2C 安全业务上有如下描述:



在 C2C 安全业务上,也有一个看似是一个针对一系列行为作出的规则抽象,如下图所示:



但是将上述规则套上规则引擎后,就会发现无法将安全的规则套上规则引擎。假设我们的详细规则是 1 分钟内被拉黑 2 次,就对该用户打上高危标记。那么我们想一想,当来了第一个拉黑事件后,匹配上了。然后紧接着来了第二个拉黑事件,也匹配上了。此时按照规则引擎的视角,条件已经满足了,可以进行下一步操作了。但是再仔细看一看规则,我们的规则是要被不同的用户拉黑,因为有可能是同一个用户操作了多次拉黑(同时多开设备)。而规则引擎上只知道匹配到了 2 次拉黑事件,对规则引擎来说已经满足了。却无法知道是否是不同人操作的。其根本原因是因为在规则引擎里,事件都是无状态的,无法回溯去做聚合计算。


✪ 新的解决方案 ✪

针对规则引擎的局限性,重新分析和梳理了我们的实际业务场景。并结合了业界知名的通用的解决方案后,设计出了新的方案,定义了新的 DSL 。可以看到,我们的语法是类 SQL 的,主要有以下几个考虑:


  • SQL 已经是语义完备的编程语言,不用再去做额外的语法设计。

  • SQL 是一门很简单的语言,不需要花太多时间就可以掌握。

  • 我们闲鱼的运营同学会写 SQL,这样会让上线效率更快。

  • 新的 DSL 方案与之前的规则引擎相比主要有以下几个增强:

  • 增加了条件表达式。可以支持更丰富更复杂的事件描述,也就能支撑更多的业务场景。

  • 增加了时间表达式。通过 WITHIN 关键字,定义了一个时间窗口。通过 HAVING 之后跟的 DISTINCT 等关键字,就可以针对时间窗口内的事件进行聚合计算。使用新的方案,就可以很好地解决上述 C2C 业务上的规则描述问题。

  • 扩展性强。遵循了业界标准,与具体业务的输入和输出无关,便于推广。

  • 针对之前的 C2C 业务上的规则描述问题,使用新方案的例子如下:



▶ 整体分层架构


基于这套用 EPL(Event Programming Language)写出的 DSL,为了做好工程化,我们做了如下的整体分层架构。为了快速实现最小闭环验证效果,我们选择先基于 Blink(Blink 是阿里对 Flink 的内部优化和升级)做云上的解析和计算引擎。


在这个分层架构里,至上而下分别是:


  • 业务应用 在这里是我们整个系统的业务方,已经在多个业务场景下做了落地。

  • 任务投放 这里是对业务应用层提供 DSL 声明和投放的能力,能可以做简单的圈人,以及与用户触达模块的关联。

  • 用户触达 这个模块用于接收来 EPL 引擎计算的结果,根据关联的 Action 来实施动作。同时这个模块也可以独立对业务应用提供服务,即各个业务方可以拥有自己的逻辑,通过用户触达模块来触达用户。

  • EPL 引擎 目前已经实现了云上的解析和结算。用于接收来自任务投放里声明的 DSL,再去解析和运行在 Blink 上。

  • 事件采集 负责通过服务端日志和行为打点里采集行为事件,并归一化地输出给 EPL 引擎。


▶ 事件采集


通过切面的方式拦截所有的网络请求和行为打点,再记录到服务端日志流里。同时通过一个事实任务对事件流进行清洗,按前面定义的格式清洗出我们想要的事件。再将清洗后的日志输出到另一个日志流里,供 EPL 引擎来读取。



▶ EPL 实现


由于我们采取了类 SQL 语法,而 Calcite 是业界通用的解析 SQL 的工具,因此我们采用 Calcite 并通过自定义其中的 parser 来解析。如果是单一事件的 DSL ,则会解析成 Flink SQL 。如果是多事件的 DSL ,则会解析后通过直接调用 Blink 的 API 接口的方式来实现。



▶ 用户触达


当 EPL 引擎计算出结果之后,会输出给用户触达模块。首先会进行一个 Action 路由,最终决策出需要由具体哪一个 Action 来响应,最后通过与客户端之间的长连接将 Action 下发到端上。端上收到具体的 Action 后,会先判断当前用户的行为是否允许展示该 Action。如果可以的话,就直接执行 Action 的具体内容,曝光给用户。用户看到这次响应后会有相应的行为,那么这部分的行为会影响到 Action 路由,对这次的路由的做出一个反馈。



✪ 应用落地 ✪


新方案上线后,我们就在越来越多的业务场景里进行了落地。这里列举 2 个例子:





在上述鱼塘的例子里,可以看出来,我们这套方案已经有了一点算法推荐的影子了。在上述租房的例子里,由于规则过于复杂,用 DSL 表达起来很麻烦,所以就做成只采集 4 次浏览不同租房宝贝的规则,即触发后,就将这里的数据都给到租房的具体开发的业务方,这也是我们在落地过程中摸到的边界。

✪ 结论 ✪

使用这一套完整方案,研发效率上有了很大的提升。原先通过写代码 case by case 的方式一般要 4 个工作日完成整个研发流程,极端情况下需要跟客户端版本则需要 2-3 周的时间。现在通过写 SQL 的方式一般要 0.5 个工作日即可上线。


此外,这套方案还有如下几个优势:


  • 高性能 整条链路计算完毕平均耗时 5 秒。

  • 高可靠 依托于 Blink 的高可靠性,承载了双十一上亿的流量。

  • 通过在多个业务的落地实践,我们也摸索出来这套方案的适用边界:

  • 对实时性要求高

  • 强运营主导规则

  • 能够用 SQL 表达

✪ 未来规划 ✪

当前整套方案还有如下几个方向可以进一步探索:


  • 整条链路计算完毕平均需要 5 秒左右。如果放到对实时性要求更高的游戏任务场景下时,这就无法满足了。

  • 闲鱼的业务已经连年保持了高增长,未来可能会面对比当下翻三番的用户流量,如果所有计算依然全部放在云上,则对云上的算力消耗是个极大的挑战。

  • 目前我们的设计上,是没有算法接入的,只有简单的圈人。而为了让规则的投放更加精准,进而提升规则对用户的有效性,是需要与算法结合的。

  • 综上,我们未来的规划将会聚焦于端侧实时计算能力的挖掘和算法能力的结合上。在这两个能力的扩展上,我们将与端智能团队一起共建 BehaviR 框架,预计明年 1 月会落地。

  • One More Thing


本文转载自“淘系技术”公众平台。


原文链接:https://mp.weixin.qq.com/s/YnCRhY3SBT4PUIVOyZA4Ig


2019-12-05 09:27652

评论

发布
暂无评论
发现更多内容

Firebase 命令行工具

HoneyMoose

书单|互联网企业面试案头书之数据分析师篇

博文视点Broadview

MySQL主从原理,基于快速学习一门技术的3种方式

博文视点Broadview

【Axure9百例】47.CSDN的列表样式

zhuchuanming

原型设计 Axure 交互原型

Centos7下Docker安装&配置&镜像加速

happlyfox

学习 ,docker 3月日更

2020 年前端技术发展盘点

三钻

发展 大前端 组件化 机会与趋势

华为云副总裁薛浩:云原生视频服务,重塑体验,助力产业升级

华为云开发者联盟

云原生 音视频 视频 华为云 AR/VR

我还不懂什么是分布式事务

好好学习,天天向上

Java MySQL spring 分布式 事务

科普NA公链(Nirvana):NAC公链采用基于NIO的Netty,实现链上应用百万级TPS并发​

区块链第一资讯

来,在图片上画个矩形吧,取经之旅第 14 天

梦想橡皮擦

3月日更

无需编程,通过配置零代码生成CRUD RESTful API

crudapi

RESTful 低代码 API crud crudapi

工作四年,分享50个让你代码更好的小建议

比伯

Java 程序员 架构 程序人生 计算机

记上周双休日的加班

sadhu

加班

史上最全教程:idea将Java项目打包Jar包,并生成exe可执行文件

madison

Java jar包转exe可执行文件 exe4j

AA

郑伟

标签

局域网服务器访问外网方案

程序员与厨子

Linux 网络 路由表

PS 进行隐藏图制作

空城机

PhotoShop ps 视觉处理 视觉 隐藏图

Redis - 主从模式

insight

redis 3月日更

算法:求两个单向链表的最早公共交点

程序员架构进阶

算法 链表 28天写作 3月日更 算法解析

从新手到专家:如何设计一套亿级消息量的分布式IM系统

JackJiang

架构设计 即时通讯 IM

双非怎么了

我是程序员小贱

3月日更

缓存不一致、缓存雪崩、缓存击穿、缓存穿透

escray

redis 学习 极客时间 3月日更 Redis 核心技术与实战

Kafka、RabbitMQ、RocketMQ 之间的区别是什么 ?

AI乔治

Java kafka 架构 消息队列

go + ffmpeg + goav 实现拉流解码器

张音乐

音视频 ffmpeg Go 语言 goav

关于Vue权限路由思考

程序员海军

Vue 大前端 vue-router 权限认证 按钮权限

图片的黑魔法——GitHub 热点速览 v.21.13

HelloGitHub

GitHub 开源

Python API 类型系统的设计与演变

李宇飞

API

万物皆可拆

小匚

推进智能变革,HPE让零售业的数字化梦想照进现实

Lily

Java + opencv实现视频人脸检测

张音乐

OpenCV 人脸识别 视频

区块链农产品溯源系统开发,区块链农产品溯源平台的搭建

13828808769

区块链 区块链+ #区块链#

一个周内上线50个增长策略,竟然能这么高效_文化 & 方法_兰昊_InfoQ精选文章