轉:攜程機票前臺埋點二三事

一名數據人若是連埋點和指標模棱兩可，則根基不穩，隨口一反問均可能成爲定時炸彈，坍塌整個分析過程。若是你認爲埋點只是開發的問題，數據人是拿現成的數據來寫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來標識。