运营分析利器——SLS窗口漏斗分析

简介: 漏斗分析当下已被广泛应用于产品运营分析过程中,成为用户增长、客户流失、留存转化等的重要分析方法。 常见的漏斗分析过程如下图所示,当产品或者运营活动发布后, 通过收集运营数据、并建立漏斗模型,然后根据漏斗模型进行统计和分析,定位问题,从而进行对应的优化迭代,并持续跟踪,最终实现用户增长、产品优化等目标...

1. 概述

漏斗分析当下已被广泛应用于产品运营分析过程中,成为用户增长、客户流失、留存转化等的重要分析方法。 常见的漏斗分析过程如下图所示,当产品或者运营活动发布后, 通过收集运营数据、并建立漏斗模型,然后根据漏斗模型进行统计和分析,定位问题,从而进行对应的优化迭代,并持续跟踪,最终实现用户增长、产品优化等目标。


image.png

2. 常见漏斗模型

在实际业务中,业务形态千差万别,不同的业务会产生自己特定的漏斗模型,常见的漏斗模型主要有以下几种。

1. AARRR模型该模型是用于分析用户增长和生命周期最常用的漏斗模型,从用户增长各阶段入手,包括Acquisition用户获取 → Activation用户激活 → Retention用户留存 → Revenue用户产生收入 → Refer自传播等用户的生命阶段,进行漏斗分析,判断用户流失大致处于哪个阶段,进而对问题阶段的用户进行细分,精细化运营,完成用户向成熟用户和付费用户的引导,实现用户增长。


image.png



2. 电商漏斗模型该模型是电商领域最常见的漏斗模型,根据用户的购物行为,从进入电商平台 → 查看商品详情 → 加入购物车 → 支付的完整流程,计算每一个环节的转化和流失情况,有助于我们分析是人(用户定位?)货(商品热销?)场(产品功能、体验如何)哪个因素的问题,从而有的放矢地优化具体环节,提升购买转化率。


image.png


3. 功能漏斗模型该模型是运营推广活动或工具类产品的常见漏斗模型,从活动推广 → 用户报名 → 用户达标 → 抽奖奖励等各个业务环节统计分析,有助于我们定位问题环节,进一步定位是广告文案不好,还是投放的广告位转化效率低?是用户报名的操作过于复杂?还是用户达标的门槛过于苛刻?是奖品设置的和参赛用户调性不符还是领奖的流程复杂有bug?


image.png


4. AIDMA模型该模型是消费者行为学领域很成熟的理论模型之一,由美国广告学家E.S.刘易斯在1898年提出。 该理论认为,消费者从接触信息到最后达成购买,会经历这5个阶段:注意 → 兴趣 → 欲望 → 记忆 → 行动(购买),消费者们从不知情者变为被动了解者再变为主动了解者,最后由被动购买者变为主动购买者的过程,从商品角度看可以看到市场从不了解、了解、接受的过程,在品牌营销领域应用得很广泛。


image.png


3. SLS窗口漏斗分析

上面对漏斗模型和分析过程进行了概述,但是落实到具体的运营分析工作中,其实是有大量的细节工作需要去做。


image.png


从产品或者运营活动的发布开始,团队的产品、开发、运维、运营等各个角色的人员就需要开启整个产品生命周期的运作,不同的角色需要负责不同的环节,涉及到产品的发布,数据的采集,数据的转换、处理和存储,运营分析的模型建立,多个维度的数据计算和漏斗分析、产出报表并持续的趋势跟踪、不断地迭代优化和分析验证。 整个过程环环相扣,上下游需要紧密协作,相互依赖,每一个环节既有很多繁琐的细节工作需要完成,又对下游工作产生影响,这其实是对整个团队提出了很高的要求。SLS针对此类运营分析的场景和用户需求,提供了一站式的数据采集、存储、处理和分析服务,其具有以下几个特点能够很好地解决用户痛点: 1、数据开箱即用用户行为和日志数据方便地采集到SLS,即可立即开始查询和分析等工作 2、满足灵活多变的迭代和分析需求产品的迭代往往是多变的,SLS无须像传统数据库或数仓一样建立严格的Schema,可以方便地建立实时索引,并立即对查询和分析有效。此外,我们下文重点提到的漏斗分析函数能够支持灵活多变的事件定义,满足多变的分析需求 3、支持多维度分析漏斗分析往往会从多个不同维度进行,不管是按照用户,还是商品分类、还是推广渠道,SLS的SQL分析语法(通过window_funnel + group by)都可以非常灵活地支持 4、自助可视化和报警最终,我们可以产出可视化仪表盘,方便对产品迭代进行持续的反馈追踪,还可以设置报警,及时发现业务异常

SLS针对运营分析需求,为用户专门提供了窗口漏斗函数,用于计算在滑动时间窗口内所定义的事件链中发生的最大连续事件数。它相比于简单离散统计各阶段的总量,具有事件连续,滑动时间窗口等特点,能更真实地统计和分析漏斗过程。

该函数采用如下算法:

  • 该函数搜索事件链中的第一个事件并将事件计数器设置为1,并开启滑动窗口。

  • 在滑动窗口内,若事件链中的后续事件顺序发生(1-3-2-3也算1-2-3顺序发生),则计数器依次递增。

  • 如果事件序列中断,则停止本轮搜索,计数器不再增加;并开始新一轮搜索,直到结束。

  • 结束时,如果存在多个搜索结果,则该函数将仅输出最长链的大小。

以下图举例说明,用户在时间轴上相继发生了事件1、2、4、5、1、3这6个事件,我们定义事件链为 1->2->3->4->5,那么窗口漏斗函数如下:

select window_funnel(100, timestamp, event_id, ARRAY['1', '2', '3', '4', '5'])

即,在滑动时间窗口(100s)内,事件链为 1->2->3->4->5,计算发生的最大连续事件数。 计算过程:从发生第一个事件(事件1)起开启滑动时间窗口,在滑动时间窗口(100s)内,每发生事件链中的后一个事件,则结果+1;整个时间范围内,可能发生多次第一个事件(事件1),重新开始新一轮计算,最终取最大值返回。 如下图所示,计算结果为2,最终在100s内发生的最大连续事件是1->2。


image.png


注:事件4也在滑动窗口内,但是因为事件3未发生,因此不能计入结果。

4. 窗口漏斗函数语法

window_funnel(int, int, ARRAY[bool, bool, ...])

形如:

select window_funnel(sliding_window, timestamp, ARRAY[event_id='A', event_id='B', ...])

其中, sliding_window,表示滑动时间窗口,类型为bigint,单位为秒,指定常量值 timestamp,表示当前时间戳,类型为bigint,单位为秒,推荐使用日志内置字段timeARRAY[event_id='A', event_id='B', ...],表示定义的事件链,最多支持32个事件,其中每个元素表示一个事件,可以支持任意SQL逻辑表达式,以便于用户自定定义事件。 这种形式适用于事件定义非枚举值,可能包含自定义逻辑的查询,给用户提供一定的灵活性。

5. 使用案例

下面以大家都比较熟悉的电商漏斗模型为例,详细讲解SLS漏斗分析的使用过程。 我们假设某店铺做了一个推广活动,希望分析本次推广活动的转化效果,建立漏斗模型如下:


image.png


我们将访问日志接入到SLS,格式可能是最简单的Ngnix日志,形如:

timestamp

user_id

method

uri

response_time

...

1630286480

1

GET

/item/1

1630286482

2

POST

/cart

...

...

...

...

之后,无须对访问日志进行二次转化,便可直接进行漏斗分析。 首先,定义事件链我们可以基于method和uri定义每个事件:

事件

事件表达式

进入活动页

method='GET' and uri='/activity'

参与活动

method='POST' and uri='/register'

访问商品

method='GET' and regexp_like(uri, '/item/\d+')

添加购物车

method='POST' and uri='/cart'

支付

method='POST' and uri='/pay'

结合我们定义的漏斗模型和漏斗函数语法,事件链表示为:

ARRAY[method='GET' and uri='/activity', 
      method='POST' and uri='/register', 
      method='GET' and regexp_like(uri, '/item/\d+'), 
      method='POST' and uri='/cart', 
      method='POST' and uri='/pay']

其次,按照用户分组,并指定时间窗口我们分析每个摄入用户的行为转化,按照用户进行分组分析,并指定对有限时间窗口内的用户行为分析,因此我们指定滑动时间窗口为24h,最终我们的SQL形如:

* | SELECT user_id, window_funnel(86400, timestamp,  
                                  ARRAY[method='GET' and uri='/activity', 
                                        method='POST' and uri='/register', 
                                        method='GET' and regexp_like(uri, '/item/\d+'), 
                                        method='POST' and uri='/cart', 
                                        method='POST' and uri='/pay']) as levels
            GROUP BY user_id order by user_id

结果输出:

 user_id | levels
---------+--------
       1 |      3
       2 |      1

表示: 用户1在24h内发生了3个连续事件,即 进入活动页->参与活动->访问商品; 用户2在24h内发生了1个连续事件,即 进入活动页

然后,根据上述结果进一步分析漏斗1、先聚合window_funnel计算结果,得出触达某一串事件链的用户数

select e, count(1) c from (
	select user, window_funnel(86400, timestamp, ARRAY[...]) e from log group by user_id
) where e > 0 group by e order by e

结果输出:

e            |     c
-------------+--------
1            |    550          --》表示用户进入活动页的有550人
2            |    183          --》表示用户进入活动页->参与活动的有183人
3            |     56          --》表示用户触达活动页->参与活动->访问商品的有56人
4            |     18          --》表示用户触达活动页->参与活动->访问商品->加入购物车的有18人
5            |      8          --》表示用户触达活动页->参与活动->访问商品->加入购物车->支付的有8人

2、计算各阶段流失情况,算出流失率(流失率 =(上阶段-本阶段)/上一阶段)

select e, c, if(lag(c,1,0) over() = 0, 0, (1.0*lag(c,1,0) over() - c)/lag(c,1,0) over()) from (
  select e, count(1) c from (
    select user, window_funnel(86400, timestamp, ARRAY[...]) e from log group by user_id
  ) where e > 0 group by e order by e
) order by e);

结果输出:

 e |  c  |       流失率
---+-----+------------------------------------------
 1 | 550 |       0.0        --》流失率为0%
 2 | 183 |       0.667      --》流失率为66.7%
 3 |  56 |       0.694      --》流失率为69.4%
 4 |  18 |       0.679      --》流失率为67.9%
 5 |   8 |       0.556      --》流失率为55.6%

最后,我们还可以通过SLS漏斗图进行可视化展示:


image.png


此外,我们还可以基于商品分类进行进一步的漏斗分析,这里不一一展开。

6. 总结

漏斗分析是运营和数据分析的常用方法,一般在进行漏斗分析前后需要做很多的数据准备、转化、存储等繁琐的工作,SLS针对用户的痛点,实现了窗口漏斗分析函数,并提供数据采集、处理、分析、可视化等一站式服务,且具有开箱即用、灵活自定义、多维度分析、自助可视化和报警等特性,为用户开展运营分析工作提供便利。

7. 参考

[SLS SQL分析概述]

[数据分析思维:一文读懂漏斗分析]

作者介绍
目录