作者介绍
李宁 ：著《数据化运营：系统方法与实践案例》书籍，现于某知名外卖订餐平台担任数据专家，先后于艾瑞、携程从事数据相关工作。
个人微信公众号：数据自由之路（微信ID：dataFreeLife）
题记
数据分析师能力与埋点的进阶关系：
不懂埋点会根基不稳：一名数据人如果连埋点和指标模棱两可、则根基不稳，随口一反问都可能成为定时炸弹，坍塌整个分析过程。如果你认为埋点只是开发的问题，数据人是拿现成的数据来来写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埋点/客户端
类比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来将机票页面区分。整个流程数据流不需要人工干预，完整的流程保证最小的人力和最快的效率。
页面基础指标：在数据报表中每个页面维度会有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表一样进入全自动流程。
报表字段：点击的报表是计算点击量(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 -
往期精彩：
公众号后台回复关键词学习
回复 免费 获取免费课程
回复 直播 获取系列直播课
回复 Python 1小时破冰入门Python
回复 人工智能 从零入门人工智能
回复 深度学习 手把手教你用Python深度学习
回复 机器学习 小白学数据挖掘与机器学习
回复 贝叶斯算法 贝叶斯与新闻分类实战
回复 数据分析师 数据分析师八大能力培养
回复 自然语言处理 自然语言处理之AI深度学习
