李寧：攜程機票前臺埋點二三事
攜程機票埋點隨著業(yè)務(wù)復(fù)雜度的增加而在做加法，先后上的埋點包括ctm、action、trace、pv、服務(wù)端埋點等五個大類，每個埋點均符合其時代屬性，但現(xiàn)在規(guī)整起來其相互間存在一定的交叉，即使冗余但有些埋點一部分還存在價值，轉(zhuǎn)移起來造成的數(shù)據(jù)問題誰都不想背鍋，所以埋點一直在做加法。直至在app減size的大趨勢下，才順便把無效的埋點做部分清理。
接下來介紹的埋點在攜程機票有其存在的意義，但并不代表是全局最優(yōu)，如果剛開始埋點的童鞋，可以參考下面各埋點的優(yōu)劣勢，結(jié)合自身的需要來取其糟粕取其精華。
ubt是什么?
全稱User Behavior Tracking system，是由攜程首席科學(xué)家葉亞明(Eric Ye，前攜程CTO)先生發(fā)起的一套數(shù)據(jù)框架，最早從online的埋點落入和上傳機制體系開始，逐步擴展至無線端app/hybrid/h5，后又增加abtest體系，現(xiàn)在支持攜程的眾多分析項目。包括數(shù)據(jù)埋點的格式、上送契約、落庫、ETL以及最后的報表數(shù)據(jù)，是數(shù)據(jù)體系的總稱，本文主要對于ubt體系在攜程機票的埋點應(yīng)用以及指標應(yīng)用做說明。
客戶端埋點
客戶端埋點：ctm，action，trace，pv
ctm埋點：
玩過GA(Google Analytics)的童鞋對utm埋點肯定不陌生，它以get方式記錄頁面來源，被廣泛使用營銷活動的收益結(jié)算，Ctripのutm即為ctm，主要用于online和h5平臺，不僅對落地頁面的uv評估，同時需要根據(jù)規(guī)則計算其轉(zhuǎn)化。因ctm只向后傳遞一次，未能直接關(guān)聯(lián)創(chuàng)單(或者hybrid頁面帶到native頁面面臨中斷)。
以機票特價頁面為例，通常會根據(jù)同一天訪問過特價首頁的vid、sid來關(guān)聯(lián)同一session的下單行為，且下單時間在頁面訪問時間之后，記為間接訂單;在此基礎(chǔ)上再限制訪問特價頁面的出發(fā)到達城市(從url截取)與訂單對應(yīng)，并限制下單前至最近一次訪問特價頁面之間未再次到訪過首頁(排除看完特價頁面后從首頁主流程正常下單的情況)，記為直接訂單。間接訂單的含義是計算特價頁面影響的用戶下單意愿的程度，而直接訂單是計算從特價頁面而下單情況。正常情況下都是以直接訂單為主要指標，間接訂單作為參考指標。
pv埋點：
PV埋點因存在時間最久、埋點方式最簡單(調(diào)用logpage方法發(fā)送pageid)，所以被接受程度最高，同時也作為新上埋點驗證丟失率的基石數(shù)據(jù)。app頁面實現(xiàn)方式有native/hybrid/rn,其均申請獨立pageid，對于計算頁面性能影響不大(除了停留時間)。
報表合作機制：作為基礎(chǔ)數(shù)據(jù)，新頁面上線第二天就需要在基礎(chǔ)報表UIP中查到(BI域數(shù)據(jù)T+1)。數(shù)據(jù)流為，新頁面在上線之前開發(fā)童鞋會在公司的資源平臺cms申請pageid，在頁面加載的時候調(diào)用logpage接口上傳pageid，行為數(shù)據(jù)經(jīng)ETL落入hive庫，經(jīng)過清洗(去爬蟲、去測試賬號等)，統(tǒng)計結(jié)果數(shù)據(jù)進入sqlserver，基礎(chǔ)報表平臺讀取數(shù)據(jù)做匯總展示。其中篩選字段可以通過channelid來將機票頁面區(qū)分。整個流程數(shù)據(jù)流不需要人工干預(yù)，完整的流程保證最小的人力和最快的效率。
頁面基礎(chǔ)指標：在數(shù)據(jù)報表中每個頁面維度會有UV、visits、PV、退出次數(shù)、頁面停留時間。visits代表session/會話數(shù),退出次數(shù)具體釋義請參考百度。頁面停留時間，是該頁面與下一面的starttime之差，一般取中位數(shù)(屏蔽異常值)。
業(yè)務(wù)影響uv：攜程機票首頁是區(qū)分國際和國內(nèi)的(pageid不同)，如果用戶進入時是”北京“->"上海"，則為國內(nèi)機票的首頁，切換到達城市為”墨爾本“時候，則為國際機票的首頁。如果用戶上一次是購買的國內(nèi)商務(wù)出行的機票，本次想搜出國玩的機票，進來被默認是記憶上一次的國內(nèi)機票首頁，這樣國內(nèi)首頁的uv將被多計算一遍，計算結(jié)果將高于實際數(shù)據(jù)，所以在計算機票主流程轉(zhuǎn)化率的時候，都是從列表頁作為起點。
action點擊/埋點：
點擊埋點平臺區(qū)別較大，按照native、hybrid、online順序說明
native埋點
埋點格式：為c_****,比如搜索頁面是c_search,c代表click，后面為名稱的英文簡稱，有開發(fā)人員自行定義。點擊埋點的hive表內(nèi)有pageid字段，命名時只要保證同一頁面無重復(fù)名稱即可。
埋點流程：app的native默認是有點擊按鈕即埋點，除非是pm特殊指定埋點附加信息(比如列表頁記錄篩選N次，但不記錄篩選內(nèi)容，如果需要記錄篩選內(nèi)容，需PM在PRD中說明)。因為native發(fā)布周期平均一個月，在之前曾遇到過重大問題沒有及時解決因其領(lǐng)導(dǎo)高度重視，故決定今后所有點擊一律埋點，逐步形成習(xí)慣。
報表數(shù)據(jù)流：這個報表暫時還沒有上公司的cms系統(tǒng)，現(xiàn)在前臺產(chǎn)品在維護其埋點簡稱和中文名稱，由bi來調(diào)用，生成每天T+1的報表。后期考慮維護進入cms系統(tǒng)，像pv表一樣進入全自動流程
報表字段：點擊的報表是計算點擊量(PV)、點擊用戶量(UV)、頁面用戶量(頁面UV)，點擊uv比(點擊UV/頁面UV)，人均點擊次數(shù)(點擊pv/點擊UV)。雖然指標很簡單呢，但是如果是跨BU或跨公司來核對數(shù)據(jù)，需要對比計算標準，曾經(jīng)在和友商核對數(shù)據(jù)的過程之紅，因?qū)Ψ绞欠?wù)端埋點、根據(jù)服務(wù)請求來計算pv;我方是客戶端埋點、根據(jù)客戶端頁面刷新計算pv，導(dǎo)致人均pv數(shù)據(jù)明顯對不上，后來經(jīng)過face to face的溝通才發(fā)現(xiàn)雖然同樣說pv，但計算方式明顯不同。
hybrid埋點
起源：hybrid埋點在2016年9月份以前并沒有統(tǒng)一的埋點格式，不同的業(yè)務(wù)開發(fā)團隊采用的js不完全相同，經(jīng)過多方push統(tǒng)一一套，因speed處是點擊名稱，又俗稱“speed”埋點。
報表數(shù)據(jù)流：speed埋點因均為中文，所以不需要人工維護維表，bi對結(jié)果表進行distinct即可生成點擊篩選框。但這需要開發(fā)在speed處不可添加變量字段，否則下拉列表將會是一個災(zāi)難。
解決的業(yè)務(wù)問題：speed埋點包含訂單信息，以hybrid訂單詳情頁為例，我們可以通過orderid的信息將用戶在訂單詳情頁的行為和來電行為關(guān)聯(lián)起來，如果用戶在訂單詳情頁上點擊“退票”操作后當天來電“退票”，說明該按鈕沒有完全解決客戶問題，可以在這個點上深挖需求，改進體驗。在快速迭代頁面的過程中，關(guān)注每個功能的點擊后來電的比例，來深究每個頁面細節(jié)，，對于快速迭代、精細化數(shù)據(jù)運營非常有幫助。
面對的挑戰(zhàn)：因每次上傳內(nèi)容較多，包含系統(tǒng)自帶信息，比如設(shè)備型號、user-agent和報錯埋點信息等，導(dǎo)致用戶流量消耗較大，待逐步改進。
online埋點
online埋點采用比較節(jié)省流量的方式，即在頁面離開(包括進入下一個頁面和當前頁面刷新)的時候，將頁面上所有的點擊信息以{點擊名稱:點擊數(shù)量}的json格式發(fā)送，這樣可以節(jié)省流量，但是對于orderid等的記錄就會缺失，如果增加額外信息需要改變結(jié)構(gòu)，有利有弊。
trace埋點：
bi分析人員希望每個埋點都可以從開始帶到創(chuàng)單，這樣計算轉(zhuǎn)化率就會比較方便;但開發(fā)認為每個頁面埋點重復(fù)勞動、浪費時間和精力，而且有可能會影響頁面加載速度。為了解決這個問題，推出了trace埋點，這個埋點的特點是每個主流程頁面僅有一個，但將所有的業(yè)務(wù)信息記錄在案。
埋點格式：每個主流程頁面均有trace埋點，在頁面加載或離開時發(fā)送，由bi統(tǒng)一管理，app/online/h5格式基本一致，所有trace修改都需要經(jīng)過bi的審核，主流程頁面包括首頁、列表頁、中間頁、填寫頁、完成頁。
作用效果：可以根據(jù)業(yè)務(wù)屬性來區(qū)分具體人群的行為轉(zhuǎn)化，故又稱“業(yè)務(wù)埋點”。比如在首頁勾選兒童之后，通過這個"children"的標識位可以看到有兒童購票意愿的細分人群在各個主流程頁面間的轉(zhuǎn)化(該標志位只有回到首頁重新取消勾選的時候才會刷新這個標識位，否則都是從首頁一直帶下去)。這樣對于細分人群的體驗改進效果具有可觀測性。
服務(wù)端埋點
機票O(jiān)TA承擔航司很多政策任務(wù)，會在列表及中間頁通過標簽的形式來給客戶不同產(chǎn)品體驗，但這些政策標簽?zāi)軌驇矶嗌黉N量的提升，以及如何決定其之間的相互影響，成為一個課題。于是在服務(wù)端從列表頁開始，將所有的顯示報文埋點記錄下來。
效果：對于所有產(chǎn)品可以根據(jù)政策維度和航司維度進行篩選，通過展示轉(zhuǎn)化比來觀測各個階段的轉(zhuǎn)化，同時對于后臺對應(yīng)的政策業(yè)務(wù)人員可以發(fā)送針對性報表，各取所需，節(jié)省大量時間。后期將利用機器學(xué)習(xí)方法針對不同政策、價格和排序的相互關(guān)系進行測算，希望找到最優(yōu)轉(zhuǎn)化的顯示方式。
指標理解
攜程機票的埋點體系基本如上所列，能夠清楚明白每種埋點的優(yōu)劣勢對于分析問題選用數(shù)據(jù)的時候非常有益。通過埋點反映出來的指標，尤其是二次計算指標，很多在網(wǎng)絡(luò)上已經(jīng)有詳細定義和說明，我將就結(jié)合攜程機票的應(yīng)用以及復(fù)盤過程中的思考做一下說明，希望能有所啟發(fā)。
數(shù)據(jù)關(guān)聯(lián)：
關(guān)聯(lián)需要注意的是，不同的埋點的缺失率是不相同的，以下的關(guān)聯(lián)準則是經(jīng)過作者在部門實踐中的反復(fù)驗證所得，不一定具備普適性。
行為和訂單的關(guān)聯(lián)，以app為例，關(guān)聯(lián)同一人，行為主要是clientcode設(shè)備號，訂單主要是uid，這兩者之間通過臨時訂單表關(guān)聯(lián)(在填寫頁創(chuàng)單的時候創(chuàng)建臨時單)，把clientcode、uid、orderid訂單號記錄下來(如果拆單的話，僅記錄主訂單)，然后需要通過訂單主表o_orders來把實際下單數(shù)據(jù)過濾出來，最后可以拿到clientcode在每個session中的下單記錄以及uid映射。
行為和行為的關(guān)聯(lián)，一般是通過clientcode,sid,pvid來定位同一個頁面的行為，如果是核心數(shù)據(jù)，如訂單號建議直接埋點，不建議通過關(guān)聯(lián)拿到。尤其是在小眾人群的匹配上，數(shù)據(jù)的缺失的基礎(chǔ)上進行關(guān)聯(lián)可能會造成數(shù)據(jù)異常波動。
數(shù)據(jù)缺失：
現(xiàn)狀：公司的pv表的存在時間最久，而且埋點最簡單，結(jié)構(gòu)最穩(wěn)定，所有的驗證數(shù)據(jù)都是以pv表的數(shù)據(jù)為基準。經(jīng)過驗證下來，根據(jù)按天計算的uv數(shù)據(jù)，trace的埋點準確率在97%左右，服務(wù)端的埋點在103%左右。如果都是在同一類埋點的情況下計算轉(zhuǎn)化率，分子分母是每個頁面的uv，影響不大，但是跨埋點計算的時候，需要特別小心。在數(shù)量級明確之后，還存在數(shù)據(jù)格式的問題，尤其是string和int的轉(zhuǎn)化，特殊字符造成的解析困難等，這些都需要在使用過程中不斷驗證，bi和開發(fā)相互磨合。
埋點的準確率受很多因素的影響，主要是不暢溝通帶來的各方gap，最后體現(xiàn)在開發(fā)對埋點的重視程度不足。每個開發(fā)對于埋點的認識不同，對于埋點上送的邏輯也不盡相同，再加上心態(tài)不同可能導(dǎo)致結(jié)果也會差別很大。
常見的幾個埋點問題：
不該觸發(fā)的時候而被觸發(fā)：hybrid頁面曾遇到過只要是手指劃過按鈕埋點就被觸發(fā)，導(dǎo)致新頁面上線后點擊數(shù)據(jù)異常暴增，其實是開發(fā)在判斷觸發(fā)事件的閾值設(shè)置錯誤，停留時間超過200ms以上才算點擊，小于200ms算滑動，但是在上面那個例子中開發(fā)未做限制，導(dǎo)致問題。
埋點觸發(fā)相互抑制：在一個新埋點上線后，發(fā)現(xiàn)一個毫不相關(guān)的點擊數(shù)據(jù)下降明顯，從業(yè)務(wù)上找不到原因，后來開發(fā)查找代碼的時候發(fā)現(xiàn)，兩個埋點的上送邏輯存在ifelse關(guān)系，只有一個被上傳。
開發(fā)與埋點不是同一人導(dǎo)致邏輯異常：這主要存在于開發(fā)交接時候?qū)τ诼顸c的上送邏輯一般不太重視，所以在業(yè)務(wù)發(fā)生變化的時候，并沒有及時更改埋點的邏輯，比如pm希望某個默認埋點的默認顯示被記錄，最早是由服務(wù)端直接下發(fā)，客戶端不做篩選，所以客戶端買點直接讀取服務(wù)端下發(fā)內(nèi)容，但一段時間后默認邏輯在客戶端加一層個性化接口，埋點方式還是直接讀取服務(wù)端內(nèi)容，未做更改，導(dǎo)致數(shù)據(jù)一直異常，經(jīng)過好長時間的努力才定位問題。
部門開發(fā)和框架之間的沖突：有時候部門開發(fā)邏輯做的很完整，但是被框架的一些邏輯所限制，被背黑鍋。比如為了優(yōu)化速度，hybrid頁面在本地app打包的過程中有些文件已經(jīng)放入，在hybrid請求的時候，有些文件優(yōu)先以本地為主，而公共框架部門做了一些攔截，但業(yè)務(wù)的開發(fā)可能就存在沒考慮到這層邏輯，埋點數(shù)據(jù)就會全部丟失。
開發(fā)對埋點的誤解
為什么每個頁面都要埋這么多點，難道不能通過關(guān)聯(lián)來實現(xiàn)嗎?
在開發(fā)本身的任務(wù)都很重的情況下，埋點相對次要，在不了解其意義的情況下，往往意愿不強，怨聲載道。這就需要pm或者bi很清楚地知道哪些埋點數(shù)據(jù)一定要有，哪些是可有可無，同時在整個項目上的最終數(shù)據(jù)表現(xiàn)上跟開發(fā)童鞋分享數(shù)據(jù)，強化埋點的價值。另外對于開發(fā)童鞋本身比較關(guān)注的kpi，如頁面性能埋點，包括報錯信息、加載時間、白屏等，可以輔助其建立報表來增強對數(shù)據(jù)的關(guān)注度。
為什么埋點動不動就要增加，能不能一次性提好?
這是個歷史性的難題，因為在分析問題的時候，維度在不斷地細致化，而這些維度是在當初并沒有想到的、或者說可能認為沒有必要的埋點(沒有必要的埋點不增加開發(fā)的工作量)，但是問題發(fā)生之后就需要增加埋點，這也是需要與開發(fā)保持密切的溝通。
新老用戶：
定義：從訪問維度上看，該設(shè)備號歷史上從未訪問過攜程app，則該設(shè)備為訪問維度上的新用戶;從訂單維度上看，該uiv歷史上從未在攜程app上成功下單，則該設(shè)備為訂單維度上的新用戶。
uv的區(qū)別：從訪問維度上看，是通過設(shè)備號vid/clientcode來看;從訂單維度，是通過uid來看。
設(shè)備平臺的區(qū)別：即使該uid在機票online上已下單，某天在app上第一次下單，則也被認定為app的下單新用戶。
辯證關(guān)系：如果一個人是app平臺的下單新用戶，則該設(shè)備號一般為訪問新用戶(一般很少有人把自己手機借給別人登陸攜程賬號，因為如果是幫朋友代訂可以用自己賬號下單，如果有的話成為異常用戶的概率比較高);一個設(shè)備號被認定為某天的app新用戶，則該uid不一定是下單新用戶(因為不一定下單，且有可能是該uid買了新手機。)攜程機票是相對成熟的app，新老用戶的比例基本保持動態(tài)平衡。
留存率/回購回訪率：
回購率：季度回購率，機票是低頻消費產(chǎn)品，回購率的比率經(jīng)過長期觀察發(fā)現(xiàn)季度的周期比較有指導(dǎo)意義。
回訪率：月度回訪率。
停留時間：
定義：該頁面與pvid+1下一頁面的starttime之差，計算方式一般采用中位數(shù)(規(guī)避異常值影響整體表現(xiàn))。
session時長計算：首次搜索->下單時間、末次搜索->下單時間，反映用戶決策時長的兩個指標，計算方式為同一session。但機票的購買決策時間比較長，從起意到最后下單在一個session完成的比例比較低，未來考慮在跨session的情況下計算其時間，盡量接近真實的停留時間。
native和hybrid混用的停留時間之殤：停留時長的計算是利用pvid+1的頁面與本頁面的訪問時間差來計算的(艾瑞在online端的訪問時間是duration，表示激活時間，能夠?qū)嶋H表示當前頁面的停留時間)，而如果native和內(nèi)嵌hybrid(已申請pageid)先后加載的時候，填寫頁的停留時間其實就變成hybrid頁面starttime-native頁面的starttime，這中間的時間差其實是兩頁面加載的時間差，并不是用戶真實的停留時間。
停留時間是否越短越好?(最好自己先思考一下再看我的回答)
對于攜程機票的電商網(wǎng)站來講，停留時間是一個輔助的指標，而非一個決定性的指標，需要和一些決定性的指標一起來推測用戶的行為。
比如同樣是填寫頁的停留時間變短，在填寫頁之后的轉(zhuǎn)化率上升的情況下，可以理解為該頁面讓用戶非常放心，用戶需要填寫和核對的信息很少，對攜程的網(wǎng)站非常熟悉和自信，下單迅速，這是一件正向的事情;
而如果是填寫頁之后的轉(zhuǎn)化率下降，就有可能是頁面冗余信息很多，用戶想關(guān)注的信息沒有找到，或者造成用戶反感的信息非常醒目，導(dǎo)致用戶立即離開而沒有下單，這就成為一件棘手的事情。結(jié)合業(yè)務(wù)可能會找到很多原因，但有一點可以肯定，單純追求停留時間的上升或者下降是沒有意義的，TA需要核心指標一起來定位原因。
行為流可視化的必要性：
可以建立每個用戶的行為流表，方便pm根據(jù)uid、手機號等常用字段可以搜索到用戶的頁面和點擊行為流，方便查找問題以及找到問題解決的靈感。因為解決問題是從特殊到一般的過程，可以通過行為流找到靈感，然后用sql來驗證是否具有普適性，分析能力螺旋式上升的過程。
在埋點新上線測試環(huán)境進行對比，實際看到埋點的數(shù)據(jù)格式是否符合預(yù)期。
附錄
vid/clientcode/clientid：設(shè)備標識字段，vid應(yīng)用于online和h5(受瀏覽器和cookie限制，換瀏覽器或清除cookie之后會更新vid)，clientcode代表app/native和hybrid(僅與設(shè)備有關(guān)，在不換設(shè)備的情況下標識唯一)
sid：sessionid，又稱為會話id，以online為例，同一設(shè)備訪問同一網(wǎng)站30min之內(nèi)為同一session。
pvid：pv的計數(shù)，同一用戶在一天之內(nèi)的攜程頁面訪問pv從1開始標識，記錄該人當天內(nèi)的所有訪問頁面的先后順序，再根據(jù)30min來切session。
starttime：事件發(fā)生時間，在pv表指頁面瀏覽時間，在action表指按鈕觸發(fā)時間。
UV：在考慮行為的時候都用設(shè)備號來標識，在考慮訂單的額時候都用uid來標識。
總結(jié)
攜程市值從2014年的60億到2016年的140億美金，其中2016年機票的貢獻利潤超過40%，快速發(fā)展的業(yè)務(wù)必然需要大量的數(shù)據(jù)作支撐來推進整體向前發(fā)展，而發(fā)展的問題需要通過發(fā)展來解決。整體埋點體系其實比較復(fù)雜，其中的困難也不必多說。在整體趨勢下，我一直秉承兩個原則：
用戶產(chǎn)生交互的埋點一般放在前端，因為客戶端離用戶最近，且有些邏輯是放在客戶端，點擊后不一定都會發(fā)送服務(wù);而服務(wù)端是以展示為主，可以記錄整個下發(fā)的報文數(shù)據(jù)，詳細分析顯示轉(zhuǎn)化比。
概念非常復(fù)雜時，將相似的概念放在一起對比理解，防止概念混淆，比如退出率和跳出率;UV數(shù)/會話數(shù)/PV數(shù);回購率和回訪率等。
【本文為51CTO專欄作者“李寧”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系作者獲取授權(quán)】
