机票前台埋点的那些事儿

欢迎关注天善智能,我们是专注于商业智能BI,人工智能AI,大数据分析与挖掘领域的垂直社区,学习,问答、求职一站式搞定!

对商业智能BI、大数据分析挖掘、机器学习,python,R等数据领域感兴趣的同学加微信:tstoutiao,并注明消息来源,邀请你进入数据爱好者交流群,数据爱好者们都在这儿。

李宁 :著《数据化运营:系统方法与实践案例》书籍,现于某知名外卖订餐平台担任数据专家,先后于艾瑞、携程从事数据相关工作。

个人微信公众号数据自由之路(微信ID:dataFreeLife)

机票前台埋点的那些事儿_第1张图片

题记

数据分析师能力与埋点的进阶关系:

不懂埋点会根基不稳:一名数据人如果连埋点和指标模棱两可、则根基不稳,随口一反问都可能成为定时炸弹,坍塌整个分析过程。如果你认为埋点只是开发的问题,数据人是拿现成的数据来来写sql、完成分析,未来路可能会越走越窄。

根据埋点质量决定使用程度:我的理解,数据分析师,可以根据埋点的质量来决定怎么使用埋点,在什么情况下用什么埋点数据会更贴近事实,很自信地说“我给出的数据是现阶段最可靠的”,面对别人的质疑时,你的数据无可辩驳。

always敢于给出结论:数据分析师不是抱怨埋点质量差而影响了自己分析,而是应该想“我如何用好现有的埋点来找到最贴近事实的数据来支持我的结论,埋点质量在不断改进,但我不会等埋点。永远敢于给出结论。”

携程机票的埋点概况:

携程机票埋点随着业务复杂度的增加而在做加法,先后上的埋点包括ctm、action、trace、pv、服务端埋点等五个大类,每个埋点均符合其时代属性,但现在规整起来其相互间存在一定的交叉,即使冗余但有些埋点一部分还存在价值,转移起来造成的数据问题谁都不想背锅,所以埋点一直在做加法。直至在app减size的大趋势下,才顺便把无效的埋点做部分清理。

UBT是什么?全称User Behavior Tracking system,是由携程首席科学家叶亚明(Eric Ye,前携程CTO)先生发起的一套数据框架,最早从online的埋点落入和上传机制体系开始,逐步扩展至无线端app/hybrid/h5,后又增加abtest体系,现在支持携程的众多分析项目。包括数据埋点的格式、上送契约、落库、ETL以及最后的报表数据,是数据体系的总称,本文主要对于ubt体系在携程机票的埋点应用以及指标应用做说明。

客户端埋点分类:ctm,action,trace,pv。

/ 01 /

ctm埋点/客户端 

3901436-1b967e8fa858568a

类比GAのutm:玩过GA(Google Analytics)的童鞋对utm埋点肯定不陌生,它以get方式记录页面来源,被广泛使用营销活动的收益结算,Ctripのutm即为ctm,主要用于online和h5平台,不仅对落地页面的uv评估,同时需要根据规则计算其转化。因ctm只向后传递一次,未能直接关联创单(或者hybrid页面带到native页面面临中断)。

应用场景:以某业务类型页面(以下称为A页面)的效果评价为例,通常会根据同一天访问过A页面的设备号的会话中,下单时间在页面访问时间之后,记为间接订单;在此基础上限制访问该页面的业务结果、与订单对应(做些业务规则的筛选),记为直接订单。间接订单的含义是计算A页面影响的用户下单意愿的程度,而直接订单是计算直接从A页面下单的人。正常情况下都是以直接订单为主要指标,间接订单作为参考指标。

/ 02/

PV埋点/客户端

PV埋点因存在时间最久、埋点方式最简单(调用logpage方法发送pageid),所以被接受程度最高,同时也作为新上埋点验证丢失率的基石数据。app页面实现方式有native/hybrid/rn,其均申请独立pageid,对于计算页面性能影响不大(除了停留时间)。

报表合作机制:作为基础数据,新页面上线第二天就需要在基础报表UIP中查到(BI域数据T+1)。数据流为,新页面在上线之前开发童鞋会在公司的资源平台cms申请pageid,在页面加载的时候调用logpage接口上传pageid,行为数据经ETL落入hive库,经过清洗(去爬虫、去测试账号等),统计结果数据进入sqlserver,基础报表平台读取数据做汇总展示。其中筛选字段可以通过channelid来将机票页面区分。整个流程数据流不需要人工干预,完整的流程保证最小的人力和最快的效率。

3901436-71e440b6db1ea9c1

页面基础指标:在数据报表中每个页面维度会有UV、visits、PV、退出次数、页面停留时间。visits代表session/会话数,退出次数具体释义请参考百度。页面停留时间,是该页面与下一面的starttime之差,一般取中位数(屏蔽异常值)。

/ 03/

action点击埋点/客户端

点击埋点方式分不同平台,操作方式区别较大,按照native、hybrid、online顺序说明。

native:

埋点格式:为c_****,比如搜索页面是c_search,c代表click,后面为名称的英文简称,有开发人员自行定义。点击埋点的hive表内有pageid字段,命名时只要保证同一页面无重复名称即可。

埋点流程:app的native默认是有点击按钮即埋点,除非是pm特殊指定埋点附加信息(比如列表页记录筛选N次,但不记录筛选内容,如果需要记录筛选内容,需PM在PRD中说明)。因为native发布周期平均一个月,在之前曾遇到过重大问题没有及时解决因其领导高度重视,故决定今后所有点击一律埋点,逐步形成习惯。

报表合作数据流:这个报表暂时还没有上公司的cms系统,现在前台产品在维护其埋点简称和中文名称,由bi来调用,生成每天T+1的报表。后期考虑维护进入cms系统,像pv表一样进入全自动流程。

3901436-d77fa804051316bd

报表字段:点击的报表是计算点击量(PV)、点击用户量(UV)、页面用户量(页面UV),点击uv比(点击UV/页面UV),人均点击次数(点击pv/点击UV)。虽然指标很简单呢,但是如果是跨BU或跨公司来核对数据,需要对比计算标准,有的公司是采用客户端页面刷新来计入PV,有的是根据服务端(server)响应次数来计入PV,可能会有显著差别。

hybrid:

起源:hybrid埋点在2016年9月份以前并没有统一的埋点格式,不同的业务开发团队采用的js不完全相同,经过多方push统一一套,因speed处是点击名称,又俗称“speed”埋点。

报表合作机制:speed埋点因均为中文,所以不需要人工维护维表,bi对结果表进行distinct即可生成点击筛选框。但这需要开发在speed处不可添加变量字段,否则下拉列表将会是一个灾难。

应用场景:speed埋点包含订单信息,以hybrid某后服务页面(以下简称B页)为例,我们可以通过订单号信息将用户在B页面的行为和来电行为关联起来,如果用户在B页上点击某后服务操作(以下简称C)操作后当天来电,说明该按钮没有完全解决客户问题,可以在这个点上深挖需求,改进体验。在快速迭代页面的过程中,关注每个功能的点击后来电的比例,来深究每个页面细节,对于快速迭代、精细化数据运营非常有帮助。

面对的挑战:因每次上传内容较多,包含系统自带信息,比如设备型号、user-agent和报错埋点信息等,导致用户流量消耗较大,待逐步改进。

online:

online埋点采用比较节省流量的方式,即在页面离开(包括进入下一个页面和当前页面刷新)的时候,将页面上所有的点击信息以{点击名称:点击数量}的json格式发送,这样可以节省流量,但是对于orderid等的记录就会缺失,如果增加额外信息需要改变结构,有利有弊。

/ 04/

trace埋点/客户端

bi分析人员希望每个埋点都可以从开始带到创单,这样计算转化率就会比较方便;但开发认为每个页面埋点重复劳动、浪费时间和精力,而且有可能会影响页面加载速度。为了解决这个问题,推出了trace埋点,这个埋点的特点是每个主流程页面仅有一个,但将所有的业务信息记录在案。

埋点格式:每个主流程页面均有trace埋点,在页面加载或离开时发送,由bi统一管理,app/online/h5格式基本一致,所有trace修改都需要经过bi的审核,主流程页面包括首页、列表页、中间页、填写页、完成页。

应用场景:可以根据业务属性来区分具体人群的行为转化,故又称“业务埋点”。比如在首页勾选某项功能(以下简称D),通过这个D标识位可以看到带D购票意愿的细分人群在各个主流程页面间的转化(该标志位只有回到首页重新取消勾选的时候才会刷新这个标识位,否则都是从首页一直带下去)。这样对于细分人群的体验改进效果具有可观测性。

/ 05/

服务端埋点

缘起:机票OTA承担航司很多政策任务,会在列表及中间页通过标签的形式来给客户不同产品体验,但这些政策标签能够带来多少销量的提升,以及如何决定其之间的相互影响,成为一个课题。于是在服务端从列表页开始,将所有的显示报文埋点记录下来。

应用场景:对于所有产品可以根据政策维度和航司维度进行筛选,通过展示转化比来观测各个阶段的转化,同时对于后台对应的政策业务人员可以发送针对性报表,各取所需,节省大量时间。后期将利用机器学习方法针对不同政策、价格和排序的相互关系进行测算,希望找到最优转化的显示方式。

/ 06/

数据准确性の讨论

现状:公司的pv表的存在时间最久,而且埋点最简单,结构最稳定,所有的验证数据都是以pv表的数据为基准。经过验证下来,根据按天计算的uv数据,trace的埋点准确率在97%左右,服务端的埋点在103%左右。如果都是在同一类埋点的情况下计算转化率,分子分母是每个页面的uv,影响不大,但是跨埋点计算的时候,需要特别小心。在数量级明确之后,还存在数据格式的问题,尤其是string和int的转化,特殊字符造成的解析困难等,这些都需要在使用过程中不断验证,bi和开发相互磨合。

埋点的准确率受很多因素的影响,主要是不畅沟通带来的各方gap,最后体现在开发对埋点的重视程度不足。每个开发对于埋点的认识不同,对于埋点上送的逻辑也不尽相同,再加上心态不同可能导致结果也会差别很大。

常见埋点问题:

不该触发的时候而被触发:hybrid页面曾遇到过只要是手指划过按钮埋点就被触发,导致新页面上线后点击数据异常暴增,其实是开发在判断触发事件的阈值设置错误,停留时间超过200ms以上才算点击,小于200ms算滑动,但是在上面那个例子中开发未做限制,导致问题。

埋点触发相互抑制:在一个新埋点上线后,发现一个毫不相关的点击数据下降明显,从业务上找不到原因,后来开发查找代码的时候发现,两个埋点的上送逻辑存在ifelse关系,只有一个被上传。

开发与埋点不是同一人导致逻辑异常:这主要存在于开发交接时候对于埋点的上送逻辑一般不太重视,所以在业务发生变化的时候,并没有及时更改埋点的逻辑,比如pm希望某个默认埋点的默认显示被记录,最早是由服务端直接下发,客户端不做筛选,所以客户端买点直接读取服务端下发内容,但一段时间后默认逻辑在客户端加一层个性化接口,埋点方式还是直接读取服务端内容,未做更改,导致数据一直异常,经过好长时间的努力才定位问题。

部门开发和框架之间的冲突:有时候部门开发逻辑做的很完整,但是被框架的一些逻辑所限制,被背黑锅。比如为了优化速度,hybrid页面在本地app打包的过程中有些文件已经放入,在hybrid请求的时候,有些文件优先以本地为主,而公共框架部门做了一些拦截,但业务的开发可能就存在没考虑到这层逻辑,埋点数据就会全部丢失。

开发对埋点的误解:

问题:为什么每个页面都要埋这么多点,难道不能通过关联来实现吗?

回答:在开发本身的任务都很重的情况下,埋点相对次要,在不了解其意义的情况下,往往意愿不强,怨声载道。这就需要pm或者bi很清楚地知道哪些埋点数据一定要有,哪些是可有可无,同时在整个项目上的最终数据表现上跟开发童鞋分享数据,强化埋点的价值。另外对于开发童鞋本身比较关注的kpi,如页面性能埋点,包括报错信息、加载时间、白屏等,可以辅助其建立报表来增强对数据的关注度。

问题:为什么埋点动不动就要增加,能不能一次性提好?

回答:这是个历史性的难题,因为在分析问题的时候,维度在不断地细致化,而这些维度是在当初并没有想到的、或者说可能认为没有必要的埋点(没有必要的埋点不增加开发的工作量),但是问题发生之后就需要增加埋点,这也是需要与开发保持密切的沟通。

后记

上面介绍携程机票现存的主流埋点格式,是业务需求和开发复杂度之间的平衡,在携程机票的场景下有其存在的意义。但并不代表是全局最优,如果是有埋点需求的童鞋,可以在充分理解每种埋点的优劣势之后,结合场景来取精华去糟粕,这也是人和机器的区别。

共勉。

- END -

往期精彩

■ 如何理解马云演讲「十年后没有数据分析师的职业」

■ 用数据分析告诉你数据分析师能挣多少钱?

■ 月薪20K的数据分析师都在做什么?

■ 营销转数据,两年半到P7,我都做了哪些事儿?

■ 给30个PM拉了一年sql,我学到了什么

■P7数据分析的Offer,你准备好了吗?

■当谈到携程机票产品经理的数据意识,我们在谈什么?

■从拉勾网看数据分析师怎么变得值钱?

公众号后台回复关键词学习

回复 免费                获取免费课程

回复 直播                获取系列直播课

回复 Python           1小时破冰入门Python

回复 人工智能         从零入门人工智能

回复深度学习 手把手教你用Python深度学习

回复 机器学习 小白学数据挖掘与机器学习

回复 贝叶斯算法      贝叶斯与新闻分类实战

回复 数据分析师      数据分析师八大能力培养

回复 自然语言处理  自然语言处理之AI深度学习

你可能感兴趣的:(机票前台埋点的那些事儿)