产品经理不可不知的6种埋点策略

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

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

通常,埋点是研发的事儿,前端或者后端埋点。而数据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),会比较少犯错误,实际上也确实是这样。

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

你可能感兴趣的:(产品经理不可不知的6种埋点策略)