4月14日晚，DTalk邀請(qǐng)到了譙洪敏老師，他是滴滴上海前端團(tuán)隊(duì)負(fù)責(zé)人环形，前陸金所移動(dòng)前端團(tuán)隊(duì)負(fù)責(zé)人，進(jìn)行了一次關(guān)于《前端數(shù)據(jù)采集與分析的那些事第二彈：前端篇》的微信群線上主題分享衙傀。
活動(dòng)分享了埋點(diǎn)需求的整理原則抬吟，埋點(diǎn)的命名規(guī)范，埋點(diǎn)流程規(guī)范统抬，埋點(diǎn)上報(bào)的解決方案火本，以及一些實(shí)際場(chǎng)景中的注意事項(xiàng)。譙洪敏老師會(huì)在4月21日的 DTalk上海數(shù)據(jù)驅(qū)動(dòng)實(shí)戰(zhàn)案例研討Workshop中深入幫助參會(huì)團(tuán)隊(duì)解決數(shù)據(jù)埋點(diǎn)方面的問(wèn)題蓄喇。
一发侵、埋點(diǎn)需求整理原則
其實(shí)就是整理一系列問(wèn)題交掏，并基于這些問(wèn)題確定埋點(diǎn)需求妆偏，我作為FE的RD，針對(duì)這些原則盅弛，我們至今也沒(méi)有真正全面的做到钱骂，但是如果遵循這些原則，將會(huì)受益良多（也歡迎大家補(bǔ)充問(wèn)題內(nèi)容）：
HOW LONG：
埋點(diǎn)可用周期是多久挪鹏，持續(xù)幾個(gè)版本可以见秽？
生命周期結(jié)束后是否可以考慮下掉？
HOW MUCH：
現(xiàn)有的埋點(diǎn)哪些可以滿足我的部分埋點(diǎn)需求讨盒？
哪些現(xiàn)有的埋點(diǎn)可以替代我要的部分埋點(diǎn)解取？
新的埋點(diǎn)有多少？這些埋點(diǎn)是否是最必要的返顺？
HOW：
怎樣證明新功能效果禀苦？
需要哪些埋點(diǎn)？
我該怎么埋這些點(diǎn)遂鹊？
部分埋點(diǎn)的計(jì)算邏輯是什么振乏？
數(shù)據(jù)結(jié)果怎么看？漏斗秉扑？同環(huán)比慧邮？
WHO：
我的產(chǎn)品設(shè)計(jì)面對(duì)的用戶群里是誰(shuí)？
用戶特征是什么？
這部分特征用戶對(duì)功能預(yù)期的數(shù)據(jù)結(jié)果是什么误澳？
用戶習(xí)慣是什么耻矮？
WHAT：
我的新產(chǎn)品是什么？
新產(chǎn)品包含哪幾個(gè)模塊脓匿？
WHY：
- 涉及新產(chǎn)品的目的是什么淘钟，為了解決什么問(wèn)題？
WHERE：
新功能展示在產(chǎn)品端的哪個(gè)位置陪毡？
在哪些版本生效米母？
哪些功能的展示或作用在哪里需要跟服務(wù)端等交互？
WHEN：
功能是在用戶場(chǎng)景什么時(shí)候調(diào)用產(chǎn)生毡琉？
調(diào)用過(guò)程中什么時(shí)候和服務(wù)端交互铁瞒？
功能調(diào)用正常情況下需要大概需要多長(zhǎng)時(shí)間？
什么情況會(huì)影響調(diào)用結(jié)果桅滋？
調(diào)用有風(fēng)險(xiǎn)的時(shí)候慧耍，是否需要加監(jiān)測(cè)？
二丐谋、埋點(diǎn)命名規(guī)范
我們當(dāng)前的做法是埋點(diǎn)名稱只能是由字母芍碧、數(shù)字抽莱、下劃線組成扫外，并保證在應(yīng)用內(nèi)唯一悼院，sw是展示豹储，ck是點(diǎn)擊偶惠。
常用規(guī)則的舉例如下：
比如行為埋點(diǎn)： {團(tuán)隊(duì)|業(yè)務(wù)|角色}{組件|頁(yè)面}{具體元素}_{動(dòng)作} 示例：yourteam_fc_all_msg_ck
autoplatform_flowtab_sw ： autoplatform代表業(yè)務(wù)線庇楞，flowtab 代表功能憋活，sw代表頁(yè)面操作铝耻，sw是展示猪落，ck是點(diǎn)擊
uber_comt_share_ck ：uber業(yè)務(wù)線贞远，comt評(píng)價(jià)組件，share分享按鈕笨忌，ck點(diǎn)擊
三蓝仲、埋點(diǎn)流程規(guī)范
埋點(diǎn)作為重要的資產(chǎn)，是數(shù)據(jù)生產(chǎn)的第一步官疲，那為什么制定規(guī)范占首要位置袱结？
因?yàn)?0%用戶反饋找不到埋點(diǎn)，根本無(wú)法進(jìn)行數(shù)據(jù)分析袁余，造成這個(gè)問(wèn)題的原因包括：
埋點(diǎn)語(yǔ)義不明確擎勘，同一個(gè)按鈕存在多種描述，不易檢索颖榜；
無(wú)用/重復(fù)埋點(diǎn)太多棚饵，干擾了正常埋點(diǎn)數(shù)據(jù)煤裙，一個(gè)公司可能已經(jīng)包括上千個(gè)埋點(diǎn)信息，而且還在按照很高的速度迭代增長(zhǎng)噪漾；
大量存量埋點(diǎn)Owner離職或者轉(zhuǎn)崗硼砰，導(dǎo)致大量僵尸埋點(diǎn)信息，找不到歸屬方和解釋方欣硼；
如果你發(fā)現(xiàn)每天有大量埋點(diǎn)錯(cuò)誤反饋题翰，并導(dǎo)致很多錯(cuò)誤的分析結(jié)論，一個(gè)錯(cuò)誤的分析結(jié)果還不如沒(méi)有數(shù)據(jù)分析結(jié)果诈胜。造成這個(gè)問(wèn)題的原因包括：
前端埋點(diǎn)涉及復(fù)雜的交互豹障，難以找準(zhǔn)埋點(diǎn)位置；
埋點(diǎn)的驗(yàn)收流程不完善焦匈，沒(méi)有經(jīng)過(guò)測(cè)試和產(chǎn)品經(jīng)理的測(cè)試和驗(yàn)收血公，驗(yàn)證不完備；
好的埋點(diǎn)需求應(yīng)該和業(yè)務(wù)功能需求同等重要缓熟，也需要經(jīng)歷軟件開發(fā)的整個(gè)生命周期累魔，如果能嚴(yán)格按照一個(gè)規(guī)范的流程處理埋點(diǎn)，以上問(wèn)題會(huì)得到更好的解決：
規(guī)范內(nèi)容：
1够滑、需求階段：
確定埋點(diǎn)信息垦写，核心包括五方面信息：事件ID、埋點(diǎn)名稱彰触、埋點(diǎn)描述梯投、埋點(diǎn)屬性以及截圖。
舉例：
快車頁(yè)面打車的埋點(diǎn)信息為：
埋點(diǎn)ID為：gulf_p_f_home_order_ck
埋點(diǎn)名稱為：呼叫快車
埋點(diǎn)描述：在快車首頁(yè)點(diǎn)擊呼叫快車按鈕渴析。
如何落地：
如果不按照規(guī)則和流程埋點(diǎn)將不會(huì)上報(bào)相關(guān)數(shù)據(jù)晚伙，制定強(qiáng)制規(guī)定吮龄。
開發(fā)什么功能：
埋點(diǎn)全文檢索能力俭茧、自動(dòng)找到重復(fù)埋點(diǎn)（語(yǔ)義相近或者數(shù)據(jù)相近）功能。
2漓帚、開發(fā)階段：
務(wù)必和開發(fā)溝通母债，并讓開發(fā)在完全理解業(yè)務(wù)語(yǔ)義的情況下，在前端按照埋點(diǎn)代碼規(guī)范進(jìn)行埋點(diǎn)尝抖。
舉例：
比如針對(duì)商品購(gòu)買按鈕毡们，在前端點(diǎn)擊方法的第一行調(diào)用SDK，最好也傳入文本字面描述昧辽。
如何落地：
靜態(tài)代碼檢查衙熔。
開發(fā)什么功能：
開發(fā)探測(cè)每個(gè)埋點(diǎn)對(duì)應(yīng)到的代碼文件和代碼行，開發(fā)根據(jù)人均事件量級(jí)進(jìn)行監(jiān)控報(bào)警功能搅荞。
3红氯、測(cè)試階段：
務(wù)必和測(cè)試溝通框咙，并讓測(cè)試在完全理解業(yè)務(wù)語(yǔ)義的情況下，通過(guò)CodeReview和埋點(diǎn)測(cè)試兩種方式對(duì)埋點(diǎn)正確性進(jìn)行驗(yàn)證痢甘。
舉例：
比如針對(duì)商品購(gòu)買按鈕埋點(diǎn)喇嘱，需要檢查埋點(diǎn)測(cè)試中上傳數(shù)據(jù)中事件ID、屬性是否符合定義塞栅，另外觸發(fā)時(shí)機(jī)是否正確者铜。
如何落地：
規(guī)定如果未經(jīng)測(cè)試的埋點(diǎn)不允許上報(bào)埋點(diǎn)數(shù)據(jù)。
開發(fā)什么功能：
提供所見即所得的埋點(diǎn)測(cè)試平臺(tái)放椰。
4作烟、驗(yàn)收階段：
確保相關(guān)人員在完全理解業(yè)務(wù)語(yǔ)義的情況下，可以通過(guò)與自比較和他比較的方式來(lái)進(jìn)行驗(yàn)證砾医。
舉例：
自比較驗(yàn)證：同一APP某一個(gè)業(yè)務(wù)線的購(gòu)買冒泡數(shù)量一定要小于所有業(yè)務(wù)線的冒泡數(shù)合計(jì)俗壹；
他比較驗(yàn)證：前端某業(yè)務(wù)點(diǎn)數(shù)量和對(duì)應(yīng)服務(wù)端數(shù)據(jù)應(yīng)該基本相當(dāng)。
如何落地：
規(guī)定如果未經(jīng)驗(yàn)證的埋點(diǎn)不允許上報(bào)埋點(diǎn)數(shù)據(jù)藻烤。
開發(fā)什么功能：
提供埋點(diǎn)實(shí)時(shí)數(shù)據(jù)查詢绷雏。
5、清理階段：
確認(rèn)完全理解語(yǔ)義的情況下怖亭，可對(duì)業(yè)務(wù)發(fā)生巨大變化或者不在維護(hù)的埋點(diǎn)進(jìn)行廢棄涎显。
舉例：
百度糯米合并餓了么后，埋點(diǎn)在經(jīng)歷產(chǎn)品大改版后已經(jīng)和其他業(yè)務(wù)線合并兴猩，需要廢棄之前的遺留埋點(diǎn)期吓。
如何落地：
3個(gè)月以上未被使用的埋點(diǎn)、1個(gè)月以上數(shù)據(jù)為0的埋點(diǎn)自動(dòng)廢棄倾芝。3個(gè)月后使用次日會(huì)自動(dòng)開啟采集讨勤。
開發(fā)什么功能：
根據(jù)規(guī)則提供針對(duì)未使用埋點(diǎn)的計(jì)算、并自動(dòng)廢棄晨另。
可以做一個(gè)表用來(lái)記錄:
四潭千、關(guān)于埋點(diǎn)上報(bào)的解決方案
一般會(huì)實(shí)現(xiàn)上個(gè)模塊，Event收集器借尿，Event緩存器刨晴，和Event上報(bào)器。
1路翻、Event上報(bào)模式
除了用戶個(gè)人不希望耗費(fèi)流量以外狈癞，也可能會(huì)因?yàn)槿蹙W(wǎng)及斷網(wǎng)情況，如果確保數(shù)據(jù)不丟失茂契，基于這些問(wèn)題而誕生的上傳策略蝶桶，來(lái)設(shè)計(jì)如何上報(bào)已收集的所有事件數(shù)據(jù)。上報(bào)一般包括針對(duì)內(nèi)存實(shí)時(shí)數(shù)據(jù)的上報(bào)和本地持久化數(shù)據(jù)上報(bào)兩個(gè)部分掉冶，分別介紹一下它們的上報(bào)策略與實(shí)現(xiàn)方式真竖。
2儡蔓、內(nèi)存埋點(diǎn)數(shù)據(jù)的實(shí)時(shí)上報(bào)
針對(duì)內(nèi)存埋點(diǎn)數(shù)據(jù)的上報(bào)策略一般如下：
基于時(shí)間間隔：每隔 n秒（時(shí)間間隔可以根據(jù)公司的業(yè)務(wù)情況自定義）
基于數(shù)據(jù)條數(shù)：每累積 n條數(shù)據(jù)（條數(shù)可以自定義）
不間斷實(shí)時(shí)上報(bào)，如果是低頻率疼邀，數(shù)據(jù)量小喂江，實(shí)時(shí)性要求高的數(shù)據(jù)可以不設(shè)限制
上述條件滿足時(shí)，便會(huì)觸發(fā)從內(nèi)存中讀取數(shù)據(jù)旁振，并執(zhí)行上傳操作获询。Native可以創(chuàng)建了一個(gè)并發(fā)隊(duì)列，H5會(huì)基于瀏覽器并發(fā)發(fā)送拐袜。
3吉嚣、本地持久化數(shù)據(jù)的延遲上報(bào)
為了盡早的上傳本地持久化埋點(diǎn)數(shù)據(jù)，以防用戶卸載 App或者關(guān)閉瀏覽器造成本地?cái)?shù)據(jù)的丟失蹬铺，針對(duì)本地持久化數(shù)據(jù)的上傳策略如下：
Native相關(guān)：
（1）App 冷啟動(dòng)
（2）App 進(jìn)入前臺(tái)
（3）App入后臺(tái)
HTML5尝哆、Hybrid相關(guān)：
（1）localstorage，瀏覽器關(guān)閉埋點(diǎn)數(shù)據(jù)并不會(huì)被刪除甜攀，如果用戶再次訪問(wèn)秋泄，會(huì)啟動(dòng)上報(bào)
（2）基于Native提供的bridge，讓Native幫忙持久化數(shù)據(jù)规阀，并在再次進(jìn)入時(shí)恒序，啟動(dòng)上報(bào)
這里也可以創(chuàng)建一個(gè)單獨(dú)的串行隊(duì)列，來(lái)實(shí)現(xiàn)對(duì)本地持久化數(shù)據(jù)的逐個(gè)上報(bào)谁撼。
另外我們?cè)谇岸寺顸c(diǎn)中也遇到過(guò)一些注意事項(xiàng)歧胁，整理如下，希望對(duì)大家有所幫助厉碟。
注意事項(xiàng)
1喊巍、一些埋點(diǎn)安全性問(wèn)題：
如果你使用普通的http 協(xié)議，在數(shù)據(jù)傳輸?shù)倪^(guò)程存在被劫持(包括不限于：JS代碼注入等)的可能性箍鼓，造成H5頁(yè)面中出現(xiàn)諸如：未知的廣告或者原網(wǎng)頁(yè)被重定向等問(wèn)題崭参。為了降低此類事件發(fā)生的可能性，建議最好使用https 協(xié)議（倡導(dǎo)全站https）袄秩，以確保數(shù)據(jù)傳輸過(guò)程的完整性阵翎，安全性逢并。
2之剧、版本迭代的時(shí)候埋點(diǎn)需要注意什么？
如果是公用模塊砍聊，可以非常放心安全的全量遷移埋點(diǎn)背稼；
如果是新增模塊，那就需要注意是否遵循了最新的埋點(diǎn)規(guī)范玻蝌，有沒(méi)有重復(fù)的埋點(diǎn)命名存在蟹肘，埋點(diǎn)是否符合業(yè)務(wù)邏輯词疼；
如果是下線模塊，那就需要評(píng)估下線后對(duì)數(shù)據(jù)的影響范圍帘腹，而且要第一時(shí)間充分周知相關(guān)方贰盗，讓各方參與評(píng)估；
如果是更新模塊阳欲，需要評(píng)估在原有埋點(diǎn)上需要修改的埋點(diǎn)內(nèi)容舵盈，是否需要重新埋點(diǎn)，刪除不需要的埋點(diǎn)球化，而且要修改功能的數(shù)據(jù)承接秽晚。
本文作者：
譙洪敏老師，DTalk核心專家組成員筒愚，滴滴上海海浪前端團(tuán)隊(duì)負(fù)責(zé)人赴蝇，前陸金所移動(dòng)前端團(tuán)隊(duì)負(fù)責(zé)人，主要專注與前端工程化巢掺、前端Web安全及前端性能優(yōu)化句伶，有豐富的前端埋點(diǎn)技術(shù)工程、數(shù)據(jù)處理和數(shù)據(jù)質(zhì)量的經(jīng)驗(yàn)陆淀。
干貨專訪和文章
【DTalk分享】黃一能：互聯(lián)網(wǎng)產(chǎn)品運(yùn)營(yíng)決策中用戶畫像的核心作用直播回顧
【DTalk分享】陳抒：產(chǎn)品設(shè)計(jì)中的用戶畫像直播回顧
【DTalk分享】吆喝科技王曄：A/B測(cè)試最佳實(shí)踐直播回顧
【DTalk精華】網(wǎng)易鄭棟：前端數(shù)據(jù)采集與分析的那些事第一彈: 從數(shù)據(jù)埋點(diǎn)到AB測(cè)試
【DTalk精華】滴滴出行譙洪敏：前端數(shù)據(jù)采集與分析的那些事第二彈：企業(yè)如何選擇自動(dòng)埋點(diǎn)和可視化埋點(diǎn)
【DTalk精華】滴滴出行譙洪敏：前端數(shù)據(jù)采集與分析的那些事第三彈：埋點(diǎn)需求整理原則于埋點(diǎn)流程規(guī)范
【DTalk專訪】滴滴譙洪敏：百家爭(zhēng)鳴的前端技術(shù)時(shí)代
【DTalk思考】顧青：互聯(lián)網(wǎng)團(tuán)隊(duì)的數(shù)據(jù)驅(qū)動(dòng)能力從哪里來(lái)熄阻？
【DTalk專訪】彭圣才：AI超越人類大腦，是一場(chǎng)「別有用心者」的騙局嗎倔约？
【DTalk專訪】翁嘉頎：AI行業(yè)現(xiàn)階段最需要什么樣的人才秃殉？
【DTalk專訪】趙華：攜程怎么把機(jī)器學(xué)習(xí)與實(shí)際業(yè)務(wù)相結(jié)合？
【DTalk專訪】網(wǎng)易鄭棟：BI浸剩、可視化數(shù)據(jù)產(chǎn)品和大數(shù)據(jù)的幾個(gè)核心問(wèn)題
【DTalk回顧】美團(tuán)點(diǎn)評(píng)沈國(guó)陽(yáng)：我們?cè)谡動(dòng)脩舢嬒竦臅r(shí)候到底在談什么钾军？
【DTalk專訪】王曄：谷歌數(shù)據(jù)如何用于決策？
