摘要：
本文作者从工作实践出发，梳理总结了关于数据埋点的相关基本知识，与大家分享。产品汪每天都在和数据打交道，你知道数据来自哪里吗？移动app端内的用户行为数据大多来自埋点... 本文作者从工作实践出发，梳理总结了关于数据埋点的相关基本知识，与大家分享。
产品汪每天都在和数据打交道，你知道数据来自哪里吗？
移动app端内的用户行为数据大多来自埋点，了解一些埋点知识，能和数据分析师、技术侃大山，参与到前期的数据采集，更重要是让最终的埋点数据能为我所用，否则可怜巴巴等上几个月是常有的事。
埋点类型
根据埋点方式，可以区分为：
手动埋点半自动埋点全自动埋点
秉承“任何事物都有两面性”的道理：自动程度高的，能解决通用统计，便于统一化管理，但个性化定制需求难满足，成本较低；偏手动的，能满足个性化需求，但容易出错和疏漏，成本较高。
上报方式：
客户端上报服务端上报
客户端能记录一些通用页面PV、UV、点击等信息，但更多细节无法覆盖，用户购买了什么、订单金额、成交单数，用户看了哪个视频、视频物理时长是多少等信息则需要服务端回传，服务端上报有上线灵活、不随版本、丢失率较低的优点。
客户端上报埋点数据流转如下图：
（客户端上报埋点数据流转）
埋点在个性化推荐系统（详见下一篇推送）中扮演着先头兵的角色，采集的数据的准确性将直接影响策略方向。
端数据
由于不同端的用户具有不同用户特征，往往会有不同的做功点，因此，采集数据时需要区分端数据，可以通过app_id区分产品不同端，如iOS、Android、iPad、PC各端。
埋点事件
如果作为数据分析师，思考角度较高，输出的埋点需要有“可扩展、可维护、易用性、高效性”，字少事大的典型。产品汪可降低要求，只要能看懂埋点文档，正确提出埋点需求、知道哪些数据对应哪些埋点即可。
(埋点文档示例)
根据场景，同一属性的行为往往会归为同一类埋点，成为“同一事件”，同一事件下会有相应的扩展字段来承接相关的细节信息。
事件字段
以资讯app（如今日头条、腾讯新闻、网易新闻）为例，按漏斗思维和用户的行为路径拆解，有哪些数据可能需要获取？
打开APP人数（客户端登录损耗）->首页/栏目访问人数（访问占比）->刷新或点击人数（刷新或点击人数占比）->点击人数（点击率）->阅读时长/停留时长（读完率、阅读进度）->跟帖/收藏/分享等互动行为（互动率）->回流人数（回流率、病毒传播系数）
以上环节怎么对应上埋点？
根据行为属性，埋点事件大致分为以下几类，并不唯一：
埋点事件下的信息怎么看？如item_id:”114774”，冒号前是字段（key），冒号后是值（value），//后的是注释。
以视频浏览事件（_vdE）为例：
字段注意点和应用场景：
item_id：内容id，易错传为序列idtype：内容类型，如图文、视频、音频，可区分内容类型作分析referer_id：上一页面内容id，可用于相关推荐业务的分析_pt/_pi/_pm系列：定位页面和模块，可用于不同业务线的分析，例如首页、要问频道、正文页等_pre_系列：追踪了上一级页面，可用于用户行为路径分析
除了关注字段的定义和场景外，还需留意上报时机，定义尽可能周全，就以此视频浏览事件为例：
页面退出（销毁）时：点击返回等切换到其他视频：点击上下集，点击相关视频等按home键退出时锁屏时app杀死时
以刷新事件（_fsE）为例：
direction：可供产品汪区分上拉、下拉作刷新行为的分析。你可能会发现，除自动刷新外，大部分用后喜欢上拉刷新，但下拉刷新的广告位更值钱（有问题存在就有工作要做了）。auto_type：在新session，打开app到达首页会有一次自动刷新（即用户没有手动操作），可用于分析用户主动刷新的行为。
