大赛简介

目前互联网领域有很多公司都在做APP领域的“用户行为分析”产品，与Web时代的行为分析相类似，其目的都是帮助公司的运营、产品等部门更好地优化自家产品，比如查看日活和月活，查看渠道来源，提高留存、转化、活跃度等等。在这个研发过程中，有个比较核心的需求，叫做“有序漏斗”。“有序漏斗”问题定义比较简单，但计算过程比较复杂。市面上现有的解决方案在数据量较大的情况下，计算效率较低。为了更好的提升产品体验，易观决定将此需求作为比赛题目，广招各路大牛，共同解决。大赛分为2组，开源组和商业组。开源组设置奖金池和排行榜，商业组最后设置排行榜。

根据提供的应用转化和OLAP场景，给出具体的方案，先利用测试数据集在指定测试集群上运行给出测试结果，最终易观会用实际测试数据在测试集群上跑整体数据并给出用时排名。

开源排行榜，第1名现金人民币10万（税前）奖励，前3名易观证书

商业排行榜，前3名易观证书

问题定义

漏斗分析是帮助运营人员分析一个多步骤过程中每一步的转化与流失情况。

假设我们在购买商品的过程中，需要触发的事件包括 “启动”，“登陆”，“搜索商品”，“查看商品”，“生成订单”等。运营人员需要分析某段时间内（比如2017年1月5号到2017年2月5号），在全部用户中依次有序触发 “登陆”→“搜索商品”→“查看商品”→“生成订单“ 事件的人群的转化流失情况，即计算全部用户中触发了“登陆”事件的总人数A，A中触发“搜索商品”事件的总人数B，B中触发“查看商品”事件的总人数C，以及C中触发“生成订单”事件的总人数D。展现形式如下：

同时，漏斗分析中包含“时间窗口”的概念，即需要保证所有事件在同一个窗口期内发生。比如时间窗口为1天，用户001触发“搜索商品”事件的时间和触发“登陆”事件的时间间隔在一天内，“搜索商品”事件才有效，否则视为无效。同理，用户001触发“查看商品”事件的时间和触发“登陆”事件的时间间隔也必须在一天内。时间窗口可以为1天、3天、7天或者1小时、6小时等任意长时间段。最后，在漏斗分析中，可以设置事件属性。比如“搜索商品”事件，可以设置只计算“搜索商品”事件的属性中“content”字段为“computer”的用户。具体见详细数据。

测试数据

链接：密码： z3m8

数据为文本文件格式，具体包含字段有：

（1）用户ID，字符串类型

（2）时间戳，毫秒级别，Long类型

（3）事件ID，Int类型，包含10001到10010十个事件

（4）事件名称，字符串类型，包含启动、登陆、搜索商品等十个事件

（5）事件属性，Json串格式

（6）日期，字符串类型

数据总条数6亿左右，日期范围：2017/01/01到2017/02/28。

比赛评判说明

所有提交的方案都必须可行，开源组须公开思路及源代码，商业组只须公开思路，具体使用哪些软件可自行设定。评委会随机设定漏斗需求，所有参赛方案根据具体需求计算结果，在结果准确的基础上，耗时最少者获胜。漏斗需求举例如下：

（1）计算2017年1月份中，依次有序触发“搜索商品”、“查看商品”、“生成订单”的用户转化情况，且时间窗口为1天。

（2）计算2017年1月和2月份中，依次有序触发“登陆”、“搜索商品”、“查看商品”、“生成订单”、“订单付款”的用户转化情况，且时间窗口为7天，“搜索商品”事件的content属性为Apple，“浏览商品”事件的price属性大于5000。

目前通用算法与实例

目前通用60分的算法如下，给各位参赛者做参考，同时源代码稍后公布，大家可以基于这个算法或者自建更好的算法优化。

（1）底层存储用HDFS

（2）建立Hive表，并以应用标识、日期、事件名称为分区

（3）查询用presto，并自定义UDAF，或者利用Spark core自定义相同逻辑

硬件系统配置

centos7、16核|16G内存、SSD数据盘300G的ucloud云主机4台

目前易观在以上配置的4台机器上测试漏斗耗时统计如下:

1、查询2017年1月份，时间窗口为7天，事件顺序为10001、10004、10008的漏斗，结果为[3999974, 3995900, 3608934]，24秒

2、查询2017年1月份，时间窗口为3天，事件顺序为10004、10008、10010的漏斗，结果为[3999422,3573367,697506]，13秒

3、查询2017年1月份，时间窗口为3天，事件顺序为10004、10007、10009、10010，并且10004事件的brand属性为’Apple’的漏斗，结果为[3639301, 2449480, 559517, 35795]，13秒

大赛简介

问题定义

测试数据

比赛评判说明

目前通用算法与实例

合作媒体