腾讯罗盘模型和指标说明

返回腾讯罗盘简介

What's New?

2012年11月5日,“黄钻开通系数”模型变更为“VIP开通系数”,其中包含了黄钻开通系数、会员开通系数、蓝钻开通系数,详见这里
2012年9月7日,腾讯罗盘新增社交渠道效果模型,以及渠道运营分析、刚性用户流失、万人商业价值等高级分析模型。

1. 模型概览

1.1 平台分析模型

平台分析模型是指无需开发者进行开发,由腾讯罗盘后台系统通过OpenAPI自动采集数据,从而展示的业务数据视图。

平台分析模型包括的模型及对应支持的平台如下表所示:
compass_legend_1.png

分类 模型名称 模型支持的平台
全部(多平台数据去重) 空间 朋友 微博 Q+
概况 应用总览 API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png
同时在线 API_legend_6.png API_legend_6.png API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG
VIP开通系数 API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG
 
新用户 新安装来源分析 FusionAPI_2.JPG API_legend_6.png API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG
新安装留存分析 API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png
社交渠道效果 API_legend_5.png API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png
新安装付费分析 API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG
广告效果跟踪分析 FusionAPI_2.JPG API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png
交叉推广跟踪分析 FusionAPI_2.JPG API_legend_6.png API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG
 
用户行为 登录来源分析 FusionAPI_2.JPG API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png
 
用户参与度 在线时长 API_legend_5.png FusionAPI_2.JPG API_legend_6.png API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG
用户活跃天 API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png
用户连续活跃天 API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png
 
用户属性 用户属性 API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png API_legend_6.png
 
收入 收入总览 API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG
用户付费天 API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG
新增付费用户分析 API_legend_6.png FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG FusionAPI_2.JPG

:“全部”是和空间、朋友等并排的一个tab,即拉取应用在全部平台的数据汇总并去重,不提供单个平台的拆分数据。

1.2 高级分析模型

高级分析模型是指需要开发者调用数据上报API上报数据,腾讯罗盘的数据仓库对用户数据进行计算,从展示各种维度的业务数据视图(根据应用上报通道的不同,展现的数据可能有差异)。

高级分析模型包括的模型如下表所示:
(注:高级分析模型支持空间、朋友、微博、Q+、QQGame、3366等多个平台,具体支持的平台详见数据上报时domain字段的说明)

分类 模型名称
概况 API_legend_5.png 基本运营信息
渠道运营分析
Benchmark分析
实时统计(暂不支持)
 
用户分析 API_legend_5.png 用户活跃度分析
新注册活跃跟踪
刚性用户流失
分区分服数据
 
用户行为 操作分析
入口操作分析
出口操作分析
 
用户参与度
操作次数分布
在线时长分布
会话操作次数
会话数分布
 
收入 API_legend_5.png 用户付费分析
新注册付费分析
首次充值场景
万人商业价值


2. 平台分析模型指标详细说明

应用总览

此模型主要提供应用整体概况,帮助开发者快速了解应用的健康度。
主要指标如下:

指标 说明
日活跃用户数(DAU) 统计周期内,有新安装或者登录行为的独立用户数。新安装指用户成功将应用添加到应用列表,登录指用户点击应用列表或者应用中心中的对应应用。(如果1个用户当天登录了多次,则按1个用户算)。
周活跃用户数(WAU) 统计时间起倒推7天内,在7天内有新安装或者登录行为的独立用户数。新安装指用户成功将应用添加到应用列表,登录指用户点击应用列表或者应用中心中的对应应用。
月活跃用户数(MAU) 统计时间起倒推31天内,在31天内有新安装或者登录行为的独立用户数。新安装指用户成功将应用添加到应用列表,登录指用户点击应用列表或者应用中心中的对应应用。
新安装用户数 统计周期内,成功将应用添加到应用列表的独立用户数。
最高在线用户数 统计周期内,同时在线的用户数的最大值。


同时在线

此模型主要描述用户在线的情况,帮助开发者了解用户的活跃度情况。

判断一个用户在线的规则:
在某个时间点,如果某个用户在前推30分钟内在应用内有操作行为,则认为在线;反之,如果前推30分钟内没有任何操作,则认为不在线。


主要指标如下:

指标 说明
同时在线 某个时间点的该应用整体在线用户数。
最高在线用户数 每5分钟统计一次,每天共288个点,这288个点的在线用户数的最大值。
最低在线用户数 每5分钟统计一次,每天共288个点,这288个点的在线用户数的最小值。
平均在线用户数 每5分钟统计一次,每天共288个点,平均在线用户数为288个点的在线用户数总和/288。


VIP开通系数

此模型主要描述应用每日用户开通腾讯各VIP业务(包括黄钻、会员、蓝钻)的系数,以及应用中各VIP用户占付费用户、活跃用户的比例。

(1)每种VIP的开通系数乘以的固定数值均不同。
(2)如果您的应用没有在空间或者朋友上线,则对应的黄钻开通系数为空;

     如果您的应用没有在Q+上线,则对应的会员开通系数为空;
     如果您的应用没有在qqgame或者3366上线,则对应的蓝钻开通系数为空。


黄钻开通系数
开发者可以使用该模型的数据来计算一周内平均每日黄钻系数,并与黄钻拉动量化奖励机制中的标准比对,以进行黄钻推广位的申请。
黄钻拉动量化奖励机制详见这里
主要指标如下:

指标 说明
黄钻开通系数 应用每日开通黄钻用户数 * 固定数值
黄钻活跃比 应用在空间+朋友的活跃用户群中,身份为黄钻的用户数 / 应用在空间+朋友的活跃用户数
黄钻付费比 黄钻用户当天付费人数 / 应用当天付费用户数
黄钻付费金额比 黄钻用户当天付费金额 / 应用当天付费金额


会员开通系数
主要指标如下:

指标 说明
会员开通系数 应用每日开通会员用户数 * 固定数值
会员活跃比 应用在Q+的活跃用户群中,身份为会员的用户数 / 应用在Q+的活跃用户数
会员付费比 会员用户当天付费人数 / 应用当天付费用户数
会员付费金额比 会员用户当天付费金额 / 应用当天付费金额


蓝钻开通系数
主要指标如下:

指标 说明
蓝钻开通系数 应用每日开通蓝钻用户数 * 固定数值
蓝钻活跃比 应用在qqgame+3366的活跃用户群中,身份为蓝钻的用户数 / 应用在qqgame+3366的活跃用户数
蓝钻付费比 蓝钻用户当天付费人数 / 应用当天付费用户数
蓝钻付费金额比 蓝钻用户当天付费金额 / 应用当天付费金额


新安装来源分析

此模型主要描述安装应用的新用户的来源,帮助开发者了解应用新用户的来源。
主要指标如下:

指标 说明
来源渠道 用户安装应用的主要入口,包括:

1. 资源位:应用中心以及应用内页的免费资源位。资源位描述以及规则详见:资源位使用简介

2. 社交渠道:包含以下个子类
(1)召唤老朋友:需应用调用接口。详见:社交渠道-好友召回
(2)QQ提醒:需应用调用接口。详见:QQ提醒推广渠道简介
(3)说说:需应用调用接口(下线)。详见:fusion2.dialog.tweet
(4)邀请:需应用调用接口。详见:社交渠道-邀请
(5)挑战:需应用调用接口。详见:fusion2.dialog.brag
(6)炫耀:需应用调用接口。详见:fusion2.dialog.brag
(7)好友请求:需应用调用接口。详见:社交渠道-好友请求
(8)免费礼物:需应用调用接口。详见:社交渠道-免费礼物
(9)游戏故事:需应用调用接口。详见:fusion2.dialog.sendStory
(10)应用内分享:需应用调用接口(下线)。详见:fusion2.dialog.share
(11)试玩:需应用调用接口。详见:fusion2.dialog.shareDemo
(12)平台主动:属于平台为应用默认提供的社交渠道,包含安装feeds和好友在玩。详见:社交渠道-平台主动


3. 交叉推广:依托于任务体系,用户完成任务领取奖励的鼓励因素,可以给应用带来很好的安装转化率以及更多活跃用户。交叉推广渠道说明详见:交叉推广渠道简介

4. 应用列表:个人中心左侧应用列表,以及个人中心顶部应用墙;

5. 广告:广告投放(详见:广点通使用简介),包含两个部分
(1)广告直接流量:用户点击在广点通投放的广告,直接安装;
(2)广告引荐流量:用户点击在广点通投放的广告后,在一定的时间后通过其它渠道安装。

6. 其它:其它平台推广入口,例如:黄钻拉动奖励资源位(详见:第三方应用拉动黄钻用户量化奖励机制),以及腾讯开放平台不定期推出的各种推广活动。

新安装用户数 在统计时间内,通过对应入口安装应用的独立用户数。
新安装量占比 通过单个渠道新安装用户数 / 整体新安装用户数 。


新安装留存分析

此模型主要描述某天新安装的用户,跟踪这批用户,在接下来30天每天的活跃情况,帮助开发者了解新用户的留存情况。
主要指标如下:

指标 说明
X日留存率 统计周期内新安装的用户,跟踪这批用户,在X日后的某天有登录行为的独立用户数量为X日留存用户数,X日留存率=X日留存用户数/某日新安装用户数量。例如,计算2011年11月1日的3日留存率,在2011年11月1号新安装用户有1000人,这1000人在2011年11月4号当天有登录行为的用户有800人,则2011年11月1号的3日留存率为800/1000=80%


社交渠道效果

此模型主要描述社交渠道的拉新效果。
主要指标如下:

指标 说明
使用社交渠道人数 统计时间内,应用中使用了社交渠道的用户数。

社交渠道包含以下类型:
(1)召唤老朋友:需应用调用接口。详见:社交渠道-好友召回
(2)QQ提醒:需应用调用接口。详见:QQ提醒推广渠道简介
(3)说说:需应用调用接口(下线)。详见:fusion2.dialog.tweet
(4)邀请:需应用调用接口。详见:社交渠道-邀请
(5)挑战:需应用调用接口。详见:fusion2.dialog.brag
(6)炫耀:需应用调用接口。详见:fusion2.dialog.brag
(7)好友请求:需应用调用接口。详见:社交渠道-好友请求
(8)免费礼物:需应用调用接口。详见:社交渠道-免费礼物
(9)游戏故事:需应用调用接口。详见:fusion2.dialog.sendStory
(10)应用内分享:需应用调用接口(下线)。详见:fusion2.dialog.share
(11)试玩:需应用调用接口。详见:fusion2.dialog.shareDemo
(12)平台主动:属于平台为应用默认提供的社交渠道,包含安装feeds和好友在玩。详见:社交渠道-平台主动

引入新安装用户数 统计时间内,通过社交渠道安装应用的用户数。
拉新率 引入新安装用户数 / 使用社交渠道人数。
社交渠道引入活跃用户数 统计时间内,通过社交渠道安装应用或者进入应用的用户数。
1日传播度 社交渠道引入活跃用户数/使用社交渠道人数。


新安装付费分析

此模型主要描述某天新安装的用户,在接下来30天每天的付费情况,帮助开发者了解应用新用户的付费情况。
主要指标如下:

指标 说明
X日付费率 X日付费率=X日付费用户数/某日新安装用户数量。

X日付费用户数:指统计周期内新安装的用户,在X日后当天有付费行为的独立用户数量。
例如:计算2011年11月1日的3日付费率,在2011年11月1号新安装用户有1000人, 这1000人在2011年11月4号当天有付费行为的用户有100人,则2011年11月1号的3日付费率为100/1000=10%。


广告效果跟踪分析

此模型主要描述通过广点通投放广告带来的新用户安装量,以及老用户的活跃度。特别地,针对广告带来的新用户进行跟踪,分析这批用户后续的留存率,付费情况等,帮助开发者了解通过广告带来的新用户的用户质量。
主要指标如下:

指标 说明
广告规格 用户通过广点通投放的广告的规格,不同的广告位有不同的规格。详细信息请参见:广告展示的详细位置
曝光量 广告被用户看到的次数。
点击量 排除恶意点击后,广告被用户点击的次数。
安装量 用户通过点击广告链接到应用并产生安装行为的用户数。
登录用户数 通过点击对应广告规格登录应用的独立用户数。
投入成本 广告主投放该广告消耗的成本。
N日转换为付费用户数 通过广告带来的新安装用户,在N日内有付费行为的用户数。
N日引入收入 通过广告带来的新安装用户,在N日内带来的收入(单位为Q点)。
N日APRU N日引入收入 / N日转换为付费用户数。
N日回本率 N日引入收入 / 投入成本。
N日传播效果 通过广告带来的新安装用户,他们的好友在N日内有安装应用的用户数。
N日留存率 通过广告带来的新安装用户,在安装后的第N天,有活跃行为的独立用户数 / 安装量。
N日内累计在线时长 通过广告带来的新安装用户,在N日内,在app内的累计在线时长(单位为分钟)。


交叉推广跟踪分析

此模型主要描述通过交叉推广渠道带来的新用户安装量。针对这些新用户进行跟踪,分析这批用户后续的留存率,付费情况等,帮助开发者了解通过交叉推广渠道带来的新用户的用户质量。
主要指标如下:

指标 说明
卖方应用名称 交叉推广渠道中卖方应用的名称。详细信息请参见交叉推广渠道简介
安装量 在统计时间,用户通过领取卖方显示的任务链接到应用并产生安装行为的数量。
转换为付费用户数 在统计时间,通过领取卖方显示的任务而新安装应用的用户,到当前时间至,转化为付费用户的独立用户数。
1日留存用户数 在统计时间,通过领取卖方显示的任务而新安装应用的用户,在安装后的第1天,有活跃行为的独立用户数。
7日留存用户数 在统计时间,通过领取卖方显示的任务而新安装应用的用户,在安装后的第7天,有活跃行为的独立用户数。
30日留存用户数 在统计时间,通过领取卖方显示的任务而新安装应用的用户,在安装后的第30天,有活跃行为的独立用户数。
引入收入 在统计时间,通过领取卖方显示的任务而新安装应用的用户,到当前时间至,转化为付费用户后付费的总金额(单位:Q点)。
ARPU 引入收入/转换为付费用户数。


登录来源分析

此模型主要描述用户登录应用的入口分布,帮助开发者了解用户登录应用的入口。
主要指标如下:

指标 说明
类型 用户安装应用的主要入口,包括:

1. 资源位:应用中心以及应用内页的免费资源位。资源位描述以及规则详见:资源位使用简介

2. 社交渠道:包含以下个子类
(1)召唤老朋友:需应用调用接口。详见:社交渠道-好友召回
(2)QQ提醒:需应用调用接口。详见:QQ提醒推广渠道简介
(3)说说:需应用调用接口(下线)。详见:fusion2.dialog.tweet
(4)邀请:需应用调用接口。详见:社交渠道-邀请
(5)挑战:需应用调用接口。详见:fusion2.dialog.brag
(6)炫耀:需应用调用接口。详见:fusion2.dialog.brag
(7)好友请求:需应用调用接口。详见:社交渠道-好友请求
(8)免费礼物:需应用调用接口。详见:社交渠道-免费礼物
(9)游戏故事:需应用调用接口。详见:fusion2.dialog.sendStory
(10)应用内分享:需应用调用接口(下线)。详见:fusion2.dialog.share
(11)试玩:需应用调用接口。详见:fusion2.dialog.shareDemo
(12)平台主动:属于平台为应用默认提供的社交渠道,包含安装feeds和好友在玩,详见:社交渠道-平台主动

3. 交叉推广:依托于任务体系,用户完成任务领取奖励的鼓励因素,可以给应用带来很好的安装转化率以及更多活跃用户。交叉推广渠道说明详见:交叉推广渠道简介

4. 应用列表:个人中心左侧应用列表,以及个人中心顶部应用墙;

5. 推广活动及其它:包含以下入口
(1)广告投放(详见:广点通使用简介);
(2)除上述入口外的其它平台推广入口,例如:黄钻拉动奖励资源位(详见:第三方应用拉动黄钻用户量化奖励机制),以及腾讯开放平台不定期推出的各种推广活动。

登录用户数 在统计时间内,通过对应入口登录应用的独立用户数。
登录次数 在统计时间内,用户通过对应入口登录应用的次数。


在线时长

此模型用来描述用户在APP内停留多久。
罗盘后台通过采集心跳数据来采集用户在线时长数据,自用户登录后,每5分钟采集一次心跳。心跳数据的采集时机示意图:
compass_user_online_time.png
此模型暂时只提供QQ空间和腾讯朋友的在线时长数据,后续会陆续提供其它平台的数据。
主要指标如下:

指标 说明
在线时长 用户在此APP中全天的在线时长累计,每天00:00时清零。由于平台数据采集的心跳为5分钟,因此在线时长分布以5分钟的整数倍为单位进行数据展现。
用户数 在线时长在某个在线时长区间内的用户数。

例如0-5分钟的用户数为8000,表示有8000个用户登录时长在(0,5]分钟的区间内。


用户活跃天

此模型为日报,主要描述当天开始最近一段周期内用户活跃度。周均活跃天越高,表示用户的活跃度越高。
主要指标如下:

指标 说明
周活跃天 在统计日期内所有的活跃用户,往前倒推7天内,用户任意在7天内活跃了N天,则活跃天为N天。

例如查看2012年1月7日的数据,用户A在1月7号活跃,同时倒推7日内,在1月6日,1月2日活跃,则此用户的活跃天为3日。

双周活跃天 在统计日期内所有的活跃用户,往前倒推14天内,用户任意在14天内活跃了N天,则活跃天为N天。
月活跃天 在统计日期内所有的活跃用户,往前倒推31天内,用户任意在31天内活跃了N天,则活跃天为N天。
周/双周/月均活跃天 周/双周/月内所有活跃用户活跃天的平均值。

计算公式:周期内所有活跃用户的活跃天求和/周期内活跃独立用户数。


用户连续活跃天

此模型为日报,主要描述当天开始最近一段周期内用户连续活跃度。
主要指标如下:

指标 说明
周连续活跃天 在统计日期内所有的活跃用户,往前倒推7天内,用户连续活跃了N天,则活跃天为N天。

例如查看2012年1月7日的数据,用户A在1月7号活跃,同时连续倒推7日,在1月6日,1月5日活跃,则此用户的连续活跃天为3日。

双周连续活跃天 在统计日期内所有的活跃用户,往前倒推14天内,用户连续活跃了N天,则活跃天为N天。
月连续活跃天 在统计日期内所有的活跃用户,往前倒推31天内,用户连续活跃了N天,则活跃天为N天。


用户属性

此模型主要描述应用内每个自然月活跃用户的属性,包括年龄、性别、地域,帮助开发者了解该应用的活跃用户群。
说明
1. 自然月:指每个月的第1天至每个月的最后1天。例如:选择2011年2月,即统计周期为2011年2月1号至2011年2月28日。
2. 此模型数据更新时间为每月10日,每月10日更新上个自然月的数据。
3. 新上线的应用,只能在上线后的下个自然月才能查看此数据。例如:应用在2012年10月13号上线,此数据只能在2012年11月10日左右查看。
4. “未定义”属性值,表示此用户没有在相关腾讯产品设置自己的属性,腾讯罗盘无法识别。

主要指标如下:

指标 说明
年龄占比 各个年龄段的用户在所有活跃用户中所占的百分比。
性别占比 所有活跃用户中男性和女性所占的百分比。
地域占比 各个省份的用户在所有活跃用户中所占的百分比。


收入总览

此模型主要描述当日用户在应用内使用游戏币(用户通过Q币/Q点购买的虚拟币)和Q点的概况。
注:这里只针对接入“Q点直购”模式的应用进行统计,暂不支持接入“道具寄售”模式的应用。
主要指标如下:

指标 说明
付费用户数 统计周期内,在应用内通过游戏币或者Q币/Q点有购买行为的独立用户数量
付费次数 统计周期内,在应用内通过游戏币或者Q币/Q点的购买行为总次数
收入 统计周期内,在应用内用户购买花费游戏币和Q点的总和,单位为Q点
单均价 收入/付费次数
ARPU 收入/付费人数


用户付费天

此模型为日报,主要描述当天开始最近一段周期内用户付费活跃度。
周均付费天越高,表示用户的付费越频繁。
主要指标如下:

指标 说明
周付费天 在统计日期内所有的付费用户,往前倒推7天内,用户任意在7天内在N天有付费行为,则付费天为N天。

例如查看2012年1月7日的数据,用户A在1月7号付费,同时倒推7日内,在1月6日,1月2日付费,则此用户的付费天为3日。

双周付费天 在统计日期内所有的付费用户,往前倒推14天内,用户任意在14天内在N天有付费行为,则付费天为N天。
月付费天 在统计日期内所有的付费用户,往前倒推31天内,用户任意在31天内在N天有付费行为,则付费天为N天。
周/双周/月均付费天 周/双周/月内所有付费用户付费活跃天的平均值。

计算公式:周期内所有付费用户的付费天求和/周期内付费独立用户数。


新增付费用户分析

此模型主要描述新增付费用户数和同比增长情况(新增付费用户为:某用户在整个应用生命周期里第一次付费)。
主要指标如下:

指标 说明
日新增付费用户数 统计日期内,新增付费的独立用户数。
日新增付费用户数同比 (当天日新增付费用户数-昨天日新增付费用户数) / 昨天日新增付费用户数。
周新增付费用户数 统计日期前推7天内,新增付费的独立用户数。
周新增付费用户数同比 (当天周新增付费用户数-7天前周新增付费用户数) / 7天前周新增付费用户数。
双周新增付费用户数 统计日期前推14天内,新增付费的独立用户数。
双周新增付费用户数同比 (当天双周新增付费用户数-14天前双周新增付费用户数) / 14天前双周新增付费用户数。
月新增付费用户数 统计日期前推31天内,新增付费的独立用户数。
月新增付费用户数同比 (当天月新增付费用户数-31天前月新增付费用户数) / 31天前月新增付费用户数。


3. 高级分析模型指标详细说明

基本运营信息

此模型通过游戏用户注册、登录、支付三项基本行为数据,反映当天游戏运营情况。 帮助开发者了解当日新注册及日活跃用户数,新注册用户的每日存留与流失率情况, 以及每日支付扣费金额。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。

主要指标如下:

指标 说明
新注册用户数 当日首次进入游戏,并在游戏帐号系统中注册帐号的用户数。
日(周/双周/月)活跃用户数 当日(近7天/近14天/近30天)登录过游戏的独立用户数。
日扣费总额 应用当日通过腾讯开放平台提供的支付接口(v3/pay/buy_goods)扣费的总额(单位:Q币)。
日人均扣费额 当日扣费总额/付费用户数。(单位:Q币)
新注册用户每日存留率 从用户注册之日起,之后该批注册用户每天的登录比例。

例如:
2012年7月1日注册用户数为1000人,其中有800人在7月2日登录,第2日存留率为800/1000=80%; 有600人在7月3日登录,第3日存留率为600/1000=60%,以此类推。

新注册用户每日流失率 从用户注册之日起,之后该批注册用户截至统计当日每天最后一次登录比例。

例如:
2012年7月1日注册用户数为1000人,统计日期为7月7日。该批注册用户中有800人在7月1日登录过应用后, 截至7月7日未再次登录过(即截至7月7日,在7月1日最后一次登录的用户数为800人),则第1日流失率为800/1000=80%; 该批注册用户中又有100人在7月2日登录过应用后,截至7月7日未再次登录过,则第2日流失率为100/1000=10%。以此类推。
但相比存留统计,流失观察的是用户从注册日期开始,截至统计日期的最后一次登录时间,所以每日之间用户是不重复的。
且从注册之日起截至统计日期,每日流失用户数相加=注册用户数。


此模型的概览图示例如下:
CBA_15.PNG

渠道运营分析

此模型通过对新用户的注册来源渠道、活跃用户的注册来源渠道、付费用户的注册来源渠道进行汇总分析,观察腾讯开放平台各渠道运营的基本情况。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。
consume:上报用户在应用中进行支付消费的相关信息。

主要指标如下:

指标 说明
新注册用户来源 用户首次进入应用的渠道。例如:腾讯朋友、QQ空间、QQ游戏等渠道。
活跃用户注册来源 统计当日在某平台上应用的活跃用户,分别是从哪个渠道首次注册的。

例如:
2012年1月1日,在QQ空间平台应用活跃用户为1000人,其中800人来自QQ空间首次注册用户,150人来自QQ游戏首次注册用户,50人来自腾讯朋友首次注册用户。

消费用户注册来源 统计当日在某平台上应用中消费的用户,分别是从哪个渠道首次注册的。

例如:
2012年1月1日,在QQ空间平台应用消费用户为1000人,其中800人来自QQ空间首次注册用户,150人来自QQ游戏首次注册用户,50人来自腾讯朋友首次注册用户。


此模型的概览图示例如下:
CBA_16.PNG

Benchmark分析

此模型从用户粘性情况和用户付费情况两个方面对游戏进行分析。
用户粘性部分,分解为两个核心指标:“用户粘度(周平均)”和“新注册用户留存(周平均)”。
付费部分,分解为两个核心指标:“付费渗透率(周平均)”和“付费ARPU值(周平均)”。
实际应用中,在雷达图将游戏的四个指标与“全部应用平均值”和“优秀应用平均值”进行比对,从而明确游戏在整个平台中的相对水平和位置。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。

主要指标如下:

指标 说明
新注册存留率(周平均) 一周内每日新注册用户留存率之和/7
支付ARPU(周平均) CBA_6.PNG
付费渗透率(周平均) CBA_7.PNG
用户粘度(周平均) 一周内每日活跃用户数之和/7


此模型的概览图示例如下:
CBA_17.PNG

实时统计

该数据模型暂不提供。
此模型能统计在每10秒,每20秒,每30秒内应用内每个操作的总次数,帮助开发者实时地了解应用的参与度。


用户活跃度分析

此模型通过用户登录行为,分析用户流失与回流状态、用户平均活跃天数及活跃天数分布。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。

主要指标如下:

指标 说明
周(双周/月)活跃用户数 近7天(14天/30天)内登录过的独立用户数。
周(双周/月)流失用户数 周流失用户数:

统计日倒数第二周(倒数第8-14天)登录过应用,当前一周(倒数第1-7天)未登录过应用的用户数。
例如:
统计日为2012年7月14日,观察在7月1日-7月7日期间登录过的用户,假如为1000人, 这批用户在7月8日-7月14日期间有600人没有再次登录应用,则7月14日统计的周流失用户数为600人。

双周流失用户数:

统计日倒数第二个双周(倒数第15-28天)登录过应用,当前一个双周(倒数第1-14天)未登录过应用的用户数。
例如:
统计日为2012年7月28日,观察在7月1日-7月14日期间登录过的用户,假如为1000人, 这批用户在7月15日-7月28日期间有800人没有再次登录应用,则7月28日统计的双周流失用户数为800人。

月流失用户数:

统计日倒数第二月(倒数第31-60天)登录过应用,当前一月(倒数第1-30天)未登录过应用的用户数。
例如:
统计日为2012年7月30日,观察在6月1日-6月30日期间登录过的用户,假如为5000人, 这批用户在7月1日-7月30日期间有2000人没有再次登录应用,则7月28日统计的月流失用户数为2000人。

周(双周/月)流失率 周流失率:

周流失用户数/倒数第二周活跃用户数。
例如:
统计日为2012年7月14日,观察在7月1日-7月7日期间登录过的用户,假如为1000人,这批用户在7月8日-7月14日期间有600人没有再次登录应用,则7月14日统计的周流失用户数为600人。周流失率为:600/1000=60%。

双周流失率:

双周流失用户数/倒数第二个双周活跃用户数。
例如:
统计日为2012年7月28日,观察在7月1日-7月14日期间登录过的用户,假如为1000人,这批用户在7月15日-7月28日期间有800人没有再次登录应用,则7月28日统计的双周流失用户数为800人。双周流失率为:800/1000=80%。

月流失率:

月流失用户数/倒数第二个月活跃用户数。
例如:
统计日为2012年7月30日,观察在6月1日-6月30日期间登录过的用户,假如为5000人,这批用户在7月1日-7月30日期间有2000人没有再次登录应用,则7月28日统计的月流失用户数为2000人。月流失率为:2000/5000=40%。

周(双周/月)回流用户数 周回流用户数:

统计日倒数第三周(倒数第15-21天)内登录过应用的用户,在倒数第二周(倒数第8-14天)内完全没有登录过应用,然后又在当前周(倒数第1-7天)内重新登录应用的用户数。
例如:
统计日为2012年7月21日,观察7月1日-7月7日期间登录过的这批用户,假如为1000人,这批用户在7月8日-7月14日期间有600人没有再次登录应用,这批600人用户中又有200人在7月15日-7月21日期间重新登录应用,则7月21日统计的周回流用户数为200人。

双周回流用户数:

统计日倒数第三个双周(倒数29-42天)内登录过应用的用户,在倒数第二个双周(倒数第15-28天)内完全没有登录过应用,然后又在当前一个双周(倒数第1-14天)内重新登录应用的用户数。
例如:
统计日为2012年7月12日,观察6月1日-6月14日期间登录过的这批用户,假如为1000人,这批用户在6月15日-6月28日期间有800人没有再次登录应用,这批800人用户中又有300人在6月29日-7月12日期间重新登录应用,则7月12日统计的双周回流用户数为300人。

月回流用户数:

统计日倒数第三月(倒数第61-90天)内登录过应用的用户,在倒数第二月(倒数第31-60天)内完全没有登录过应用,然后又在当前一月(倒数第1-30天)内重新登录应用的用户数。
例如:
统计日为2012年7月30日,观察5月2日-5月31日期间登录过的这批用户,假如为5000人,这批用户在6月1日-6月30日期间有2000人没有再次登录应用,这批2000人用户中又有800人在7月1日-7月30日期间重新登录应用,则7月30日统计的双周回流用户数为800人。

周(双周/月)回流率 周回流率:

周回流用户数/倒数第二周流失用户数。
例如:
统计日为2012年7月21日,观察7月1日-7月7日期间登录过的这批用户,假如为1000人,这批用户在7月8日-7月14日期间有600人没有再次登录应用,这批600人用户中又有200人在7月15日-7月21日期间重新登录应用,则7月21日统计的周回流用户数为200人。周回流率为200/600=33.3%。

双周回流率:

双周回流用户数/倒数第二个双周流失用户数。
例如:
统计日为2012年7月12日,观察6月1日-6月14日期间登录过的这批用户,假如为1000人,这批用户在6月15日-6月28日期间有800人没有再次登录应用,这批800人用户中又有300人在6月29日-7月12日期间重新登录应用,则7月12日统计的双周回流用户数为300人。双周回流率为300/800=37.5%。

月回流率:
月回流用户数/倒数第二个月流失用户数。

例如:
统计日为2012年7月30日,观察5月2日-5月31日期间登录过的这批用户,假如为5000人,这批用户在6月1日-6月30日期间有2000人没有再次登录应用,这批2000人用户中又有800人在7月1日-7月30日期间重新登录应用,则7月30日统计的双周回流用户数为800人。月回流率为800/2000=40%。

周(双周/月)用户活跃天数分布 在统计日近7天(14天/30天)内,用户累计登录天数分布。
周(双周/月)用户平均活跃天数 在统计日近7天(14天/30天)内,用户累计登录天数/周(双周/月)活跃用户数。
新注册用户第一周登录率 在注册当日(第1天)登录后,第2-7天内再次登录的用户占注册用户比例。
新注册用户第二周登录率 在注册当日(第1天)登录后,第8-14天内再次登录的用户占注册用户比例。
新注册用户前两周登录率 在注册当日(第1天)登录后,第2-14天内再次登录的用户占注册用户比例。


此模型的概览图示例如下:
CBA_18.PNG

新注册活跃跟踪

此模型通过对新注册用户进行90天连续登录状态跟踪,帮助开发者了解每阶段注册用户的存留与流失情况。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。

主要指标如下:

指标 说明
新注册用户每日存留率。 从用户注册之日起,之后该批注册用户每天的登录比例。

例如:
2012年7月1日注册用户数为1000人,其中有800人在7月2日登录,第2日存留率为800/1000=80%;有600人在7月3日登录,第3日存留率为600/1000=60%,以此类推。

新注册用户每日流失率 从用户注册之日起,之后该批注册用户截至统计当日每天最后一次登录比例。

例如:
2012年7月1日注册用户数为1000人,统计日期为7月7日。该批注册用户中有800人在7月1日登录过应用后, 截至7月7日未再次登录过(即截至7月7日,在7月1日最后一次登录的用户数为800人),则第1日流失率为800/1000=80%; 该批注册用户中又有100人在7月2日登录过应用后,截至7月7日未再次登录过,则第2日流失率为100/1000=10%。以此类推。
但相比存留统计,流失观察的是用户从注册日期开始,截至统计日期的最后一次登录时间,所以每日之间用户是不重复的。
且从注册之日起截至统计日期,每日流失用户数相加=注册用户数。

新注册用户第1周存留率 在注册第2天至第7天登录过应用的用户数占新注册用户的比例。(注册当日为第1天)
新注册用户第2周存留率 新注册用户第2周存留率 在注册第8天至第14天登录过应用的用户数占新注册用户的比例。(注册当日为第1天)
新注册用户第3周存留率 在注册第15天至第21天登录过应用的用户数占新注册用户的比例。(注册当日为第1天)
新注册用户第4周存留率 在注册第22天至第28天登录过应用的用户数占新注册用户的比例。(注册当日为第1天)
新注册用户第1月存留率 在注册第2天至第30天登录过应用的用户数占新注册用户的比例。(注册当日为第1天)
新注册用户首日流失率 注册日期(第1天)当天登录过应用,从第2天开始直到观察日期连续N天未再登录过应用的用户数占新增注册用户数比例。

例如:
1月1日注册1000名用户,其中有800人在注册当日(1月1日)登录过应用后,从第2天(1月2日)开始截至观察日期(1月10日)连续9天未再此登录,则在1月10日观察1月1日注册的1000名用户,首日活跃后即流失的比例为80%。
注:随着观察日期的变化,流失率也会随之变化。

新注册用户前3日流失率 从注册日期(第1天)开始,3天内登录过应用,从第4天开始直到观察日期连续N天未再登录过应用的用户数占新增注册用户数比例。

例如:
1月1日注册1000名用户,其中有800人在注册3天内(1月3日)登录过应用后,从第4天(1月4日)开始截至观察日期(1月10日)连续7天未再此登录,则在1月10日观察1月1日注册的1000名用户,活跃3天即流失的比例为80%。

新注册用户前7日流失率 从注册日期(第1天)开始,1周(7天)内登录过应用,从第8天开始直到观察日期连续N天未再登录过应用的用户数占新增注册用户数比例。

例如:
1月1日注册1000名用户,其中有800人在注册7天内(1月7日)登录过应用后,从第8天(1月8日)开始截至观察日期(1月14日)连续7天未再此登录,则在1月14日观察1月1日注册的1000名用户,活跃1周即流失的比例为80%。

新注册用户前14日流失率 从注册日期(第1天)开始,2周(14天)内登录过应用,从第15天开始直到观察日期连续N天未再登录过应用的用户数占新增注册用户数比例。

例如:
1月1日注册1000名用户,其中有800人在注册14天内(1月14日)登录过应用后,从第15天(1月15日)开始截至观察日期(1月30日)连续16天未再此登录,则在1月30日观察1月1日注册的1000名用户,活跃2周即流失的比例为80%。


此模型的概览图示例如下:
CBA_19.PNG

刚性用户流失

此模型通过对用户月度流失状态的观察,预测用户近期流失概率。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。

主要指标如下:

指标 说明
连续N天未登录用户刚性流失概率 到观察日为止,连续N天未登录的用户为User1,User1中从观察日到观察日之后(30-N-1)天都未曾登录的用户为User2,则连续N天未登录用户刚性流失概率=(User2/User1)*100%。

刚性流失的跟踪周期为30天。
例如:
到观察日1月5日为止,连续4天未登录的用户为1000人(即1月1日登录,直到1月5日未登录过的用户为1000人),这1000人中从1月5日到1月30号都未曾登录的用户为200人,那连续4天未登录用户刚性流失概率为(200/1000)*100%。


此模型的概览图示例如下:
CBA_20.PNG

分区分服数据

此模型分区显示游戏的运营基础数据,帮助开发者了解分区分服游戏各区的基本运营情况。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。

主要指标如下:

指标 说明
各区新注册用户数 各区每日新增注册用户数。首次登录该区,则记为当日该区新增注册用户。
各区活跃用户数 各区每日活跃用户数。当日登录过该区,则记为当日该区活跃用户。
各区最高在线 各区每日最高同时在线人数。


此模型的概览图示例如下:
CBA_21.PNG

操作分析

此模型主要描述当天在应用内每个操作的用户数和次数,帮助开发者了解应用被操作的情况。
此模型需要开发者根据应用中的操作来调用相应的接口,数据上报接口详见这里

主要指标如下:

指标 说明
操作用户数 当天进行了某个操作的独立用户数量。
操作次数 当天进行了某个操作的总次数。


此模型的概览图示例如下:
CBA_8.PNG

入口操作分析

此模型主要描述在所有会话内的第一个操作(刨除登录、登出、注册操作)的分布情况。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。
report:通用数据上报接口,开发者可根据实际的场景在基本必填字段基础上增加需要的上报字段。

主要指标如下:

指标 说明
操作 每个会话都是由一系列用户操作构成,这里指会话的第一个操作。
会话数 会话的第一个操作为特定操作的个数。


此模型的概览图示例如下:
CBA_9.PNG

出口操作分析

此模型主要描述在所有会话内的最后一个操作(刨除登录、登出、注册操作)的分布情况。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。
report:通用数据上报接口,开发者可根据实际的场景在基本必填字段基础上增加需要的上报字段。

主要指标如下:

指标 说明
操作 每个会话都是由一系列用户操作构成,这里指会话的第一个操作。
会话数 会话的最后一个操作为特定操作的个数。


此模型的概览图示例如下:
CBA_10.PNG

操作次数分布

此模型主要描述当天操作次数的分布,帮助开发者评估用户在应用的参与度变化。
此模型需要开发者根据应用中的操作来调用相应的接口,数据上报接口详见这里

主要指标如下:

指标 说明
操作用户数 在某个操作次数区间的用户数。


此模型的概览图示例如下:
CBA_11.PNG

在线时长分布

此模型主要描述当天所有用户在线时长的分布,用以描述用户的参与度。
每个用户的在线时长为当天所有会话时长的总和,会话的时长为会话的最后一个操作的时间和第一个操作的时间间隔。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。
report:通用数据上报接口,开发者可根据实际的场景在基本必填字段基础上增加需要的上报字段。

主要指标如下:

指标 说明
用户数 在某个在线时长区间的用户数。


此模型的概览图示例如下:
CBA_12.PNG

会话操作次数

此模型主要描述当天在所有会话数里面包含操作次数的分布,即描述用户每次会话在应用的参与度,如果会话操作次数越多,可以反映出用户每次登录后在应用停留的时间越长,帮助开发者评价用户在应用中的参与度。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。
report:通用数据上报接口,开发者可根据实际的场景在基本必填字段基础上增加需要的上报字段。

主要指标如下:

指标 说明
会话数 会话内操作次数的特定区间的总会话数。


此模型的概览图示例如下:
CBA_13.PNG

会话数分布

此模型主要描述当天会话数的分布,帮助开发者评估用户在应用的参与度变化。
此模型需要开发者调用以下接口:
login:上报用户登录应用时的相关信息。
register:上报用户主动注册应用时的相关信息。
report:通用数据上报接口,开发者可根据实际的场景在基本必填字段基础上增加需要的上报字段。

主要指标如下:

指标 说明
用户数 在某个会话数区间的用户数。


此模型的概览图示例如下:
CBA_14.PNG

用户付费分析

此模型通过对用户充值、消费两项行为进行跟踪,分析用户充值与消费趋势,及充值和消费各种额度用户数分布, 同时对用户消费活跃度进行分析,得出用户平均消费天数,帮助开发者综合了解游戏应用的付费总况。
此模型需要开发者调用以下接口:
consume:上报用户在应用中进行支付消费的相关信息。
recharge:上报用户在应用中进行支付充值的相关信息。

主要指标如下:

指标 说明
日充值金额 统计当日,用户通过支付Q币或Q点,兑换游戏内等值货币(例如“点券、金币、元宝”等)所支付的金额(单位:Q币)。
日充值用户数 统计当日,通过支付Q币或Q点兑换游戏内等值货币(例如“点券、金币、元宝”等)的用户数。
日人均充值额 统计当日充值金额/充值用户数(单位:Q币)。
日次均充值额 统计当日充值金额/充值总次数(单位:Q币)。
日活跃用户人均充值额 统计当日充值金额/活跃用户数(单位:Q币)。
日活跃用户充值渗透率 统计当日充值用户数/活跃用户数。
日消费金额 统计当日,用户通过Q币或Q点直接购买游戏内商品,

或者通过游戏内充值兑换的等值货币(例如“点券、金币、元宝”等)购买游戏内商品所支付的总金额(单位:Q币)。

日消费用户数 统计当日,通过Q币或Q点直接购买游戏内商品,或者通过游戏内充值兑换的等值货币(例如“点券、金币、元宝”等)购买游戏内商品的用户数。
日人均消费额 统计当日消费金额/消费用户数(单位:Q币)。
日次均消费额 统计当日消费金额/消费总次数(单位:Q币)。
日活跃用户人均消费额 统计当日消费金额/活跃用户数(单位:Q币)。
日活跃用户消费渗透率 统计当日消费用户数/活跃用户数。


此模型的概览图示例如下:
CBA_22.PNG

新注册付费分析

此模型通过对新注册用户连续90天不间断跟踪,分析新用户首次付费时间、付费金额、付费率趋势等。
此模型需要开发者调用以下接口:
register:上报用户主动注册应用时的相关信息。
consume:上报用户在应用中进行支付消费的相关信息。
recharge:上报用户在应用中进行支付充值的相关信息。

主要指标如下:

指标 说明
新注册每日消费用户数 在该批新注册用户中,在注册第N天通过Q币Q点直接支付,或者通过游戏内充值兑换的等值货币(例如“点券、金币、元宝”等)支付,购买游戏内付费商品的独立用户数。
新注册用户每日消费额 该批新注册用户,在注册第N天通过Q币Q点直接支付,或者通过游戏内充值兑换的等值货币(例如“点券、金币、元宝”等)支付,购买游戏内付费商品所消费的总金额。
新注册用户每日消费率 在该批新注册用户中,每日消费用户数/新注册用户数。
新注册用户首次消费时间 用户从注册之日起,在距离注册日期第N天,首次在应用中有消费行为,第N天即为新注册用户首次消费时间。
新注册用户首次人均消费额 统计当日用户首次消费的总金额/首次消费用户数,单位:Q币。
新注册用户每日充值用户数 在该批新注册用户中,每日通过Q币Q点或RMB充值游戏内等值货币的用户数。
新注册用户每日充值额 在该批新注册用户中,每日通过Q币Q点或RMB充值游戏内等值货币的总金额。
新注册用户每日充值率 在该批新注册用户中,每日充值用户数/新注册用户数。
新注册用户首次充值时间 用户从注册之日起,在距离注册日期第N天,首次在应用中有充值行为,第N天即为新注册用户首次充值时间。
新注册用户首次人均充值额 统计当日首次充值的总金额/首次充值用户数,单位:Q币。


此模型的概览图示例如下:
CBA_23.PNG

首次充值场景

此模型反映用户首次充值发生在什么等级、充值金额有多大(图中最大的气泡对应用户首次充值最集中的等级和愿意接受的充值金额),开发者可结合该模型数据引导用户首次付费,从而提高用户付费率。
此模型需要开发者调用以下接口:
recharge:上报用户在应用中进行支付充值的相关信息。
:调用该接口时,“level”字段为必填字段,表示用户在应用中的等级。

主要指标如下:

指标 说明
首次充值用户各等级段各金额段比例 每日统计首次在应用中充值的用户,显示各个等级段(例如1-10级),各个充值金额段(例如10-50Q币)的用户比例。


此模型的概览图示例如下:
CBA_24.PNG

万人商业价值

此模型通过对每月新注册的用户进行跟踪,统计每一万个用户所贡献的商业价值总额,即每一万个用户的消费总额。
此模型需要开发者调用以下接口:
register:上报用户主动注册应用时的相关信息。
consume:上报用户在应用中进行支付消费的相关信息。

主要指标如下:

指标 说明
万人商业价值 每月到统计截止点时,跟踪的用户中,每一万个用户在最近一个月所贡献的商业价值总额。


此模型的概览图示例如下:
CBA_25.PNG

以上信息是否解决您的问题?

Copyright © 1998 - 2017 Tencent. All Rights Reserved.

腾讯公司 版权所有

有问必答 返回顶部