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

产品汪天天都在和数据打交道，你知道数据来自哪里吗？

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

 

埋点类型

根据埋点方式，能够区分为：

1. 手动埋点
2. 半自动埋点
3. 全自动埋点

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

上报方式：

1. 客户端上报
2. 服务端上报

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

客户端上报埋点数据流转以下图：

（客户端上报埋点数据流转）

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

 

端数据

因为不一样端的用户具备不一样用户特征，每每会有不一样的作功点，所以，采集数据时须要区分端数据，能够经过app_id区分产品不一样端，如iOS、Android、iPad、PC各端。

 

埋点事件

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

(埋点文档示例)

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

 

事件字段

以资讯app（现在日头条、腾讯新闻、网易新闻）为例，按漏斗思惟和用户的行为路径拆解，有哪些数据可能须要获取？

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

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

根据行为属性，埋点事件大体分为如下几类，并不惟一：

埋点事件下的信息怎么看？如item_id:”114774”，冒号前是字段（key），冒号后是值（value），//后的是注释。

以视频浏览事件（_vdE）为例：

字段注意点和应用场景：

1. item_id：内容id，易错传为序列id
2. type：内容类型，如图文、视频、音频，可区份内容类型做分析
3. referer_id：上一页面内容id，可用于相关推荐业务的分析
4. _pt/_pi/_pm系列：定位页面和模块，可用于不一样业务线的分析，例如首页、要问频道、正文页等
5. _pre_系列：追踪了上一级页面，可用于用户行为路径分析

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

1. 页面退出（销毁）时：点击返回等
2. 切换到其余视频：点击上下集，点击相关视频等
3. 按home键退出时
4. 锁屏时
5. app杀死时

以刷新事件（_fsE）为例：

1. direction：可供产品汪区分上拉、下拉做刷新行为的分析。你可能会发现，除自动刷新外，大部分用后喜欢上拉刷新，但下拉刷新的广告位更值钱（有问题存在就有工做要作了）。
2. auto_type：在新session，打开app到达首页会有一次自动刷新（即用户没有手动操做），可用于分析用户主动刷新的行为。

以评论事件（_cmE）为例：

从以上埋点，咱们能获取哪些数据？

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

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

 

五花八门的用户id

用户id是用户的惟一标识，是该用户在应用里活动的“身份证”，但它在获取的时候但是五花八门的，曾经某产品汪提供的deviceid和数据分析师手上的uuid彻底对不上，ab实验得重作，因此懂多点儿概念提早问一问准没错。

（用户id获取示例）

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

1. IDFA（广告标识符，Advertising Identifier），是苹果公司提供的用于追踪用户的广告ID，同一手机的不一样APP对应着相同的IDFA，IDFA可经过如下步骤重置：设置-隐私-广告-还原广告标识符。由于IDFA会存在取不到的状况，所以须要选用其余的ID做为DeviceID。在取不到IDFA的状况下，选用IDFV。
2. IDFV（Vindor标示符，IdentifierForVendor），通常用于追踪用户在应用内的行为，每一个设备在所属同一个Vender的应用里值是相同的。若是用户删掉了该vender的全部APP，IDFV将会被重置。
3. 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：过滤刷新事件中单个用户天天几千几万次刷新的异常数据。

 

埋点注意点

1. 埋点问题需跟版本修复，bug修复周期长：手动埋点若是出现漏埋或埋错的状况，必须依赖下一个版本发版，才能看到数据（发版还需时间覆盖，很伤），想周全+多测试=高效率
2. 定义明确，格式规范，正确上报
3. 测试环节很重要（老生常谈）

 

平常反馈bug姿式

产品汪反馈bug是屡见不鲜，甩个bug截图可能会被忙碌精分的开发直接无视，掌握反馈bug的正确姿式：

1. 截图
2. 提供本身的app帐号或手机信息
3. Android：提供imei（手机数入*#06#可自助查询）
4. iOS：提供idfa（抓包查询）
5. 说明时间和场景，给开发补充上下文，方便定位问题

走上述流程，开发必定以为你可爱无比。

 

结语

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