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

如何在一周内上线50个用户增长策略（TOP100直击）

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

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

• 研发周期长。一开始，我们先用最快的实现方案来做，主要是为了快速验证规则策略的有效性，并没有做大而全的设计，每个需求都是case by case地写代码来实现。那么从开始开发真正能到上线，很可能就是三周，主要因为客户端发版是有窗口的。
• 运营效率慢。因为上线慢，导致获取业务数据后再分析效果就很晚了，然后还要根据数据再去做调整那就更晚了。这样算下来，一年也上不了几个规则策略。

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

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

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

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

规则引擎的局限性

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

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

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

新的解决方案

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

• SQL已经是语义完备的编程语言，不用再去做额外的语法设计。
• SQL是一门很简单的语言，不需要花太多时间就可以掌握。
• 我们闲鱼的运营同学会写SQL，这样会让上线效率更快。

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

• 增加了条件表达式。可以支持更丰富更复杂的事件描述，也就能支撑更多的业务场景。
• 增加了时间表达式。通过WITHIN关键字，定义了一个时间窗口。通过HAVING之后跟的DISTINCT等关键字，就可以针对时间窗口内的事件进行聚合计算。使用新的方案，就可以很好地解决上述C2C业务上的规则描述问题。
• 扩展性强。遵循了业界标准，与具体业务的输入和输出无关，便于推广。

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

整体分层架构

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

在这个分层架构里，至上而下分别是：

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