[[188173]]

攜程機(jī)票埋點(diǎn)隨著業(yè)務(wù)復(fù)雜度的增加而在做加法，先后上的埋點(diǎn)包括ctm、action、trace、pv、服務(wù)端埋點(diǎn)等五個(gè)大類，每個(gè)埋點(diǎn)均符合其時(shí)代屬性，但現(xiàn)在規(guī)整起來其相互間存在一定的交叉，即使冗余但有些埋點(diǎn)一部分還存在價(jià)值，轉(zhuǎn)移起來造成的數(shù)據(jù)問題誰都不想背鍋，所以埋點(diǎn)一直在做加法。直至在app減size的大趨勢下，才順便把無效的埋點(diǎn)做部分清理。

接下來介紹的埋點(diǎn)在攜程機(jī)票有其存在的意義，但并不代表是全局最優(yōu)，如果剛開始埋點(diǎn)的童鞋，可以參考下面各埋點(diǎn)的優(yōu)劣勢，結(jié)合自身的需要來取其糟粕取其精華。

ubt是什么?

全稱User Behavior Tracking system，是由攜程首席科學(xué)家葉亞明(Eric Ye，前攜程CTO)先生發(fā)起的一套數(shù)據(jù)框架，最早從online的埋點(diǎn)落入和上傳機(jī)制體系開始，逐步擴(kuò)展至無線端app/hybrid/h5，后又增加abtest體系，現(xiàn)在支持?jǐn)y程的眾多分析項(xiàng)目。包括數(shù)據(jù)埋點(diǎn)的格式、上送契約、落庫、ETL以及最后的報(bào)表數(shù)據(jù)，是數(shù)據(jù)體系的總稱，本文主要對于ubt體系在攜程機(jī)票的埋點(diǎn)應(yīng)用以及指標(biāo)應(yīng)用做說明。

客戶端埋點(diǎn)

客戶端埋點(diǎn)：ctm，action，trace，pv

ctm埋點(diǎn)：

玩過GA(Google Analytics)的童鞋對utm埋點(diǎn)肯定不陌生，它以get方式記錄頁面來源，被廣泛使用營銷活動(dòng)的收益結(jié)算，Ctripのutm即為ctm，主要用于online和h5平臺，不僅對落地頁面的uv評估，同時(shí)需要根據(jù)規(guī)則計(jì)算其轉(zhuǎn)化。因ctm只向后傳遞一次，未能直接關(guān)聯(lián)創(chuàng)單(或者h(yuǎn)ybrid頁面帶到native頁面面臨中斷)。

以機(jī)票特價(jià)頁面為例，通常會根據(jù)同一天訪問過特價(jià)首頁的vid、sid來關(guān)聯(lián)同一session的下單行為，且下單時(shí)間在頁面訪問時(shí)間之后，記為間接訂單;在此基礎(chǔ)上再限制訪問特價(jià)頁面的出發(fā)到達(dá)城市(從url截取)與訂單對應(yīng)，并限制下單前至最近一次訪問特價(jià)頁面之間未再次到訪過首頁(排除看完特價(jià)頁面后從首頁主流程正常下單的情況)，記為直接訂單。間接訂單的含義是計(jì)算特價(jià)頁面影響的用戶下單意愿的程度，而直接訂單是計(jì)算從特價(jià)頁面而下單情況。正常情況下都是以直接訂單為主要指標(biāo)，間接訂單作為參考指標(biāo)。

pv埋點(diǎn)：

PV埋點(diǎn)因存在時(shí)間最久、埋點(diǎn)方式最簡單(調(diào)用logpage方法發(fā)送pageid)，所以被接受程度最高，同時(shí)也作為新上埋點(diǎn)驗(yàn)證丟失率的基石數(shù)據(jù)。app頁面實(shí)現(xiàn)方式有native/hybrid/rn,其均申請獨(dú)立pageid，對于計(jì)算頁面性能影響不大(除了停留時(shí)間)。

報(bào)表合作機(jī)制：作為基礎(chǔ)數(shù)據(jù)，新頁面上線第二天就需要在基礎(chǔ)報(bào)表UIP中查到(BI域數(shù)據(jù)T+1)。數(shù)據(jù)流為，新頁面在上線之前開發(fā)童鞋會在公司的資源平臺cms申請pageid，在頁面加載的時(shí)候調(diào)用logpage接口上傳pageid，行為數(shù)據(jù)經(jīng)ETL落入hive庫，經(jīng)過清洗(去爬蟲、去測試賬號等)，統(tǒng)計(jì)結(jié)果數(shù)據(jù)進(jìn)入sqlserver，基礎(chǔ)報(bào)表平臺讀取數(shù)據(jù)做匯總展示。其中篩選字段可以通過channelid來將機(jī)票頁面區(qū)分。整個(gè)流程數(shù)據(jù)流不需要人工干預(yù)，完整的流程保證最小的人力和最快的效率。

頁面基礎(chǔ)指標(biāo)：在數(shù)據(jù)報(bào)表中每個(gè)頁面維度會有UV、visits、PV、退出次數(shù)、頁面停留時(shí)間。visits代表session/會話數(shù),退出次數(shù)具體釋義請參考百度。頁面停留時(shí)間，是該頁面與下一面的starttime之差，一般取中位數(shù)(屏蔽異常值)。

業(yè)務(wù)影響uv：攜程機(jī)票首頁是區(qū)分國際和國內(nèi)的(pageid不同)，如果用戶進(jìn)入時(shí)是”北京“->"上海"，則為國內(nèi)機(jī)票的首頁，切換到達(dá)城市為”墨爾本“時(shí)候，則為國際機(jī)票的首頁。如果用戶上一次是購買的國內(nèi)商務(wù)出行的機(jī)票，本次想搜出國玩的機(jī)票，進(jìn)來被默認(rèn)是記憶上一次的國內(nèi)機(jī)票首頁，這樣國內(nèi)首頁的uv將被多計(jì)算一遍，計(jì)算結(jié)果將高于實(shí)際數(shù)據(jù)，所以在計(jì)算機(jī)票主流程轉(zhuǎn)化率的時(shí)候，都是從列表頁作為起點(diǎn)。

action點(diǎn)擊/埋點(diǎn)：

點(diǎn)擊埋點(diǎn)平臺區(qū)別較大，按照native、hybrid、online順序說明

native埋點(diǎn)

埋點(diǎn)格式：為c_****,比如搜索頁面是c_search,c代表click，后面為名稱的英文簡稱，有開發(fā)人員自行定義。點(diǎn)擊埋點(diǎn)的hive表內(nèi)有pageid字段，命名時(shí)只要保證同一頁面無重復(fù)名稱即可。

埋點(diǎn)流程：app的native默認(rèn)是有點(diǎn)擊按鈕即埋點(diǎn)，除非是pm特殊指定埋點(diǎn)附加信息(比如列表頁記錄篩選N次，但不記錄篩選內(nèi)容，如果需要記錄篩選內(nèi)容，需PM在PRD中說明)。因?yàn)閚ative發(fā)布周期平均一個(gè)月，在之前曾遇到過重大問題沒有及時(shí)解決因其領(lǐng)導(dǎo)高度重視，故決定今后所有點(diǎn)擊一律埋點(diǎn)，逐步形成習(xí)慣。

報(bào)表數(shù)據(jù)流：這個(gè)報(bào)表暫時(shí)還沒有上公司的cms系統(tǒng)，現(xiàn)在前臺產(chǎn)品在維護(hù)其埋點(diǎn)簡稱和中文名稱，由bi來調(diào)用，生成每天T+1的報(bào)表。后期考慮維護(hù)進(jìn)入cms系統(tǒng)，像pv表一樣進(jìn)入全自動(dòng)流程

報(bào)表字段：點(diǎn)擊的報(bào)表是計(jì)算點(diǎn)擊量(PV)、點(diǎn)擊用戶量(UV)、頁面用戶量(頁面UV)，點(diǎn)擊uv比(點(diǎn)擊UV/頁面UV)，人均點(diǎn)擊次數(shù)(點(diǎn)擊pv/點(diǎn)擊UV)。雖然指標(biāo)很簡單呢，但是如果是跨BU或跨公司來核對數(shù)據(jù)，需要對比計(jì)算標(biāo)準(zhǔn)，曾經(jīng)在和友商核對數(shù)據(jù)的過程之紅，因?qū)Ψ绞欠?wù)端埋點(diǎn)、根據(jù)服務(wù)請求來計(jì)算pv;我方是客戶端埋點(diǎn)、根據(jù)客戶端頁面刷新計(jì)算pv，導(dǎo)致人均pv數(shù)據(jù)明顯對不上，后來經(jīng)過face to face的溝通才發(fā)現(xiàn)雖然同樣說pv，但計(jì)算方式明顯不同。

hybrid埋點(diǎn)

起源：hybrid埋點(diǎn)在2016年9月份以前并沒有統(tǒng)一的埋點(diǎn)格式，不同的業(yè)務(wù)開發(fā)團(tuán)隊(duì)采用的js不完全相同，經(jīng)過多方push統(tǒng)一一套，因speed處是點(diǎn)擊名稱，又俗稱“speed”埋點(diǎn)。

報(bào)表數(shù)據(jù)流：speed埋點(diǎn)因均為中文，所以不需要人工維護(hù)維表，bi對結(jié)果表進(jìn)行distinct即可生成點(diǎn)擊篩選框。但這需要開發(fā)在speed處不可添加變量字段，否則下拉列表將會是一個(gè)災(zāi)難。

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

面對的挑戰(zhàn)：因每次上傳內(nèi)容較多，包含系統(tǒng)自帶信息，比如設(shè)備型號、user-agent和報(bào)錯(cuò)埋點(diǎn)信息等，導(dǎo)致用戶流量消耗較大，待逐步改進(jìn)。

online埋點(diǎn)

online埋點(diǎn)采用比較節(jié)省流量的方式，即在頁面離開(包括進(jìn)入下一個(gè)頁面和當(dāng)前頁面刷新)的時(shí)候，將頁面上所有的點(diǎn)擊信息以{點(diǎn)擊名稱:點(diǎn)擊數(shù)量}的json格式發(fā)送，這樣可以節(jié)省流量，但是對于orderid等的記錄就會缺失，如果增加額外信息需要改變結(jié)構(gòu)，有利有弊。

trace埋點(diǎn)：

bi分析人員希望每個(gè)埋點(diǎn)都可以從開始帶到創(chuàng)單，這樣計(jì)算轉(zhuǎn)化率就會比較方便;但開發(fā)認(rèn)為每個(gè)頁面埋點(diǎn)重復(fù)勞動(dòng)、浪費(fèi)時(shí)間和精力，而且有可能會影響頁面加載速度。為了解決這個(gè)問題，推出了trace埋點(diǎn)，這個(gè)埋點(diǎn)的特點(diǎn)是每個(gè)主流程頁面僅有一個(gè)，但將所有的業(yè)務(wù)信息記錄在案。

埋點(diǎn)格式：每個(gè)主流程頁面均有trace埋點(diǎn)，在頁面加載或離開時(shí)發(fā)送，由bi統(tǒng)一管理，app/online/h5格式基本一致，所有trace修改都需要經(jīng)過bi的審核，主流程頁面包括首頁、列表頁、中間頁、填寫頁、完成頁。

作用效果：可以根據(jù)業(yè)務(wù)屬性來區(qū)分具體人群的行為轉(zhuǎn)化，故又稱“業(yè)務(wù)埋點(diǎn)”。比如在首頁勾選兒童之后，通過這個(gè)"children"的標(biāo)識位可以看到有兒童購票意愿的細(xì)分人群在各個(gè)主流程頁面間的轉(zhuǎn)化(該標(biāo)志位只有回到首頁重新取消勾選的時(shí)候才會刷新這個(gè)標(biāo)識位，否則都是從首頁一直帶下去)。這樣對于細(xì)分人群的體驗(yàn)改進(jìn)效果具有可觀測性。

服務(wù)端埋點(diǎn)

機(jī)票O(jiān)TA承擔(dān)航司很多政策任務(wù)，會在列表及中間頁通過標(biāo)簽的形式來給客戶不同產(chǎn)品體驗(yàn)，但這些政策標(biāo)簽?zāi)軌驇矶嗌黉N量的提升，以及如何決定其之間的相互影響，成為一個(gè)課題。于是在服務(wù)端從列表頁開始，將所有的顯示報(bào)文埋點(diǎn)記錄下來。

效果：對于所有產(chǎn)品可以根據(jù)政策維度和航司維度進(jìn)行篩選，通過展示轉(zhuǎn)化比來觀測各個(gè)階段的轉(zhuǎn)化，同時(shí)對于后臺對應(yīng)的政策業(yè)務(wù)人員可以發(fā)送針對性報(bào)表，各取所需，節(jié)省大量時(shí)間。后期將利用機(jī)器學(xué)習(xí)方法針對不同政策、價(jià)格和排序的相互關(guān)系進(jìn)行測算，希望找到最優(yōu)轉(zhuǎn)化的顯示方式。

指標(biāo)理解

攜程機(jī)票的埋點(diǎn)體系基本如上所列，能夠清楚明白每種埋點(diǎn)的優(yōu)劣勢對于分析問題選用數(shù)據(jù)的時(shí)候非常有益。通過埋點(diǎn)反映出來的指標(biāo)，尤其是二次計(jì)算指標(biāo)，很多在網(wǎng)絡(luò)上已經(jīng)有詳細(xì)定義和說明，我將就結(jié)合攜程機(jī)票的應(yīng)用以及復(fù)盤過程中的思考做一下說明，希望能有所啟發(fā)。

數(shù)據(jù)關(guān)聯(lián)：

關(guān)聯(lián)需要注意的是，不同的埋點(diǎn)的缺失率是不相同的，以下的關(guān)聯(lián)準(zhǔn)則是經(jīng)過作者在部門實(shí)踐中的反復(fù)驗(yàn)證所得，不一定具備普適性。

行為和訂單的關(guān)聯(lián)，以app為例，關(guān)聯(lián)同一人，行為主要是clientcode設(shè)備號，訂單主要是uid，這兩者之間通過臨時(shí)訂單表關(guān)聯(lián)(在填寫頁創(chuàng)單的時(shí)候創(chuàng)建臨時(shí)單)，把clientcode、uid、orderid訂單號記錄下來(如果拆單的話，僅記錄主訂單)，然后需要通過訂單主表o_orders來把實(shí)際下單數(shù)據(jù)過濾出來，最后可以拿到clientcode在每個(gè)session中的下單記錄以及uid映射。

行為和行為的關(guān)聯(lián)，一般是通過clientcode,sid,pvid來定位同一個(gè)頁面的行為，如果是核心數(shù)據(jù)，如訂單號建議直接埋點(diǎn)，不建議通過關(guān)聯(lián)拿到。尤其是在小眾人群的匹配上，數(shù)據(jù)的缺失的基礎(chǔ)上進(jìn)行關(guān)聯(lián)可能會造成數(shù)據(jù)異常波動(dòng)。

數(shù)據(jù)缺失：

現(xiàn)狀：公司的pv表的存在時(shí)間最久，而且埋點(diǎn)最簡單，結(jié)構(gòu)最穩(wěn)定，所有的驗(yàn)證數(shù)據(jù)都是以pv表的數(shù)據(jù)為基準(zhǔn)。經(jīng)過驗(yàn)證下來，根據(jù)按天計(jì)算的uv數(shù)據(jù)，trace的埋點(diǎn)準(zhǔn)確率在97%左右，服務(wù)端的埋點(diǎn)在103%左右。如果都是在同一類埋點(diǎn)的情況下計(jì)算轉(zhuǎn)化率，分子分母是每個(gè)頁面的uv，影響不大，但是跨埋點(diǎn)計(jì)算的時(shí)候，需要特別小心。在數(shù)量級明確之后，還存在數(shù)據(jù)格式的問題，尤其是string和int的轉(zhuǎn)化，特殊字符造成的解析困難等，這些都需要在使用過程中不斷驗(yàn)證，bi和開發(fā)相互磨合。

埋點(diǎn)的準(zhǔn)確率受很多因素的影響，主要是不暢溝通帶來的各方gap，最后體現(xiàn)在開發(fā)對埋點(diǎn)的重視程度不足。每個(gè)開發(fā)對于埋點(diǎn)的認(rèn)識不同，對于埋點(diǎn)上送的邏輯也不盡相同，再加上心態(tài)不同可能導(dǎo)致結(jié)果也會差別很大。

常見的幾個(gè)埋點(diǎn)問題：

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

埋點(diǎn)觸發(fā)相互抑制：在一個(gè)新埋點(diǎn)上線后，發(fā)現(xiàn)一個(gè)毫不相關(guān)的點(diǎn)擊數(shù)據(jù)下降明顯，從業(yè)務(wù)上找不到原因，后來開發(fā)查找代碼的時(shí)候發(fā)現(xiàn)，兩個(gè)埋點(diǎn)的上送邏輯存在ifelse關(guān)系，只有一個(gè)被上傳。

開發(fā)與埋點(diǎn)不是同一人導(dǎo)致邏輯異常：這主要存在于開發(fā)交接時(shí)候?qū)τ诼顸c(diǎn)的上送邏輯一般不太重視，所以在業(yè)務(wù)發(fā)生變化的時(shí)候，并沒有及時(shí)更改埋點(diǎn)的邏輯，比如pm希望某個(gè)默認(rèn)埋點(diǎn)的默認(rèn)顯示被記錄，最早是由服務(wù)端直接下發(fā)，客戶端不做篩選，所以客戶端買點(diǎn)直接讀取服務(wù)端下發(fā)內(nèi)容，但一段時(shí)間后默認(rèn)邏輯在客戶端加一層個(gè)性化接口，埋點(diǎn)方式還是直接讀取服務(wù)端內(nèi)容，未做更改，導(dǎo)致數(shù)據(jù)一直異常，經(jīng)過好長時(shí)間的努力才定位問題。

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

開發(fā)對埋點(diǎn)的誤解

為什么每個(gè)頁面都要埋這么多點(diǎn)，難道不能通過關(guān)聯(lián)來實(shí)現(xiàn)嗎?

在開發(fā)本身的任務(wù)都很重的情況下，埋點(diǎn)相對次要，在不了解其意義的情況下，往往意愿不強(qiáng)，怨聲載道。這就需要pm或者bi很清楚地知道哪些埋點(diǎn)數(shù)據(jù)一定要有，哪些是可有可無，同時(shí)在整個(gè)項(xiàng)目上的最終數(shù)據(jù)表現(xiàn)上跟開發(fā)童鞋分享數(shù)據(jù)，強(qiáng)化埋點(diǎn)的價(jià)值。另外對于開發(fā)童鞋本身比較關(guān)注的kpi，如頁面性能埋點(diǎn)，包括報(bào)錯(cuò)信息、加載時(shí)間、白屏等，可以輔助其建立報(bào)表來增強(qiáng)對數(shù)據(jù)的關(guān)注度。

為什么埋點(diǎn)動(dòng)不動(dòng)就要增加，能不能一次性提好?

這是個(gè)歷史性的難題，因?yàn)樵诜治鰡栴}的時(shí)候，維度在不斷地細(xì)致化，而這些維度是在當(dāng)初并沒有想到的、或者說可能認(rèn)為沒有必要的埋點(diǎn)(沒有必要的埋點(diǎn)不增加開發(fā)的工作量)，但是問題發(fā)生之后就需要增加埋點(diǎn)，這也是需要與開發(fā)保持密切的溝通。

新老用戶：

定義：從訪問維度上看，該設(shè)備號歷史上從未訪問過攜程app，則該設(shè)備為訪問維度上的新用戶;從訂單維度上看，該uiv歷史上從未在攜程app上成功下單，則該設(shè)備為訂單維度上的新用戶。

uv的區(qū)別：從訪問維度上看，是通過設(shè)備號vid/clientcode來看;從訂單維度，是通過uid來看。

設(shè)備平臺的區(qū)別：即使該uid在機(jī)票online上已下單，某天在app上第一次下單，則也被認(rèn)定為app的下單新用戶。

辯證關(guān)系：如果一個(gè)人是app平臺的下單新用戶，則該設(shè)備號一般為訪問新用戶(一般很少有人把自己手機(jī)借給別人登陸攜程賬號，因?yàn)槿绻菐团笥汛喛梢杂米约嘿~號下單，如果有的話成為異常用戶的概率比較高);一個(gè)設(shè)備號被認(rèn)定為某天的app新用戶，則該uid不一定是下單新用戶(因?yàn)椴灰欢ㄏ聠?，且有可能是該uid買了新手機(jī)。)攜程機(jī)票是相對成熟的app，新老用戶的比例基本保持動(dòng)態(tài)平衡。

留存率/回購回訪率：

回購率：季度回購率，機(jī)票是低頻消費(fèi)產(chǎn)品，回購率的比率經(jīng)過長期觀察發(fā)現(xiàn)季度的周期比較有指導(dǎo)意義。

回訪率：月度回訪率。

停留時(shí)間：

定義：該頁面與pvid+1下一頁面的starttime之差，計(jì)算方式一般采用中位數(shù)(規(guī)避異常值影響整體表現(xiàn))。

session時(shí)長計(jì)算：首次搜索->下單時(shí)間、末次搜索->下單時(shí)間，反映用戶決策時(shí)長的兩個(gè)指標(biāo)，計(jì)算方式為同一session。但機(jī)票的購買決策時(shí)間比較長，從起意到最后下單在一個(gè)session完成的比例比較低，未來考慮在跨session的情況下計(jì)算其時(shí)間，盡量接近真實(shí)的停留時(shí)間。

native和hybrid混用的停留時(shí)間之殤：停留時(shí)長的計(jì)算是利用pvid+1的頁面與本頁面的訪問時(shí)間差來計(jì)算的(艾瑞在online端的訪問時(shí)間是duration，表示激活時(shí)間，能夠?qū)嶋H表示當(dāng)前頁面的停留時(shí)間)，而如果native和內(nèi)嵌hybrid(已申請pageid)先后加載的時(shí)候，填寫頁的停留時(shí)間其實(shí)就變成hybrid頁面starttime-native頁面的starttime，這中間的時(shí)間差其實(shí)是兩頁面加載的時(shí)間差，并不是用戶真實(shí)的停留時(shí)間。

停留時(shí)間是否越短越好?(最好自己先思考一下再看我的回答)

對于攜程機(jī)票的電商網(wǎng)站來講，停留時(shí)間是一個(gè)輔助的指標(biāo)，而非一個(gè)決定性的指標(biāo)，需要和一些決定性的指標(biāo)一起來推測用戶的行為。

比如同樣是填寫頁的停留時(shí)間變短，在填寫頁之后的轉(zhuǎn)化率上升的情況下，可以理解為該頁面讓用戶非常放心，用戶需要填寫和核對的信息很少，對攜程的網(wǎng)站非常熟悉和自信，下單迅速，這是一件正向的事情;

而如果是填寫頁之后的轉(zhuǎn)化率下降，就有可能是頁面冗余信息很多，用戶想關(guān)注的信息沒有找到，或者造成用戶反感的信息非常醒目，導(dǎo)致用戶立即離開而沒有下單，這就成為一件棘手的事情。結(jié)合業(yè)務(wù)可能會找到很多原因，但有一點(diǎn)可以肯定，單純追求停留時(shí)間的上升或者下降是沒有意義的，TA需要核心指標(biāo)一起來定位原因。

行為流可視化的必要性：

可以建立每個(gè)用戶的行為流表，方便pm根據(jù)uid、手機(jī)號等常用字段可以搜索到用戶的頁面和點(diǎn)擊行為流，方便查找問題以及找到問題解決的靈感。因?yàn)榻鉀Q問題是從特殊到一般的過程，可以通過行為流找到靈感，然后用sql來驗(yàn)證是否具有普適性，分析能力螺旋式上升的過程。

在埋點(diǎn)新上線測試環(huán)境進(jìn)行對比，實(shí)際看到埋點(diǎn)的數(shù)據(jù)格式是否符合預(yù)期。

附錄

vid/clientcode/clientid：設(shè)備標(biāo)識字段，vid應(yīng)用于online和h5(受瀏覽器和cookie限制，換瀏覽器或清除cookie之后會更新vid)，clientcode代表app/native和hybrid(僅與設(shè)備有關(guān)，在不換設(shè)備的情況下標(biāo)識唯一)

sid：sessionid，又稱為會話id，以online為例，同一設(shè)備訪問同一網(wǎng)站30min之內(nèi)為同一session。

pvid：pv的計(jì)數(shù)，同一用戶在一天之內(nèi)的攜程頁面訪問pv從1開始標(biāo)識，記錄該人當(dāng)天內(nèi)的所有訪問頁面的先后順序，再根據(jù)30min來切session。

starttime：事件發(fā)生時(shí)間，在pv表指頁面瀏覽時(shí)間，在action表指按鈕觸發(fā)時(shí)間。

UV：在考慮行為的時(shí)候都用設(shè)備號來標(biāo)識，在考慮訂單的額時(shí)候都用uid來標(biāo)識。

總結(jié)

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

用戶產(chǎn)生交互的埋點(diǎn)一般放在前端，因?yàn)榭蛻舳穗x用戶最近，且有些邏輯是放在客戶端，點(diǎn)擊后不一定都會發(fā)送服務(wù);而服務(wù)端是以展示為主，可以記錄整個(gè)下發(fā)的報(bào)文數(shù)據(jù)，詳細(xì)分析顯示轉(zhuǎn)化比。

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

【本文為51CTO專欄作者“李寧”的原創(chuàng)稿件，轉(zhuǎn)載請通過51CTO聯(lián)系作者獲取授權(quán)】

戳這里，看該作者更多好文