图片 6

APP数据统计调研

作者:陈小二

数据统计平台调研报告

问题: 小程序使用微信支付的单页面pv数偏高,致页面转化率低

对于业务开发者来说,业务数据和数据监控是不可缺失的。

图例是我们小程序扫码付业务在数据体系搭建过程中的其中一步:技术流程拆解。

图片 1image.png

在数据选型上,我同时使用了微信自定义数据统计和公司内部第三方数据统计,并将之与微信主动上报的数据分析进行对比,来确保数据准确性。

微信自定义数据统计和公司内部第三方数据统计方法:

图片 2image.png

微信主动上报数据查询参见MP后台 微信实时统计:

图片 3image.png

在数据的收集过程中,我发现支付按钮点击率(点击支付次数/页面展示次数)仅有50%+。

对比我们内部相同的H5服务,转化率过低,远远不符合我们对业务预期效果。

核查3种数据分析,我发现页面展示次数过高,并且三种方法的页面展示次数有较大差异,其中:

 微信自定义数据统计pv 约等于 公司内部第三方数据统计pv 微信实时统计pv < 自定义数据统计 (包括微信自定义和公司内部第三方字数据统计)

微信实时统计pv的统计方法不得而知,而另外两种方法均是在onshow事件中触发。

一、调研目的

原因:

排查过程中,发现页面在涉及到支付时,微信调起弹窗,会再次触发onshow事件,从而导致pv数重复发送。

对于微信来说,支付完以后会触发支付完成页,如图所示:

图片 4image.png

点击完成后再次回到页面会继续触发onshow事件。

目前有多种APP应用数据统计平台,如友盟、腾讯移动分析、Cobub
Razor、Bugly等。当前运营统计需求有按公司进行分组统计PV、UV等数据,因此需要对上述几个平台进行调研。

解决方案:

从技术上来说,onshow事件本应设计如此。页面再次展示应该触发onshow。

从业务上来说,onshow事件是应该用来做pv统计的。但因为涉及到类似支付的事情,业务方需要自己控制pv发送时机。

目前我的解决方案:onload中统计。

图片 5image.png

问题虽小,记录下来的意义更大。

另外:欢迎加入弱势群体(开发小程序的前端工程师们)共享bug组织

也欢迎一起贡献仓库:小程序bug集合)共享bug组织

1.名词解释:

PV:即页面浏览量;用户每1次对APP中的每个网页访问均被记录1次。用户对同一页面的多次访问,访问量累计。

UV:指访问某个站点或点击某条新闻的不同IP地址的人数。

二、调研内容

1.友盟

友盟包含如下统计分析种类:

1)应用概况

实时统计:今日与历史数据的对比

整体趋势:APP应用的整体概要、用户数的趋势统计

2)用户分析

新增用户:按日、周对第一次进行启动的用户的统计

活跃用户:按日、周对启动过一次的用户的统计

沉默用户:用户在安装后或次日无启动行为的统计

启动次数:对用户打开应用次数统计

版本分布:应用的版本进行统计

行业对比:同行业APP对比

3)用户构成

周用户构成:对回流用户、连续活跃用户、忠诚用户的统计

用户成分转化:对变化系数的趋势统计

4)留存分析

留存用户:某段时间新增的用户,经过一段时间后,仍继续使用的用户

5)渠道分析

分析各渠道用户数量的趋势对比

6)用户参与度

使用时长:一次启动的使用时长

使用频率:日启动的次数

访问页面:用户一次启动访问的页面数量

使用间隔:同一用户两次启动间隔时间

7)功能使用

页面访问路径:用户从打开到离开应用整个过程中每一步骤的页面访问。

自定义事件:事件的触发次数。

事件转化率:整个事件的最终转化率

8)终端属性

设备机型、分辨率、操作系统、网络、运营商、地域等信息

9)错误分析

错误趋势:错误数、影响用户数、影响用户/活跃用户、错误解决率

错误列表

10)社会化分享

如果集成了友盟的社会化分享,可统计应用社会化分享

11)消息推送

友盟实现了消息推送功能。

12)APP发送策略

启动时发送、按间隔发送

调研结论:友盟可支持很多数据的统计,包括其自己的社会化分享和消息推送,植入SDK方便快捷,属于埋点统计,支持用户分组,分组方式如下:

a)活跃时间

b)触发、不触发事件

SDK无法修改,不能发送到指定服务器,无法支撑需求。

2.腾讯移动分析

腾讯移动分析是腾讯出的一款数据统计平台,可统计的数据有:

1)应用概况

实时统计:今日与历史数据的对比

整体趋势:APP应用的整体概要、用户数的趋势统计

2)用户、设备分析

用户留存率:某段时间新增的用户,经过一段时间后,仍继续使用的用户

用户流失与回流:在一个观察周期后不活跃的用户与超过一个周期后,用户再次使用的统计

用户活跃度:

用户画像:通过用户数据画出用户基本画像

设备画像:用过设备基本信息

用户时段:启动次数、新增用户、活跃用户

周用户构成:对一周内的回流、流失、活跃、忠实用户的统计

3)版本渠道分析

渠道分布:不同渠道的新增、活跃、启动次数等

渠道效果:不同渠道的留存、使用时长、使用次数

版本分布:不同版本的新增、活跃、启动次数、时长

4)用户参与度

使用时长、频率:

页面访问:人均访问页面数量

页面路径:从一个页面去向其他路径的分流情况

页面来源:所选页面访问量的来源情况

5)事件分析

自定义事件:事件的触发次数

漏斗模型:事件转化

6)质量监控

错误统计:错误发生次数

错误分析:错误原因

错误告警:当错误达到一定比率,可邮件、微信通知开发人员

统计接口监控:对统计的接口的失败率,耗时等监控

网速监控:感觉意义不大。。

7)上报策略

实时发送

wifi下发送

批量发送(达到30条发送)

启动时发送

开发者模式

间隔时间发送

调研结论:腾讯移动分析统计内容较细,SDK植入便捷,支持用户群组,用户群支持如下情况:

a)时间段范围

b)设备属性

c)触发自定义事件

d)触发漏斗

由于SDK不能修改,无法发送到指定URL,另外群组无法支持运营需求。

3.CobubRazor

Cobub
Razor是一款开源的统计平台,服务平台可以部署在本地,SDK可以自行修改上传地址和参数格式。其平台统计内容有:

1)应用概况

分布渠道:按渠道统计新增、日活、启动次数、使用时长、周活、月活等

版本分布:按版本统计新增、活跃用户数

2)用户

使用频率:统计使用次数

使用时长:统计每次使用时长

分时段趋势:按时段统计活跃、新增数量

页面访问路径:用户的页面访问路径比例

地域分析:按地域统计用户启动次数和新增用户数量

用户留存:

用户行为轨迹

3)终端网络

设备型号

操作系统

分辨率

运营商

联网方式

厂商

4)事件转化率

事件转化率:即自定义事件流的转化率

5)错误分析

错误趋势

错误列表

6)发送策略

启动时发送

立即发送

定时发送

调研结论:Cobub

Razor,其统计平台统计内容相对较少,不支持分组统计,不过可以对其SDK进行修改,将数据发送到指定URL上。再由服务器开发人员开发统计平台。

4.Bugly

Bugly将运营统计和bug上报分成两个模块,即Bugly更加重视bug分析处理,其统计项如下:

1)应用概览

对使用用户、启动次数、安装用户、版本渠道统计

2)用户分析

版本分布:累计新增用户、使用用户、启动次数

留存分析:用户的留存分析

使用频率、时长:可按渠道、版本统计用户启动次数、使用时长

3)渠道分析

渠道分布:分渠道统计用户启动次数、新增用户数

4)异常上报

异常概览:统计用户崩溃率、次数崩溃率、发生次数、影响用户数、用户联网数等,可多版本对比

崩溃分析:崩溃的log,开发者可设置已处理,可按版本、是否处理查询,崩溃详情可以查看手机信息及崩溃日志和页面跟踪

卡顿分析:统计遇到的卡顿异常,及相应的手机信息、日志和页面跟踪

错误分析:

调研结论:Bugly正如其名,更加注重APP出现的bug分析处理,在数据统计方面统计项较少,统计内容不丰富。建议采用bugly对app进行bug统计分析。

图片 6