app开发者平台在数字化时代的重要性与发展趋势解析
1861
2022-11-01
本文目录一览:
埋点实施应该注意些什么呢?
埋点实施
下图为一个资讯行业的事件埋点模版,可以参照这个模板去进行梳理并提交给技术。友盟+ 开发者数据银行产品中的智能采集平台就可以按照这个模板,直接帮我们生成对应的埋点方案,并协助我们进行后续的事件管理。
市场上主流支持的四种埋点方式,分别是 代码埋点、服务端埋点、可视化埋点和全埋点。
代码埋点: 支持事件与参数这种结构化的使用方式,弊端是想增加或修改事件,都需要重新发版,用户更新后才能采集。 服务端埋点 :通常用于业务数据的采集,例如:付费成功、用户注册等,这个场景会选择用服务埋点进行采集。 可视化埋点和全埋点 :都是解决整个App前端操作的一些点击行为,例如说某些按钮、页面,每一个点击都能监测。但差异点在于可视化埋点只能看到圈定后的数据,那么全埋点则是在圈定时,历史数据也能去追溯。但这两个埋点的弊端是散点采集,每一个点击行为都是一个事件,在数据分析时,事件的量级会较大,不易于分析,而且它只能是取这种点击行为的事件,并不能把参数带过来,你可以理解为它就是一个纯扁平化的一个事件采集。
针对需求的不同,数据采集方式应该是结合使用的,以友盟+为例,友盟+现在支持两种埋点方式,代码埋点和可视化埋点,开发者可以结合使用,去满足事件方案的采集需求。
埋点验证
埋点后可通过三种方式验证:
打印日志,开启debug去打印Log,去验证触发事件log是否有上报,这种方式需要技术来配合验证 集成测试,以友盟+为例,只需要让技术注册一个测试设备,就可在你这个测试设备上去启用你的App,在去触发事件,产品、运营的同学就可直接测试埋点情况。 也可以使用市场上智能验证的工具,以友盟+为例,可先注册设备,自动去识别整个埋点的情况,且日志是实时的,可产出事件的验证报告。
智能验证,可以帮您智能验证这些事件的点是否采集了,是否有遗漏,最后会定期给出体检报告,详细的明细都会有。在友盟+的智能采集页面就可以智能验证埋点,只需要注册一个测试设备,这个测试设备填加完之后会实时把客户这些埋点的数据进行验证,到底是成功还是异常,以及测试的时间是什么都会有详细的数据。
综上所述:一个公司的埋点要可见、可控、可管,如果一家公司不清楚自己的埋点结构,便是在错误的数据上长期持续经营业务,越走越错。合理的埋点方案,可以使埋点能够智能调试和验证,大幅降低埋点采集的成本,从而最终达成数据质量的根本性提升。
一. 埋点还是埋雷?数据埋点的五大“坑”
在接触过上百家头部客户中,诊断和参与了数百次的数据体系搭建工作。几乎80%的开发者都没有科学的埋点规划,只采集显性数据,而更深层的与事件、参数相关的隐性数据,都没有采集到。埋点规划并不难!但为什么大部分企业都做的不太好?埋点规划需要整合产品、运营、技术和业务等跨部门的需求,运营同学不太懂技术、技术同学不太懂业务、产品同学不太懂埋点。
埋点的常见的问题有那些呢?
遗漏 :指的是埋点采集不全面,有可能重要的数据并没有采集到,会对数据分析造成比较直接的影响,出现这个问题的原因是前期数据分析需求不清晰。
杂乱 :前期并没有进行事件结构化的设计,想一出是一出。通常是想到一个需求,就把这个需求提供给技术进行埋点。例如:某一个位置或者某一个功能的点击行为,就当做一个事件进行采集,看上去采集和查看很容易,但随着时间跟需求的增加,当采集了大量零散的事件之后,需要在统计工具中通过分组分析时,就会比较麻烦。
低效: 在事件设计的时候,会去做结构化处理。但事件设计的参数逻辑会有问题,通常都是以大的页面这种框架的思维去进行设计。举个例子:部分客户在设计时,会按照页面的思路去进行事件采集,当产品结构产生变化时,原有事件调整概率会比较大,因为之前都是按页面结构去设计,页面的调整直接影响事件采集。
无用 :指的是数据虽然采集了,但分析时根本用不上,这个问题主要有2个原因导致,一是前期需求不太清晰,另一个是之前的采集需求都是由不同人提出的,由于中间人员变动,很多采集需求就不清楚了,并且也不敢下掉,因为并不清楚这个事件是否还有人使用。
复用: 指的是事件重复采集,或者是需求重复,这个同样是与多个人提需求有关,并没有一个人去做整合管理,或者是说,没有一个工具去帮忙我们做管理。
如果想要避免这些坑,就需要坚守五个原则:
需求清晰 合理设计 实施规范 结果可验 规范管理
移动互联网时代,无论是Android、iOS还是小程序,都有很多成熟的解决方案,无需花费很多的时间去处理埋点的事情,而且基于第三方提供的SDK进行埋点,在数据处理和分析上也有很大的优势。
但是在之前的PC互联网时代,除了网页端有百度统计、谷歌分析等,客户端的埋点似乎没有一套能拿出来可供大家讨论的解决方案,我就基于我的工作经验和理解,给大家分享一下PC客户端的埋点。
PC客户端的埋点
首先,在PC上,我们得知道我们需要统计些什么内容。
一个PC客户端,无论是工具类的还是内容类的,我们都希望知道我们提供的服务的效果。那么,我们从一个客户端安装、运行到最终被卸载来看看。
就拿产品使用较多的工具“Axure RP”来举例吧。如果“Axure RP”是我们自己的软件,首先我们需要知道被安装了,之后,我们关注激活情况,也就是使用,到最后,被卸载了,这一整个环节,构成了一个生命周期。 重点来了,对于这个生命周期,所有你想知道的关于“Axure RP”的情况你都可以统计到。
1.软件的安装
在PC客户端安装的过程中,流程一般是这样的:①运行安装包②弹出安装界面提供给用户操作③执行安装过程-写注册表、启动项、计划任务等④执行安装过程-创建安装的文件夹(③和④可以交换)。
在这个环节,我们一般需要知道:
安装包被运行了
在安装界面用户做了哪些操作
我们的安装过程是否正常执行
我们最终是否安装成功
在PC上,只要我们的安装包运行起来了,无论是弹出安装界面、写注册表还是创建文件,这些都是安装包可以控制的,所以我们能通过安装包进程,将整个安装环节的所有数据记录下来发送到我们的后台并记录下来 (这里要重点记住,由于安装是一次性的动作,所以统计一定要发实时的) 。
2.软件的使用
软件的使用,包括启动软件、使用功能和退出软件。
在PC上,软件的启动有很多种方式,例如开机自启动、计划任务、手动点击快捷方式,我们继续以“Axure RP”举例,当我们装上了“Axure RP”后,会在桌面、开始菜单中,创建快捷方式(有些程序会在任务栏上也创建),同时,会将后缀名为“rp”的文件默认打开方式调整为“Axure RP”。
对于启动, 我们就有了三种方式:桌面快捷方式、开始菜单快捷方式和默认软件打开,所以我们需要统计软件是否被启动了,是如何启动的。
对于使用功能, 当软件运行起来后,其进程就会启动,这个时候就跟移动端的应用类似,我们需要统计一系列事件,每个功能的使用情况、功能状态、付费、登录等一系列信息(区别于移动端的是,在PC上一般这些统计都是做单点统计,例如统计弹窗的弹出、功能的点击、某个状态,对于相互关联的一组事件统计是比较复杂的,需要定义结构体,在一条统计中包含很多组字段信息,因为没有成熟的SDK集成,所以基本都要自己定义埋点,复用性较差)。
这部分统计分为公共统计和专用统计。公共统计就是基本信息,常用的是用户标识、用户基本信息、计算机硬件信息和其他的可复用的;专用统计就是针对你的功能,你想了解哪些情况,针对性进行埋点统计。
对于软件退出, 这就比较简单了,是正常退出还是异常退出?软件使用了多久退出?
3.软件的卸载
软件卸载的流程包括启动卸载程序、用户操作、删除注册表及文件等操作、完成卸载。
在这个过程中,我们主要关注两方面的信息,一方面是用户怎么卸载的?是主动使用卸载程序,还是通过一些管理软件进行卸载;另一方面是用户为什么要卸载,这个时候我们可以在卸载的界面中给用户提供选择,以获取用户的反馈。
该怎么埋点
1.埋点的分类
(1)时效性
PC客户端一般情况下都比较复杂,子功能很多,可统计的内容很多,为了节省带宽,我们不可能每次都实时将数据传输回来,而且很多时效性不是很强的功能没有必要实时上报。
实时统计
当功能触发时或达到一定条件,立即将统计回传,一般情况下用于时效性比较强的功能,例如活跃统计、营收类统计,我们需要实时分析并调整策略。
延时统计
统计不立即回传,将统计积累,达到一定的条件或者一定的时间,统一将这部分统计回传,一般情况用于时效性不强的功能,例如采集设备信息、获取某些功能的状态、常规功能的统计,这部分统计使用范围比较广,一般都是隔日发送,有一天的延迟,统计的信息晚一天不会对分析产生较大的影响。
(2)埋点的作用
常规的基础统计
每次统计都需要发送,可以理解为公用统计,这部分统计是将几乎所有的统计都需要的部分包括进来,封装成一个统一的部分,每次发送统计都会带上这些内容,方便管理,节省后续埋点时间。
功能统计
针对特定功能,当功能被使用或者生效的时候,我们需要统计效果或者状态,可以理解为专用统计,不同于移动端,PC一般没有第三方提供的SDK,需要每个专用统计自己埋点,维护大量的统计内容,不过在一个公司内部,可以统一设计规范,方便维护。
(3)数据类型
结构体
统计连贯的事件,各项信息之间的关联很重要。
计数
统计某个行为发生的次数。
字符串
统计内容。
整形
统计数值,也可用来统计状态。
布尔型
统计需要判断的类型,一般使用场景较少,为了方便计算,大部分被整形和字符串替代。
2.数据埋点实例
(1)软件安装
场景:统计安装过程中的信息
(2)软件的使用
场景:软件启动后,用户使用了分享功能,将自己做的原型分享到了云端,最后用户关闭了软件。
要注意的是,软件启动和关闭,看需要是可以调整的,如果你只是想知道是不是启动了,来判断活跃,那么仅仅需要启动的时候发送个整型的值标识即可;如果想知道更详细的信息,比如启动方式、启动时间等等,可以定义结构体,将这一刻更多的信息发送回来,可灵活定义。
(3)软件卸载
卸载跟软件安装类似,这里就不赘述了。
在这里,如果希望收集用户的卸载原因,可以定义一个字符串,将用户填写的内容上报,这种形式的数据如果太多,不太利于分析,所以看产品情况可灵活设置。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~