转:携程机票前台埋点二三事

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

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

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

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

接下来介绍的埋点在携程机票有其存在的意义，但并不表明是全局最优，若是刚开始埋点的童鞋，能够参考下面各埋点的优劣势，结合自身的须要来去其糟粕取其精华。

1、UBT是什么？

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

2、客户端埋点

客户端埋点：ctm，action，trace，pv

一、ctm埋点

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

以机票特价页面为例，一般会根据同一天访问过特价首页的vid、sid来关联同一session的下单行为，且下单时间在页面访问时间以后，记为间接订单；在此基础上再限制访问特价页面的出发到达城市(从url截取)与订单对应，并限制下单前至最近一次访问特价页面之间未再次到访过首页（排除看完特价页面后从首页主流程正常下单的状况），记为直接订单。间接订单的含义是计算特价页面影响的用户下单意愿的程度，而直接订单是计算从特价页面而下单状况。正常状况下都是以直接订单为主要指标，间接订单做为参考指标。

二、pv埋点

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

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

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

业务影响uv：携程机票首页是区分国际和国内的（pageid不一样），若是用户进入时是”北京“->”上海”，则为国内机票的首页，切换到达城市为”墨尔本“时候，则为国际机票的首页。若是用户上一次是购买的国内商务出行的机票，本次想搜出国玩的机票，进来被默认是记忆上一次的国内机票首页，这样国内首页的uv将被多计算一遍，计算结果将高于实际数据，因此在计算机票主流程转化率的时候，都是从列表页做为起点。

三、action点击/埋点

点击埋点平台区别较大，按照native、hybrid、online顺序说明。

1）native埋点

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

埋点流程：app的native默认是有点击按钮即埋点，除非是pm特殊指定埋点附加信息（好比列表页记录筛选N次，但不记录筛选内容，若是须要记录筛选内容，需PM在PRD中说明）。由于native发布周期平均一个月，在以前曾遇到太重大问题没有及时解决因其领导高度重视，故决定从此全部点击一概埋点，逐步造成习惯。

报表数据流：这个报表暂时尚未上公司的cms系统，如今前台产品在维护其埋点简称和中文名称，由bi来调用，生成天天T+1的报表。后期考虑维护进入cms系统，像pv表同样进入全自动流程

报表字段：点击的报表是计算点击量(PV)、点击用户量（UV）、页面用户量（页面UV），点击uv比（点击UV/页面UV），人均点击次数（点击pv/点击UV）。虽然指标很简单呢，可是若是是跨BU或跨公司来核对数据，须要对比计算标准，曾经在和友商核对数据的过程之红，因对方是服务端埋点、根据服务请求来计算pv；我方是客户端埋点、根据客户端页面刷新计算pv，致使人均pv数据明显对不上，后来通过face to face的沟通才发现虽然一样说pv，但计算方式明显不一样。

2）hybrid埋点

起源：hybrid埋点在2016年9月份之前并无统一的埋点格式，不一样的业务开发团队采用的js不彻底相同，通过多方push统一一套，因speed处是点击名称，又俗称“speed”埋点。

报表数据流：speed埋点因均为中文，因此不须要人工维护维表，bi对结果表进行distinct便可生成点击筛选框。但这须要开发在speed处不可添加变量字段，不然下拉列表将会是一个灾难。

解决的业务问题：speed埋点包含订单信息，以hybrid订单详情页为例，咱们能够经过orderid的信息将用户在订单详情页的行为和来电行为关联起来，若是用户在订单详情页上点击“退票”操做后当天来电“退票”，说明该按钮没有彻底解决客户问题，能够在这个点上深挖需求，改进体验。在快速迭代页面的过程当中，关注每一个功能的点击后来电的比例，来深究每一个页面细节，，对于快速迭代、精细化数据运营很是有帮助。

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

3）online埋点

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

四、trace埋点

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

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

做用效果：能够根据业务属性来区分具体人群的行为转化，故又称“业务埋点”。好比在首页勾选儿童以后，经过这个”children”的标识位能够看到有儿童购票意愿的细分人群在各个主流程页面间的转化（该标志位只有回到首页从新取消勾选的时候才会刷新这个标识位，不然都是从首页一直带下去）。这样对于细分人群的体验改进效果具备可观测性。

3、服务端埋点

机票OTA承担航司不少政策任务，会在列表及中间页经过标签的形式来给客户不一样产品体验，但这些政策标签可以带来多少销量的提高，以及如何决定其之间的相互影响，成为一个课题。因而在服务端从列表页开始，将全部的显示报文埋点记录下来。

效果：对于全部产品能够根据政策维度和航司维度进行筛选，经过展现转化比来观测各个阶段的转化，同时对于后台对应的政策业务人员能够发送针对性报表，各取所需，节省大量时间。后期将利用机器学习方法针对不一样政策、价格和排序的相互关系进行测算，但愿找到最优转化的显示方式。

4、指标理解

携程机票的埋点体系基本如上所列，可以清楚明白每种埋点的优劣势对于分析问题选用数据的时候很是有益。经过埋点反映出来的指标，尤为是二次计算指标，不少在网络上已经有详细定义和说明，我将就结合携程机票的应用以及复盘过程当中的思考作一下说明，但愿能有所启发。

一、数据关联

关联须要注意的是，不一样的埋点的缺失率是不相同的，如下的关联准则是通过做者在部门实践中的反复验证所得，不必定具有普适性。

行为和订单的关联，以app为例，关联同一人，行为主要是clientcode设备号，订单主要是uid，这二者之间经过临时订单表关联（在填写页创单的时候建立临时单），把clientcode、uid、orderid订单号记录下来（若是拆单的话，仅记录主订单），而后须要经过订单主表o_orders来把实际下单数据过滤出来，最后能够拿到clientcode在每一个session中的下单记录以及uid映射。

行为和行为的关联，通常是经过clientcode,sid,pvid来定位同一个页面的行为，若是是核心数据，如订单号建议直接埋点，不建议经过关联拿到。尤为是在小众人群的匹配上，数据的缺失的基础上进行关联可能会形成数据异常波动。

二、数据缺失

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

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

1）常见的几个埋点问题：

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

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

开发与埋点不是同一人致使逻辑异常：这主要存在于开发交接时候对于埋点的上送逻辑通常不过重视，因此在业务发生变化的时候，并无及时更改埋点的逻辑，好比pm但愿某个默认埋点的默认显示被记录，最先是由服务端直接下发，客户端不作筛选，因此客户端买点直接读取服务端下发内容，但一段时间后默认逻辑在客户端加一层个性化接口，埋点方式仍是直接读取服务端内容，未作更改，致使数据一直异常，通过好长时间的努力才定位问题。

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

2）开发对埋点的误解

问：为何每一个页面都要埋这么多点，难道不能经过关联来实现吗？

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

问：为何埋点动不动就要增长，能不能一次性提好？

答：这是个历史性的难题，由于在分析问题的时候，维度在不断地细致化，而这些维度是在当初并无想到的、或者说可能认为没有必要的埋点（没有必要的埋点不增长开发的工做量），可是问题发生以后就须要增长埋点，这也是须要与开发保持密切的沟通。

三、新老用户

定义：从访问维度上看，该设备号历史上从未访问过携程app，则该设备为访问维度上的新用户；从订单维度上看，该uiv历史上从未在携程app上成功下单，则该设备为订单维度上的新用户。

uv的区别：从访问维度上看，是经过设备号vid/clientcode来看；从订单维度，是经过uid来看。

设备平台的区别：即便该uid在机票online上已下单，某天在app上第一次下单，则也被认定为app的下单新用户。

辩证关系：若是一我的是app平台的下单新用户，则该设备号通常为访问新用户（通常不多有人把本身手机借给别人登录携程帐号，由于若是是帮朋友代订能够用本身帐号下单，若是有的话成为异经常使用户的几率比较高）；一个设备号被认定为某天的app新用户，则该uid不必定是下单新用户（由于不必定下单，且有多是该uid买了新手机。）携程机票是相对成熟的app，新老用户的比例基本保持动态平衡。

四、留存率/回购回访率

回购率：季度回购率，机票是低频消费产品，回购率的比率通过长期观察发现季度的周期比较有指导意义。

回访率：月度回访率。

五、停留时间

定义：该页面与pvid+1下一页面的starttime之差，计算方式通常采用中位数（规避异常值影响总体表现）。

session时长计算：首次搜索->下单时间、末次搜索->下单时间，反映用户决策时长的两个指标，计算方式为同一session。但机票的购买决策时间比较长，从起意到最后下单在一个session完成的比例比较低，将来考虑在跨session的状况下计算其时间，尽可能接近真实的停留时间。

native和hybrid混用的停留时间之殇：停留时长的计算是利用pvid+1的页面与本页面的访问时间差来计算的（艾瑞在online端的访问时间是duration，表示激活时间，可以实际表示当前页面的停留时间），而若是native和内嵌hybrid（已申请pageid）前后加载的时候，填写页的停留时间其实就变成hybrid页面starttime-native页面的starttime，这中间的时间差实际上是两页面加载的时间差，并非用户真实的停留时间。

停留时间是否越短越好？

对于携程机票的电商网站来说，停留时间是一个辅助的指标，而非一个决定性的指标，须要和一些决定性的指标一块儿来推测用户的行为。

好比一样是填写页的停留时间变短，在填写页以后的转化率上升的状况下，能够理解为该页面让用户很是放心，用户须要填写和核对的信息不多，对携程的网站很是熟悉和自信，下单迅速，这是一件正向的事情；

而若是是填写页以后的转化率降低，就有多是页面冗余信息不少，用户想关注的信息没有找到，或者形成用户反感的信息很是醒目，致使用户当即离开而没有下单，这就成为一件棘手的事情。结合业务可能会找到不少缘由，但有一点能够确定，单纯追求停留时间的上升或者降低是没有意义的，TA须要核心指标一块儿来定位缘由。

六、行为流可视化的必要性

能够创建每一个用户的行为流表，方便pm根据uid、手机号等经常使用字段能够搜索到用户的页面和点击行为流，方便查找问题以及找到问题解决的灵感。由于解决问题是从特殊到通常的过程，能够经过行为流找到灵感，而后用sql来验证是否具备普适性，分析能力螺旋式上升的过程。

在埋点新上线测试环境进行对比，实际看到埋点的数据格式是否符合预期。

5、总结

携程市值从2014年的60亿到2016年的140亿美金，其中2016年机票的贡献利润超过40%，快速发展的业务必然须要大量的数据做支撑来推动总体向前发展，而发展的问题须要经过发展来解决。总体埋点体系其实比较复杂，其中的困难也没必要多说。在总体趋势下，我一直秉承两个原则：

一、用户产生交互的埋点通常放在前端，由于客户端离用户最近，且有些逻辑是放在客户端，点击后不必定都会发送服务；而服务端是以展现为主，能够记录整个下发的报文数据，详细分析显示转化比。

二、概念很是复杂时，将类似的概念放在一块儿对比理解，防止概念混淆，好比退出率和跳出率；UV数/会话数/PV数；回购率和回访率等。

【附录】

vid/clientcode/clientid：设备标识字段，vid应用于online和h5（受浏览器和cookie限制，换浏览器或清除cookie以后会更新vid），clientcode表明app/native和hybrid（仅与设备有关，在不换设备的状况下标识惟一）

sid：sessionid，又称为会话id，以online为例，同一设备访问同一网站30min以内为同一session。

pvid：pv的计数，同一用户在一天以内的携程页面访问pv从1开始标识，记录该人当天内的全部访问页面的前后顺序，再根据30min来切session。

starttime：事件发生时间，在pv表指页面浏览时间，在action表指按钮触发时间。

UV：在考虑行为的时候都用设备号来标识，在考虑订单的额时候都用uid来标识。