快好知 kuaihz订阅观点

 

关于数据埋点,你需要了解这些基本知识

本文作者从工作实践出发,梳理总结了关于数据埋点的相关基本知识,与大家分享。

产品汪每天都在和数据打交道,你知道数据来自哪里吗?

移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。

埋点类型

根据埋点方式,可以区分为:

手动埋点

半自动埋点

全自动埋点

秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定制需求难满足,成本较低;偏手动的,能满足个性化需求,但容易出错和疏漏,成本较高。

上报方式:

客户端上报

服务端上报

客户端能记录一些通用页面PV、UV、点击等信息,但更多细节无法覆盖,用户购买了什么、订单金额、成交单数,用户看了哪个视频、视频物理时长是多少等信息则需要服务端回传,服务端上报有上线灵活、不随版本、丢失率较低的优点。

客户端上报埋点数据流转如下图:

(客户端上报埋点数据流转)

埋点在个性化推荐系统(详见下一篇推送)中扮演着先头兵的角色,采集的数据的准确性将直接影响策略方向。

端数据

由于不同端的用户具有不同用户特征,往往会有不同的做功点,因此,采集数据时需要区分端数据,可以通过app_id区分产品不同端,如iOS、Android、iPad、PC各端。

埋点事件

如果作为数据分析师,思考角度较高,输出的埋点需要有“可扩展、可维护、易用性、高效性”,字少事大的典型。产品汪可降低要求,只要能看懂埋点文档,正确提出埋点需求、知道哪些数据对应哪些埋点即可。

(埋点文档示例)

根据场景,同一属性的行为往往会归为同一类埋点,成为“同一事件”,同一事件下会有相应的扩展字段来承接相关的细节信息。

事件字段

以资讯app(如今日头条、腾讯新闻、网易新闻)为例,按漏斗思维和用户的行为路径拆解,有哪些数据可能需要获取?

打开APP人数(客户端登录损耗)->首页/栏目访问人数(访问占比)->刷新或点击人数(刷新或点击人数占比)->点击人数(点击率)->阅读时长/停留时长(读完率、阅读进度)->跟帖/收藏/分享等互动行为(互动率)->回流人数(回流率、病毒传播系数)

以上环节怎么对应上埋点?

根据行为属性,埋点事件大致分为以下几类,并不唯一:

埋点事件下的信息怎么看?如item_id:”114774”,冒号前是字段(key),冒号后是值(value),//后的是注释。

以视频浏览事件(_vdE)为例:

字段注意点和应用场景:

item_id:内容id,易错传为序列id

type:内容类型,如图文、视频、音频,可区分内容类型作分析

referer_id:上一页面内容id,可用于相关推荐业务的分析

_pt/_pi/_pm系列:定位页面和模块,可用于不同业务线的分析,例如首页、要问频道、正文页等

_pre_系列:追踪了上一级页面,可用于用户行为路径分析

除了关注字段的定义和场景外,还需留意上报时机,定义尽可能周全,就以此视频浏览事件为例:

页面退出(销毁)时:点击返回等

切换到其他视频:点击上下集,点击相关视频等

按home键退出时

锁屏时

app杀死时

以刷新事件(_fsE)为例:

direction:可供产品汪区分上拉、下拉作刷新行为的分析。你可能会发现,除自动刷新外,大部分用后喜欢上拉刷新,但下拉刷新的广告位更值钱(有问题存在就有工作要做了)。

auto_type:在新session,打开app到达首页会有一次自动刷新(即用户没有手动操作),可用于分析用户主动刷新的行为。

以评论事件(_cmE)为例:

从以上埋点,我们能获取哪些数据?

每篇内容的评论数,可区分内容类型、栏目、评论类型、位置;结合获取到的用户id,还可以从用户维度分析。

以上埋点字段仅做示例说明,需要根据实际的数据需要来增删字段,定义要明确,场景要详尽,避免出现“想要分析次均阅读进度,却发现没有相关字段”的窘境。

五花八门的用户id

用户id是用户的唯一标识,是该用户在应用里活动的“身份证”,但它在获取的时候可是五花八门的,曾经某产品汪提供的deviceid和数据分析师手上的uuid完全对不上,ab实验得重做,所以懂多点儿概念提前问一问准没错。

用户id获取示例)

以iOS系统的用户id获取为例,先补充几个概念。

IDFA(广告标识符,Advertising Identifier),是苹果公司提供的用于追踪用户的广告ID,同一手机的不同APP对应着相同的IDFA,IDFA可通过以下步骤重置:设置-隐私-广告-还原广告标识符。因为IDFA会存在取不到的情况,因此需要选用其他的ID作为DeviceID。在取不到IDFA的情况下,选用IDFV。

IDFV(Vindor标示符,IdentifierForVendor),一般用于追踪用户在应用内的行为,每个设备在所属同一个Vender的应用里值是相同的。如果用户删掉了该vender的所有APP,IDFV将会被重置。

UUID(通用唯一标识码,Universally Unique Identifier),通用唯一识别码,每次生成均不一样;第1次生成后UUID后,需要保存到钥匙串(keyChain)中;应用被删除再重装时,仍然可以从钥匙串得取到UUID;在一台设备上,同一个开发者账号的所有APP,可获取到相同的UDID;刷机或者重新安装系统后,UUID将重新生成。

鉴于没有任何一种标识符能百分百准确获取,且为了尽可能获取用户id,会有一个退而求其次的获取逻辑,即先取IDFA的值,取不到IDFA时去取IDFV的值,再取不到时IDFA时,则生成UUID。

获取用户id逻辑示例:

iOS:先取user-DA;如果user-DA为空或者为00000000-0000-0000-0000-000000000000,取user-DV;如果user-DV为空,取deviceid

Android:先取imei;如果imei为空或者为02:00:00:00:00:00,取deviceid

埋点踩过的坑

字段和值

id字段指内容id,错传序列id,导致无法读取用户浏览的内容,丢失用户阅读历史(影响个性化推荐)。

当内容是合集时,item_id传合集id还是主视频id需提前定义

上报时机

需明确定义,如:不同端的文章浏览事件切换前后台时的上报时机需统一,Android切前后台都上报,iOS仅切前台时上报,导致两端的人均阅读数差异大。

需正确上报,如:视频浏览事件出现同一个用户的同一条数据重复上报(事件、时间戳、用户id等都相同),使统计的浏览量偏大。

统计

栗子1:过滤浏览事件中时长>=10 ms 和     时长<10000000 ms 的异常数据。

栗子2:过滤刷新事件中单个用户每天几千几万次刷新的异常数据。

埋点注意点

埋点问题需跟版本修复,bug修复周期长:手动埋点如果出现漏埋或埋错的情况,必须依赖下一个版本发版,才能看到数据(发版还需时间覆盖,很伤),想周全+多测试=高效率

定义明确,格式规范,正确上报

测试环节很重要(老生常谈)

日常反馈bug姿势

产品汪反馈bug是家常便饭,甩个bug截图可能会被忙碌精分的开发直接无视,掌握反馈bug的正确姿势:

截图

提供自己的app账号或手机信息

Android:提供imei(手机数入*#06#可自助查询)

iOS:提供idfa(抓包查询)

说明时间和场景,给开发补充上下文,方便定位问题

走上述流程,开发一定觉得你可爱无比。

结语

只要产品仍在迭代,就需要更新埋点以供数据分析使用,可以说埋点将伴随产品终生,携手埋点,头发也将越来越少,且行且珍惜。

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:基本知识  基本知识词条  这些  这些词条  了解  了解词条  需要  需要词条  数据  数据词条