對2016年作總結后，發現自己的文章中有很多是在務虛，很多新入行的童鞋通過私下方式詢問了很多比較實際的問題。但在遵守公司數據保密規定的前提下做務實的分享不是一件容易的事情（相當于讓了一車馬炮，想來一手好棋顧慮比較多），最后決定從埋點的維度來切入，將從埋點方法、指標釋義以及分析方法擴展以窺全貌。

聲明：本文由李寧投稿至36大數據，并經由36大數據編輯發布，轉載必須獲得原作者和36大數據許可，并標注來源36大數據和原文鏈接 http://www.36dsj.com/archives/75791，任何不經同意的轉載均為侵權。

一名數據人如果連埋點和指標模棱兩可、則根基不穩，隨口一反問都可能成為定時炸彈，坍塌整個分析過程。如果你認為埋點只是開發的問題，數據人是拿現成的數據來來寫sql、完成分析，未來路可能會越走越窄。

我的理解，數據分析師，可以根據埋點的質量來決定怎么使用埋點，在什么情況下用什么埋點數據會更貼近事實，很自信地說“我給出的數據是現階段最可靠的”，面對別人的質疑時，你的數據無可辯駁。

數據分析師不是抱怨埋點質量差而影響了自己分析，而是應該想“我如何用好現有的埋點來找到最貼近事實的數據來支持我的結論，埋點質量在不斷改進，但我不會等埋點。永遠敢于給出結論。”

–正文–

攜程機票埋點隨著業務復雜度的增加而在做加法，先后上的埋點包括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

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順序說明

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，但計算方式明顯不同。

hybrid埋點

起源：hybrid埋點在2016年9月份以前并沒有統一的埋點格式，不同的業務開發團隊采用的js不完全相同，經過多方push統一一套，因speed處是點擊名稱，又俗稱“speed”埋點。

報表數據流：speed埋點因均為中文，所以不需要人工維護維表，bi對結果表進行distinct即可生成點擊篩選框。但這需要開發在speed處不可添加變量字段，否則下拉列表將會是一個災難。

解決的業務問題：speed埋點包含訂單信息，以hybrid訂單詳情頁為例，我們可以通過orderid的信息將用戶在訂單詳情頁的行為和來電行為關聯起來，如果用戶在訂單詳情頁上點擊“退票”操作后當天來電“退票”，說明該按鈕沒有完全解決客戶問題，可以在這個點上深挖需求，改進體驗。在快速迭代頁面的過程中，關注每個功能的點擊后來電的比例，來深究每個頁面細節，，對于快速迭代、精細化數據運營非常有幫助。

面對的挑戰：因每次上傳內容較多，包含系統自帶信息，比如設備型號、user-agent和報錯埋點信息等，導致用戶流量消耗較大，待逐步改進。

online埋點

?

oonline埋點采用比較節省流量的方式，即在頁面離開（包括進入下一個頁面和當前頁面刷新）的時候，將頁面上所有的點擊信息以{點擊名稱:點擊數量}的json格式發送，這樣可以節省流量，但是對于orderid等的記錄就會缺失，如果增加額外信息需要改變結構，有利有弊。

trace埋點：

bi分析人員希望每個埋點都可以從開始帶到創單，這樣計算轉化率就會比較方便；但開發認為每個頁面埋點重復勞動、浪費時間和精力，而且有可能會影響頁面加載速度。為了解決這個問題，推出了trace埋點，這個埋點的特點是每個主流程頁面僅有一個，但將所有的業務信息記錄在案。

埋點格式：每個主流程頁面均有trace埋點，在頁面加載或離開時發送，由bi統一管理，app/online/h5格式基本一致，所有trace修改都需要經過bi的審核，主流程頁面包括首頁、列表頁、中間頁、填寫頁、完成頁。

作用效果：可以根據業務屬性來區分具體人群的行為轉化，故又稱“業務埋點”。比如在首頁勾選兒童之后，通過這個”children”的標識位可以看到有兒童購票意愿的細分人群在各個主流程頁面間的轉化（該標志位只有回到首頁重新取消勾選的時候才會刷新這個標識位，否則都是從首頁一直帶下去）。這樣對于細分人群的體驗改進效果具有可觀測性。

【服務端埋點】

機票OTA承擔航司很多政策任務，會在列表及中間頁通過標簽的形式來給客戶不同產品體驗，但這些政策標簽能夠帶來多少銷量的提升，以及如何決定其之間的相互影響，成為一個課題。于是在服務端從列表頁開始，將所有的顯示報文埋點記錄下來。

效果：對于所有產品可以根據政策維度和航司維度進行篩選，通過展示轉化比來觀測各個階段的轉化，同時對于后臺對應的政策業務人員可以發送針對性報表，各取所需，節省大量時間。后期將利用機器學習方法針對不同政策、價格和排序的相互關系進行測算，希望找到最優轉化的顯示方式。

【指標理解】

攜程機票的埋點體系基本如上所列，能夠清楚明白每種埋點的優劣勢對于分析問題選用數據的時候非常有益。通過埋點反映出來的指標，尤其是二次計算指標，很多在網絡上已經有詳細定義和說明，我將就結合攜程機票的應用以及復盤過程中的思考做一下說明，希望能有所啟發。

數據關聯：

關聯需要注意的是，不同的埋點的缺失率是不相同的，以下的關聯準則是經過作者在部門實踐中的反復驗證所得，不一定具備普適性。

行為和訂單的關聯，以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，最后體現在開發對埋點的重視程度不足。每個開發對于埋點的認識不同，對于埋點上送的邏輯也不盡相同，再加上心態不同可能導致結果也會差別很大。

常見的幾個埋點問題：

不該觸發的時候而被觸發：hybrid頁面曾遇到過只要是手指劃過按鈕埋點就被觸發，導致新頁面上線后點擊數據異常暴增，其實是開發在判斷觸發事件的閾值設置錯誤，停留時間超過200ms以上才算點擊，小于200ms算滑動，但是在上面那個例子中開發未做限制，導致問題。

埋點觸發相互抑制：在一個新埋點上線后，發現一個毫不相關的點擊數據下降明顯，從業務上找不到原因，后來開發查找代碼的時候發現，兩個埋點的上送邏輯存在ifelse關系，只有一個被上傳。

開發與埋點不是同一人導致邏輯異常：這主要存在于開發交接時候對于埋點的上送邏輯一般不太重視，所以在業務發生變化的時候，并沒有及時更改埋點的邏輯，比如pm希望某個默認埋點的默認顯示被記錄，最早是由服務端直接下發，客戶端不做篩選，所以客戶端買點直接讀取服務端下發內容，但一段時間后默認邏輯在客戶端加一層個性化接口，埋點方式還是直接讀取服務端內容，未做更改，導致數據一直異常，經過好長時間的努力才定位問題。

部門開發和框架之間的沖突：有時候部門開發邏輯做的很完整，但是被框架的一些邏輯所限制，被背黑鍋。比如為了優化速度，hybrid頁面在本地app打包的過程中有些文件已經放入，在hybrid請求的時候，有些文件優先以本地為主，而公共框架部門做了一些攔截，但業務的開發可能就存在沒考慮到這層邏輯，埋點數據就會全部丟失。

開發對埋點的誤解

?

為什么每個頁面都要埋這么多點，難道不能通過關聯來實現嗎？

在開發本身的任務都很重的情況下，埋點相對次要，在不了解其意義的情況下，往往意愿不強，怨聲載道。這就需要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來驗證是否具有普適性，分析能力螺旋式上升的過程。

在埋點新上線測試環境進行對比，實際看到埋點的數據格式是否符合預期。

【附錄】

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來標識。

–總結–

攜程市值從2014年的60億到2016年的140億美金，其中2016年機票的貢獻利潤超過40%，快速發展的業務必然需要大量的數據作支撐來推進整體向前發展，而發展的問題需要通過發展來解決。整體埋點體系其實比較復雜，其中的困難也不必多說。在整體趨勢下，我一直秉承兩個原則：

用戶產生交互的埋點一般放在前端，因為客戶端離用戶最近，且有些邏輯是放在客戶端，點擊后不一定都會發送服務；而服務端是以展示為主，可以記錄整個下發的報文數據，詳細分析顯示轉化比。

概念非常復雜時，將相似的概念放在一起對比理解，防止概念混淆，比如退出率和跳出率；UV數/會話數/PV數；回購率和回訪率等。