关于小程序埋点 2018-05-18

小程序(小市集)新版上线,需要一些简单的埋点,下面是我这两天从各个论坛整理的前辈的资料,希望能对你有些用处。

一、如何判断产品需要埋点

1.为什么要埋点?你想要得到什么

先确定目标,想想你要这个数据干什么。因为不同的业务会对应不同的指标,如果想绘制基础的人群画像,就需要获取用户记性、网络类型、操作系统、IP地域等数据;如果想分析每一个注册的转化率,就需要获取每一个步骤的点击次数,然后制作成漏斗,看哪一步转化率出现了问题。目的不一样,获取的数据也不一样。

2.如果不埋点,有没有其他解决方案?

如果不埋点,是否可以从现有的数据库中查询到一些信息来进行判断。例如从注册量和订单量来粗略的判断订单转化率,缺点就是不知道用户中途是在哪里退出,无法精确定位问题,只能猜测着来优化产品了。

3.现有的统计工具是否能够满足?比如百度统计、谷歌统计、友盟、talkingdata。

(仅针对小程序)小程序目前还不能使用百度统计、谷歌统计、友盟、talkingdata这些主流统计工具,sad。

小程序的数据统计目前有小程序数据助手,访问人数、页面访问量、用户来源等都能统计的到;阿拉丁除了能显示小程序数据助手之外的数据,还可以追踪到某个页面的pv/uv,转发率,打开率,更有渠道二维码,添加后就可以看到这个二维码的pv和uv(颗粒度是人数/小时)。

4.无码埋点的性价比,比如growingio,可以直接迁入SDK就能埋点,性价比是否足够高?

对于小程序来说,好像没有无码埋点的工具。目前阿拉丁好像也不能完全做到无码埋点,但如果是简单的页面事件统计(点击按钮或者区域)就可以很简单的实现。


二、埋点的思路

埋点的思路,可以分成三大类,即“业务环节埋点”、“运营环节埋点”和“绩效环节埋点”。

什么是业务环节埋点?

比如,我是卖苹果的商贩。那么,我的核心流程当然是从果农手里买到苹果,摆到货架上出售,消费者挑选、付款等等。打通全流程,则要从种子种下的一颗开始,直到苹果被吃掉,甚至被排泄掉为止。

什么是运营环节埋点?

比如,还是卖苹果的例子。作为商贩的我,关心的不再是卖的苹果什么样,而是卖了多少钱、多少个、谁买的。管的是从我的本钱变成苹果的一刻开始,之后苹果被安排在货架上的某个位置,再之后苹果被消费者购买,直到收到钱的整个过程。此时苹果又变成了钱,然后货架上的每个位置也都有了自己的“金钱价值”。或许,还有一些苹果没等摆到货架上就被碰坏了,还没等卖出去就烂掉了;甚至还有人可耻的盗窃货架上的苹果。不管怎样,反正这些苹果占用的钱是回不来了。

什么是绩效环节埋点?

卖苹果是为了赚钱,养家糊口。那么按照“从本钱变成苹果再变成钱”为一个循环,每个循环赚了多少钱,在乘上循环了多少次,这就是我的盈利能力。细分下去,我这个店铺的循环,又是每个苹果的循环累加起来的。因此,每个苹果被我买来,以及被我卖掉,这些环节都会产生影响我的收入的数据指标。专有名词,叫做毛利率和资金周转率。

更重要的是,这三个埋点思路是相互嵌套的:上报运营数据,可以带上业务数据;而上报绩效数据,又可以带上业务数据和运营数据。

一个可以衡量的精细标准是:数据收集口径维度不应小于数据应用口径。如果对于“新增用户数”这样的指标,我们收集了“新增用户数/天”这样的数据,那么周、月、季度、年等指标也就迎刃而解。但是小时、分钟、秒这样的维度,是打死也算不出来准确值的,只能用除法均摊。


三、如何埋点

1.通常在哪些环节埋点?

产品数据分析的三个层次

对产品用户和行为数据的研究可以大致划分为宏观层、微观层和中间层三个层次:

宏观层:由一系列的数据指标构成。如产品每日的「活跃用户数」、「新增用户数」、「订单数量」、「点赞的次数和人数」、「次日或7日留存率」等,这些指标能够帮您从整体上把握产品的运营状况;

微观层:由产品中每个用户及其行为的细节数据构成。如每一个用户的年龄性别……、他在什么时间打开应用、做了什么、他的购物车里都有哪些商品等,这些数据可以让您去深入的了解和理解每一个用户以及用户的行为?

中间层:中间层由一系列相互关联的分析方法、模型以及相应的数据构成。如行为分析、漏斗、留存、细分、画像洞察等等。


2.主要分析方法、模型

漏斗模型:

指的是多个自定义时间按照一定顺序依次触发的流程中的量化转化模型。通常我们会对应用中的一些关键路径进行分析。比如注册流程、购物流程等。

以电商应用等购物流程为例:

1浏览商品 ->  2放入购物车 ->  3生成订单 ->  4支付订单 ->  5完成交易

计算事件/计数事件:

(1)计数事件:计数事件统计事件的发生次数、独立用户数、事件时长及各参数的发生次数、市场。

如登录、分享、下载等,是定性变量(categorical variable),对应的统计项是字符串类型。

(2)计算事件:支付金额、内容浏览数量等是连续变量,对应的统计项是树脂类型。开发者需要查看这些事件的数值分布特征,这就需要使用计算事件。


3.具体数据

一、页面统计

页面统计,可以统计应用内各个页面的访问次数(PV),访问设备数(UV)和访问时长,以及各页面之间的流向关系。

1.1 页面访问数

页面访问次数,即当前页面的被访问的次数,即浏览量PV;举例:首页,访问次数,1000次;

页面访问人数,即访问该页面的活跃用户数,即独立访问数UV;举例:首页,访问人数,100次;

1.2 页面访问时长

页面访问时长,用户在页面的停留时长,即首页受访时长的总和;举例:首页,访问总时长,2小时;

1.3页面流向分布

页面流向(走向)分布,可统计出,当前页面和下一个页面(有多个)的流向关系;

举例1:在“商品详情”这个页面中,可以进入“购买”、“收藏”、“返回列表”、共3个页面,即在“商品详情”页,可能的流向分布为:

其中,用户在该“商品详情”页面,没有进入对应的3个页面,即视为“离开应用”,在页面流向分布,有2个常见问题:

 问题一:页面流向分布中,仅有离开应用这一个指标?

造成这种情况的原因,可能有以下两点:

用户在该页面全部选择了离开用户(这种概率相对很小);

该页面的下一级页面,没有做埋点,导致所有的下一级页面都没有数据,其结果就是离开应用的占比为100%;

问题二:页面流向分布中,离开应用的占比非常高,达到了40%以上?

与问题一类似,如果没有为每个页面添加统计代码,会导致这些页面统计不到,那么跳转到这些未添加统计代码的页面,将会被视为离开应用。

备注:页面流向分布的计算方法

页面的统计数据中,会返回以下数据:当前页面名称,来源页面名称,当前页面访问次数;

举例2:参照举例1中的页面流向分布,假定的页面统计数字如下:

则,商品详情流向购买页面的占比为:在购买页面中,来源为商品详情的次数与商品详情总次数的比值,即20/100*100%=20%;

依次类推,可以分别计算出商品详情流向收藏、商品详情流向返回列表的占比;

离开应用的占比,即为1-(20+30+30)/100*100%=20%。

二、自定义事件统计

自定义事件,即记录用户的操作行为(如点击行为),记录用户操作行为中的具体细节;一般来说,通常所说的埋点,指的就是自定义事件。

埋点可以是某个按钮,某个点击区域,某个提示,甚至可以用来统计一些特定的代码是否被执行。在APP中,需要在代码中定义一个事件行为。

2.1简单事件统计

简单事件统计,即记录事件的发生次数(可理解为PV)和事件发生人数(可理解为UV)。

以下面的登录页为例:

其事件统计的结果为:

事件ID,即EventID,该名称可由程序员自行定义(按照APP统计平台,如友盟、talkingdata等提供的事件ID命名规范进行命名),将该事件ID写入需要跟踪的位置中即可。

事件名称,可以理解为事件ID的一个中文翻译名称,是为了方便运营人员查看,事件名称命名是在APP上线后,该事件ID有数据后的一个事后行为,通常是在APP数据平台中定义(如果你乐意,你可以把input_number这个事件ID的事件名称改为:用户在这里输入手机号)。事件名称只是事件ID在前端页面的一个显示名称。

事件发生次数,即该事件总共发生的次数;可以理解为,在每个事件中,都会有个事件ID计数器,每当该事件被触发时,事件数即加1;

事件发生人数,即该事件的发生人数(有些APP统计平台也称之为:达成该事件的用户数、独立用户数);参考事件发生次数,可以理解为,在每个事件中,都会有个事件ID计数器,每当该事件被触发时,同时记录下该用户的唯一标识,事件数即加1;事件发生人数,即根据用户唯一标识,对事件发生次数进行去重。

2.2事件转化漏斗

事件漏斗,即按照一定的事件顺序,依次统计各个事件之间的转化率,如我们可以对登录注册中的一些关键步骤进行事件漏斗分析,如输入手机号码,获取验证码、输入验证码等,以2.1中提到的登录过程为例,其漏斗可设置为:输入手机号码->获取验证码->输入验证码->点击登录按钮,即由4个事件组成的漏斗。

根据对应的事件数,即可计算出各个事件的转化率,如输入手机号码发生次数为5000次,获取验证码的次数为4000次,那么输入手机号码后点击获取验证码的转化率为4000/5000*100=80%。如下表所示:

2.3利用事件参数进行精确统计

为方便对相同类型的事件类型进行归类,在事件统计中,提供了事件标签(label)的方法;即相同类型的事件可以使用相同的事件ID和不同的事件label,通过事件ID+事件label的方式,指代一个特定的事件。

在进行事件统计时,为了为了统计一些特定的行为数据,如商品价格,商品类型等具体数据,提供了事件参数的方法,通过使用key-value的方式,记录该事件的详细记录。

事件ID、事件label、事件参数的关系,如下图所示:


举例,在一个购买行为中,运营人员想查看用户在整个购买流程的详细参数,那么可以通过以下的事件埋点方式进行埋点;在这个购买行为中,购买就是事件ID,浏览商品详情,收藏该商品,加入购物车等,就是一个一个的事件label;在浏览商品详情中,“商品类型:电子产品”,“商品价格:1-100元”……,等,就是一对一对的key-value值,如下图所示:

通过对商品价格的分析,可以统计得出,用户所选择的商品价格的分布情况。



©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,684评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,143评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,214评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,788评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,796评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,665评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,027评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,679评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,346评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,664评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,766评论 1 331
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,412评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,015评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,974评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,073评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,501评论 2 343

推荐阅读更多精彩内容