数据产品经理，或者数据分析师，亦或者其他产品同学，运营同学，一定离不开数据分析。而数据分析的基础，那就是数据。

互联网产品的数据主要途径为埋点和爬虫。爬虫目的一般为获取竞争对手的数据，埋点的目的一般为理解自身数据。以后我们介绍爬虫，这里，主要介绍埋点。

通常，埋点是研发的事儿，前端或者后端埋点。而数据PM或者数据分析师是拿现成的数据来写SQL、完成分析。

但是，一名优秀的数据分析师或者数据产品经理，可以根据埋点的质量来决定怎么使用埋点，在什么情况下用什么埋点数据会更贴近事实，从而在面对别人的质疑时，可以很自信地说你给出的数据是现阶段最可靠的，你的数据无可辩驳。

数据PM或者数据分析师，以及其他优秀的同学们，不会抱怨埋点质量差而影响了自己分析，反而应该想，我如何用好现有的埋点来找到最贴近事实的数据来支持我的结论，埋点质量在不断改进，但我不会等埋点。要永远敢于给出结论。（当然，很多PM，其实是不知道埋点竟然还有好处之分？）

我们一个一个介绍一下，不同的埋点策略是如何实现的。

从埋点解决的问题不同，大概可以将其分为utm来源埋点、页面PV埋点、单击埋点native、单击埋点hybrid、业务埋点、曝光埋点。

utm来源埋点

当网站在吸引外部流量的过程中，如何评判从不同渠道跳转过来的流量效率？

我们举个例子，这个埋点，最早是Google Analytics，也就是GA，这一套埋点引申而来，埋在客户端。举例说明，从baidu.com搜索“booking”后单击第一个链接跳转后的url：https://www.booking.com/?aid=334565;label=baidu-brand-list1&utm_source=baidu&utm_medium=brandzone&utm_campaign=title。

其中：

·aid=334565是alliance id的简称，一般是企业内部对外投渠道的自定义编码，一般在自建的外放管理平台申请，设置跳转url来管理渠道。这里的334565是booking对baidu.com的渠道编码。如果和百度合作紧密，一个aid下面还有多个子id来区分和百度不同事业部的结算，比如百度地图、百度搜索、百度糯米等。但这里没有记录。

·utm_source=baidu指来源为baidu。

·utm_medium=brandzone指来源于百度的品牌专区。

·utm_compaign=title一般是活动类型，这里是代表直接搜索“booking”过来的流量。

这种埋点，一般是市场部申请好id，拿到url直接给流量方的对接人即可，不需要本公司开发资源介入。这个埋点，可以记录每个流量来源的投入产出ROI，这个产出可以是注册量，也可以是下单量或其他。流量主流结算方式是单击付费CPC，对于引流的价值需要在合理的区间才有长期合作的必要。

页面埋点

当我们想知道，每个页面的访问情况如何？停留时间是多少？就可以用到页面PV埋点了。产品经理一般只要把这个需求给到研发，让研发自己做就可以了。

页面埋点主要应用在如下两个方面：

·当作数据的基准（benchmark）。因为页面埋点格式最为简单，且触发逻辑简单，开发出错的概率最低，所以一般将其作为正常数据的基础。在通常情况下，各个埋点的数据是对不上的，需要找出一个基准，那这个页面埋点最靠谱，其他的如果偏离很大，就需要查找bug。

·通过触发时间差来计算页面停留时间。一般不会单独对页面停留时间埋点，因为正常情况下，下个页面和本页面的埋点触发时间差即为本页面的停留时间。而且为避免异常值干扰，停留时间在计算时一般取中位数，而非平均值。

这个埋点，一般能够包括以下字段包括：

·页面UV：按日对设备号去重。

·页面PV：计算访问次数。

·退出次数：计算从该页面离开网站的次数，用来衡量该页面的质量。

·退出率：退出次数/页面PV。

·页面停留时长：下一页面时间与本页面时间之差，一般取中位数。

这里，我们再聊一下，客户端和服务端埋点的区别，也就是前端埋点和后端埋点的区别。

一般情况下，页面PV和单击等跟用户交互的信息是放在客户端埋点，但也有公司将PV放在服务端埋点。两者的区别在于：客户端埋点一般为页面加载完成/离开的场景触发一次（刷新/回退可能都会PV+1），但是服务端是根据服务的次数来计算PV，如果一个页面是分批加载（另一种情况是，现在很多Hybrid是一个页面预加载，减少页面加载时的用户等待时间），那按照客户端来计算的1个PV，按服务次数来算可能是多个PV，在跨部门对比数据的时候需要和对方沟通清楚这些指标。你们是埋在哪里的，怎么定义的。

单击埋点native和hybrid

下面将区分native和hyrbid，虽然两者解决的业务问题类似，但方法上有较大不同。

我们先说说，单击埋点native.

比如，新的模块/功能上线后效果如何？有多少人单击这个位置？单击之后的转化率如何？下一步应该如何改进？这时候，就需要用到单击埋点native了。如果只是统计button的单击次数，开发就可以搞定，但如果是在此之外的内容，就需要产品经理在PRD中写明。比如电商中列表页常见的筛选button功能，如果只是筛选button的单击，可以计算“c_filter”的单击，但是如果想知道用户搜索过的内容，比如你有一个搜索框，你想知道用户搜索过什么内容，就需要在扩展字段中记录内容，而这些内容需要产品经理来指明。告诉研发，我要这个东西。

单击埋点native，主要应用在如下两个方面：

·按钮的单击情况。每个按钮的单击UV和单击次数PV。这里需要注意，单看按钮的单击次数的绝对值是没有意义的，需要跟其他按钮比是相对多还是相对少，以及这个按钮的设计初衷是希望用户多点还是少点，这个需要根据不同场景来确定。

·按钮之后的操作行为。更多情况下，产品经理想了解用户在经过这个按钮单击之后的行为和转化率，以及这个按钮有没有加速用户的购物流程。

单击埋点hybrid

一般来讲，hybrid开发团队和native开发团队相对独立，编程语言也存在较大差异，支持的业务方也有区别。hybrid一般常用于快速迭代的页面，比如活动页和后服务页面等。一般这个埋点，需要产品经理和研发沟通好，要埋哪儿，以及埋点的难度如何等等。

以某电商后服务页面为例，这些页面的单击后评价，可能是跨平台的行为参考，比如说售后来电数量的下降，针对这样的场景如何埋点，与native又有何异同点？

区别有两个：

        ·一般直接取用显示的模块/单击名。因为改版非常频繁，有时候文字也会稍微变动，这时候再用英文可能很难直观体现区别（比如“退票”和“退订”很难用英文来区分，用拼音的话还不如直接用中文），有的改版可能就是在文案上做AB测试，所以这里直接记录中文。

        ·记录订单信息。因为一般后服务页面常常跟客户投诉、客户来电等KPI挂钩，页面功能的设计大多数是为了降低投诉、降低客户来电、减少客服人工成本，所以常有“单击退货按钮后当天用户电话咨询数量”的监测指标需求。那一般是通过订单信息来做这样的关联，所以这个json数组中一般都要包含订单号，其他视产品经理要求而增加。

通过这种埋点，主要给页面的频繁改版提供方向和计算ROI，因为产品经理的需求改动需要计算出合理的价值，而后服务的价值就是这个功能的上线可以减少客户的通话时间，减少多少用户的时间，提升体验，换算出来的价值后再和其他项目PK，依靠结果来争取上线机会。页面上线后评估效果是否符合预期，值得深入细化还是改变方向。这也是数据给产品迭代提供支持的有效例证。

业务埋点

业务埋点常常是因为业务需求而制作，记录业务相关埋点。这种埋点，一般都是产品经理提需求，BI出面制定规则、出方案，由开发执行。流程比较多，是因为这个埋点很复杂，所以需要多方面协商沟通好。

这个埋点有什么用呢？比如，我想知道每个单击之后的转化率，有没有可能把一个用户的每个单击信息都带到订单完成页？就是需要用到业务埋点了。

最主要的场景是利用该标志位细分人群，针对这些人群看一些指标以及针对性做些改进。比如说首页勾选婴儿的人可以理解为“携带儿童者”，转化率相比商务出行转化率如何，流程痛点在哪里，如何评判针对性改进的效果等，都可以利用这个标志位从开始到下单所有页面的转化情况，以及单击情况拎出来淡出分析，这是精细化运营和产品迭代的利器。

要注意的是，业务埋点与PV埋点的不一致。业务埋点一般是在用户离开页面的时候记录信息，理论上应该与页面的UV和PV是一致的，但因为该埋点本身比较复杂，且由于触发机制的问题，会存在5%左右的差距，但是一般这个埋点多用于计算细分人群的转化率，所以分子分母同时缺失对转化率计算是没有影响的。但如果说要单独计算UV和PV，需要考虑到这5%的差异（如果能推动开发查到问题所在，也可以消除这其中的差距，这当然是最好的解决方案）。

最后一个埋点，曝光埋点

曝光其实是控制流量的主要手段，原因是这样子的，对于产品来说，流量分配其实是曝光的分配。曝光埋点理论上与单击埋点可以放在一起，区别对待的考量是如果流量消耗太大，就会出现浪费。=

举个例子，对于app来说，无论是native还是hybrid，曝光是对所有展现内容进行记录并上传，而这些数据本来就是下载到手机端，再从手机端上传，从流量的角度看是非常大的浪费，所以曝光的埋点一般从服务端来埋，不走客户端。也因此，这个埋点，一定要PM和研发沟通好。

以OTA为例，最重要的场景是选择不同的产品排序，不同的产品排序，对整体转化率和利润的影响不同。对不同的供应商的产品进行包装后卖出，在不同的排位上转化率肯定不同，位置变动后此消彼长的转化率对整体的转化率的影响情况，以及对于整体利润的影响情况，这是核心关注指标。曝光埋点，辅之以各种AB Test就可以帮助业务方来做决策。

要记得一点就是，服务端埋点的PV和页面PV一般是对不上的，因为页面PV=1代表访问1次，而服务端PV=1代表页面服务被调用一次，如果一个页面调用多个服务，尤其是在分批加载的时候，两者是明显对不上的。理论上服务端埋点会比前面所述的客户端埋点（包括单击埋点和页面埋点）准确，因为相比客户端，服务端一般人数较少（不用区分是Android或是iOS），会比较少犯错误，实际上也确实是这样。

以上，就是平常会用到的埋点策略了，如果大家遇到更多的情况，我们也可以一起讨论。欢迎作为补充和交流。