李寧，攜程機票資深數據&產品經理，對於用戶行為分析、用戶畫像、ABTest等積累了豐富的經驗。
來源：攜程技術中心
一名數據人如果連埋點和指標模稜兩可，則根基不穩，隨口一反問都可能成為定時炸彈，坍塌整個分析過程。如果你認為埋點只是開發的問題，數據人是拿現成的數據來寫sql、完成分析，未來路可能會越走越窄。
我的理解，數據分析師，可以根據埋點的質量來決定怎麼使用埋點，在什麼情況下用什麼埋點數據會更貼近事實，很自信地說「我給出的數據是現階段最可靠的」，面對別人的質疑時，你的數據無可辯駁。
數據分析師不是抱怨埋點質量差而影響了自己分析，而是應該想「我如何用好現有的埋點來找到最貼近事實的數據來支持我的結論，埋點質量在不斷改進，但我不會等埋點。永遠敢於給出結論。」
攜程機票埋點隨著業務複雜度的增加而在做加法，先後上的埋點包括ctm、action、trace、pv、服務端埋點等五個大類，每個埋點均符合其時代屬性，但現在規整起來其相互間存在一定的交叉，即使冗餘但有些埋點一部分還存在價值，轉移起來造成的數據問題誰都不想背鍋，所以埋點一直在做加法。直至在app減size的大趨勢下，才順便把無效的埋點做部分清理。
接下來介紹的埋點在攜程機票有其存在的意義，但並不代表是全局最優，如果剛開始埋點的童鞋，可以參考下面各埋點的優劣勢，結合自身的需要來去其糟粕取其精華。
全稱User Behavior Tracking system，是由攜程首席科學家葉亞明（Eric Ye，攜程前CTO）發起的一套數據框架，最早從online的埋點落入和上傳機制體系開始，逐步擴展至無線端app/hybrid/h5，後又增加abtest體系，現在支持攜程的眾多分析項目。包括數據埋點的格式、上送契約、落庫、ETL以及最後的報表數據，是數據體系的總稱，本文主要對於UBT體系在攜程機票的埋點應用以及指標應用做說明。
客戶端埋點：ctm，action，trace，pv
玩過GA(Google Analytics)的童鞋對utm埋點肯定不陌生，它以get方式記錄頁面來源，被廣泛使用營銷活動的收益結算，Ctrip的utm即為ctm，主要用於online和h5平臺，不僅對落地頁面的uv評估，同時需要根據規則計算其轉化。因ctm只向後傳遞一次，未能直接關聯創單（或者hybrid頁面帶到native頁面面臨中斷）。
以機票特價頁面為例，通常會根據同一天訪問過特價首頁的vid、sid來關聯同一session的下單行為，且下單時間在頁面訪問時間之後，記為間接訂單；在此基礎上再限制訪問特價頁面的出發到達城市(從url截取)與訂單對應，並限制下單前至最近一次訪問特價頁面之間未再次到訪過首頁（排除看完特價頁面後從首頁主流程正常下單的情況），記為直接訂單。間接訂單的含義是計算特價頁面影響的用戶下單意願的程度，而直接訂單是計算從特價頁面而下單情況。正常情況下都是以直接訂單為主要指標，間接訂單作為參考指標。
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將被多計算一遍，計算結果將高於實際數據，所以在計算機票主流程轉化率的時候，都是從列表頁作為起點。
點擊埋點平臺區別較大，按照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等的記錄就會缺失，如果增加額外信息需要改變結構，有利有弊。
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，最後體現在開發對埋點的重視程度不足。每個開發對於埋點的認識不同，對於埋點上送的邏輯也不盡相同，再加上心態不同可能導致結果也會差別很大。
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來驗證是否具有普適性，分析能力螺旋式上升的過程。
在埋點新上線測試環境進行對比，實際看到埋點的數據格式是否符合預期。
【附錄】