导读:年初的一个晨会上,用户增长负责人湘翁问我说:一个周内上线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 表达

原文链接
本文为云栖社区原创内容,未经允许不得转载。

一个周内上线50个增长策略,竟然能这么高效!相关推荐

  1. TOP100直击|如何在一周内上线50个用户增长策略

    导读:年初的一个晨会上,用户增长负责人湘翁问我说:一个周内上线50个增长策略,技术兄弟们能做到么? 在用户增长业务上的实验 闲鱼的用户增长业务具有如下现状: 闲鱼的卖家都是普通小卖家,而非专业的B类商 ...

  2. 如何在一周内上线50个用户增长策略

    在闲鱼用户增长业务上的实验 我们最先落地的业务是在用户增长上,闲鱼的用户增长业务有如下描述: 闲鱼的卖家都是普通小卖家,而非专业的B类商家.因此无法统一组织起来参加营销活动带来买家活跃. 我们目前DA ...

  3. 【干货】完美日记增长策略深度研究报告.pdf(附下载链接)

    大家好,我是文文(微信:sscbg2020),今天给大家分享一个干货资料<完美日记增长策略深度研究报告.pdf>,美妆赛道尤其是对完美日记感兴趣的伙伴们别错过啦!另外,我们也搭建了美妆行业 ...

  4. 知乎万赞回答:如何在一周内快速摸清一个行业?

    除了咨询顾问和券商的研究员需要每天研究行业外,其他职场人/打工人也会在以下场合中快速的了解某个行业: 职业选择,跳槽换工作时:哪家企业所在的行业有优势,未来会有更多的机会?哪个行业给的薪资会更高?行业 ...

  5. 基于A股周内效应择时策略验证与思考(附代码)

    基于A股周内效应择时策略验证与思考 本文思路来自于东吴证券研报<A股市场的周内效应>内容,对A股市场的日历效应在周内表现进行探索. 上述研报的核心内容简述: 1.A股市场在股票指数和个股上 ...

  6. 这么简单的量化策略,居然能跑赢大盘10倍 | A股周内效应

    观前提醒,本文硬核,阅读时间较长 本文的由来要从9月10日星期四我发的一条朋友圈说起. 当天全球股市暴跌,基本上所有的主要指数都是绿的,我持仓股票比指数跌的还要多. 所以有那么点抑郁,收盘之后准备读研 ...

  7. 【SQL开发实战技巧】系列(十九):数据仓库中时间类型操作(进阶)如何一个SQL打印当月或一年的日历?如何确定某月内第一个和最后—个周内某天的日期?

    系列文章目录 [SQL开发实战技巧]系列(一):关于SQL不得不说的那些事 [SQL开发实战技巧]系列(二):简单单表查询 [SQL开发实战技巧]系列(三):SQL排序的那些事 [SQL开发实战技巧] ...

  8. 项目经理怎么在两周内熟悉一个项目的业务?

    项目经理空降到一个进行中的项目,怎么在两周内熟悉一个项目的业务? 四步帮你解决:明确项目业务目标,了解系统功能模块,弄清系统核心业务流程,多使用系统. 一.明确项目业务目标 明确项目业务目标,也就是了 ...

  9. 程序员一周内了解一个行业的方法

    感觉很适合程序员阅读,毕竟搞技术的都很宅,对应一些非技术的事物,都是抱着事不关己高高挂起的态度. 原文:程序员一周内了解一个行业的方法 写得有点像做FBI的,所以看看不会有什么坏处的. 我们都是有理想 ...

最新文章

  1. word录入表单数据 java 导入系统,java导入excel | 怎么把excel中的数据批量导入到word中的表格中...
  2. C++实现 找出10000以内的完数
  3. 民生银行场景化数据中台是如何炼成的?
  4. 题解【黑匣子_NOI导刊2010提高(06)】(洛谷P1801)
  5. centos 卸载ffmpeg_CentOS Linux 操作系统安装 FFmpeg 教程
  6. 【摘录】MTK按键扫描原理及相关代码
  7. keil及iar调试解释
  8. easyui源码翻译1.32--Window(窗口)
  9. Bailian2786 Pell数列【数列】(POJ NOI0102-1788,POJ NOI0103-1788)
  10. ubuntu类似sourcetree的git可视化工具安装
  11. 泰坦尼克号沉没之谜,用数据还原真相——Titanic获救率分析(用pyecharts)
  12. java下载文件下载不动_JAVA实现文件下载,浏览器端得到数据没反应
  13. windows下的gitbub使用入门
  14. 《领导力与沟通艺术》
  15. 十二星座物语,女生最喜欢的星座性格【1】
  16. 'Project Name' was compiled with optimization - stepping may behave oddly
  17. 穆迪收购Omega Performance,加强在线信贷培训平台
  18. 输入法规则(U模式输入)
  19. odis工程师使用教程_odis工程师版6.7.5图文安装教程
  20. NOI的1.8.20反反复复

热门文章

  1. 为什么不可以使用哈曼顿距离_K-means真的不能使用曼哈顿距离吗?
  2. 谈一谈Java编程开发中的并发控制
  3. Java开发需要达到什么样的水平才称得上架构师?
  4. java编程有什么独特之处?
  5. mysql怎么实现生日字段前一个小时提醒_MySql学习笔记(二) 索引的设计和使用...
  6. PHP调整图片饱和度,window_Win10系统电脑屏幕的饱和度如何调整?,什么是饱和度? 对电脑来说 - phpStudy...
  7. php fast cgi nginx,通过fast-cgi连接php-fpm和nginx之间的连接是持...
  8. android oat如何提取dex文件字节码,Android: 使用oatdump反编译oat文件
  9. 先出报表还是先计提所得税_一道大综合题搞定“与子公司的内部交易合并报表抵销分录”的逻辑...
  10. element ui 多个子组件_ElementUI 技术揭秘(2) 组件库的整体设计