每個版本中都可能會有數(shù)據(jù)埋點工作，版本中的數(shù)據(jù)埋點工作是怎么運轉(zhuǎn)的呢？本文作者將來討論客戶端埋點那些事兒。

“……數(shù)據(jù)表明這次xxx的優(yōu)化效果明顯……”總結(jié)會上，老K的一句話突然引起了小L的注意，數(shù)據(jù)表明？這些數(shù)據(jù)從哪來的？項目過程中自己好像沒有關(guān)注這塊，是從開發(fā)那邊直接獲取的嗎？還是有什么工具……會后，小L將一股腦的好奇和疑問拋向Q姐。

只見Q姐不緊不慢喝了口茶，然后說道：“我們通常通過客戶端埋點來收集數(shù)據(jù)，然后將收集的數(shù)據(jù)進(jìn)行分析并呈現(xiàn)出來?！?/p>

“啊?。靠蛻舳寺顸c收集數(shù)據(jù)是什么意思?。俊毙一頭霧水地問道。

“給你舉個例子吧。諾，你看，比如你想知道昨天網(wǎng)易新聞客戶端里有多少人點過發(fā)現(xiàn)按鈕，一種很直接的辦法就是在發(fā)現(xiàn)這個按鈕做埋點事件，當(dāng)觸發(fā)后就會被記錄下來，然后就可以用作統(tǒng)計了”，Q姐接著說，“杭研有相應(yīng)的統(tǒng)計支撐部門，他們會將這些數(shù)據(jù)進(jìn)行處理并展現(xiàn)在平臺上，便于查看”。

聽到這，小L似乎明白了，同時又陷入了另外的問題，如果是這樣的，那么每個版本中都可能會有數(shù)據(jù)埋點工作，版本中的數(shù)據(jù)埋點工作是怎么運轉(zhuǎn)的呢？而這些問題似乎只有小L自己去找答案了。

經(jīng)過一番打聽，了解到目前版本的埋點行為由需求owner主動發(fā)起，運營組的一位同事進(jìn)行補充。同時也存在幾個問題：

1. 有時候會出現(xiàn)未提埋點需求的情況，待上線后要查看相關(guān)數(shù)據(jù)時才想起，此時也只能等下個版本再進(jìn)行埋點。
2. 由于不同的人可能會在同一功能不同版本上交叉負(fù)責(zé)，有些交互上的變化需要埋點數(shù)據(jù)同樣做更新，但會由于信息的不透明和未及時溝通而導(dǎo)致例如：看到的數(shù)據(jù)其實是另外埋點的數(shù)據(jù)，前一個人的漏斗分析失效等這樣那樣的問題。
3. 埋點數(shù)據(jù)無測試和驗收環(huán)節(jié)，需求owner們等版本上線后去查看相關(guān)數(shù)據(jù)，此時如果發(fā)現(xiàn)有問題，只能等下個版本再更新。

小L一邊用筆寫下這些問題，一邊嘴上還說著看我怎么逐個消滅你們！

問題1、2有個根本原因就是對數(shù)據(jù)埋點的重視程度不夠，由于不是每個需求都有埋點工作，所以這個非必選項在意識不夠的情況下容易被忽略?？墒切枨髈wner怎么會不重視數(shù)據(jù)反饋的實際效果呢？又經(jīng)過一番摸底后才知道，原來很多人是沒有直接的數(shù)據(jù)權(quán)限，那么前面的疑問就自然消失了，要解決的問題或許就變成了：

1. 提高大家對數(shù)據(jù)的重視程度；
2. 提供大家可見的數(shù)據(jù)。

找到了問題，方案就不會太遠(yuǎn)了，小L想著想著不禁臉上露出了燦爛的笑容。

再看看問題2，除了剛才上述說的原因外，還需要解決埋點數(shù)據(jù)透明性的問題，整個系統(tǒng)的埋點數(shù)據(jù)如果是公開透明的，那么每個需求owner就可以方便的查看他本次所改動的部分之前是怎樣的情況。然后有變化隨時更新，大家一起來維護(hù)這張表。

問題3需要跟測試和開發(fā)們溝通下是否有好的辦法，經(jīng)過一番溝通，好的是我們可以在發(fā)布前驗證埋點數(shù)據(jù)的有、無和對應(yīng)屬性的正確性，不好的是目前暫時無法驗證數(shù)據(jù)的精準(zhǔn)度，就是用戶在客戶端觸發(fā)了事件我們可以驗證事件是否有以及是否對，但還不能精準(zhǔn)確認(rèn)用戶操作的次數(shù)和后臺顯示是匹配的，小數(shù)據(jù)可以驗證，大數(shù)據(jù)就難落實了。這個我們可以逐輪迭代進(jìn)行完善。

小L將想法跟相關(guān)負(fù)責(zé)人溝通后，很快一致決定召開一次埋點培訓(xùn)/動員會。目的也很清晰：

1. 提高大家對數(shù)據(jù)埋點的重視程度；
2. 解決大家看相關(guān)數(shù)據(jù)的問題；
3. 建立數(shù)據(jù)埋點的整個流程。

所以，大會也就分為三部分：

1. 領(lǐng)導(dǎo)講話，目的在于提高大家對數(shù)據(jù)埋點的重視程度。
2. 介紹埋點業(yè)務(wù)知識和數(shù)據(jù)考察核心指標(biāo)等，用于讓大家了解我們常規(guī)考察的核心指標(biāo)是什么。
3. 介紹數(shù)據(jù)埋點工作流程，在整個版本過程中有哪些環(huán)節(jié)以及如何開展。

前面兩點就不多介紹了，第三點做個介紹供大家參考。

數(shù)據(jù)埋點工作在整個版本過程分為三個階段：計劃、執(zhí)行和驗收階段。

（1）計劃

需求owner在確定需求同時提埋點需求，并根據(jù)埋點標(biāo)準(zhǔn)格式（根據(jù)標(biāo)準(zhǔn)模板）提交指定同事及統(tǒng)計組同事進(jìn)行初步review，用于確認(rèn)埋點數(shù)據(jù)的格式以及合理性，比如有些事件可以做合并，將多個事件轉(zhuǎn)變?yōu)橐粋€事件多個屬性等。指定同事確認(rèn)沒有問題后提交開發(fā)進(jìn)行確認(rèn)和埋點。

（2）執(zhí)行

各端開發(fā)根據(jù)已確認(rèn)的埋點需求文檔進(jìn)行埋點。

（3）驗收

分為三步：

1. 在測試階段，開發(fā)會提供埋點debug包，需求owner可以通過觸發(fā)事件然后界面顯示所被觸發(fā)的事件進(jìn)行簡單的驗證；
2. 上線前，指定同事會通過平臺查看埋點數(shù)據(jù)的情況，做二次確認(rèn)；
3. 上線后，需求owner會觀察線上數(shù)據(jù)是否有異常；

會后小L高興的告訴Q姐整個過程，只見Q姐還是不緊不慢地喝了口茶說道，“恩，做的不錯！是個好的開始?！?/p>

“好的開始？”小L疑惑地看著Q姐。

“沒錯，是個好的開始，現(xiàn)在是給大家了一個guideline，具體實施的時候需要仔細(xì)跟進(jìn)，看看存在什么問題，怎么進(jìn)一步優(yōu)化，真正執(zhí)行的時候你會學(xué)到更多，加油吧！哈哈~”

Q姐笑著走開了。

作者：劉煦萍/Abble，曾先后在摩托羅拉、諾基亞西門子任職。現(xiàn)為網(wǎng)易資深項目經(jīng)理，先后服務(wù)于網(wǎng)易云存儲、客戶端安全、易信、云信、七魚等產(chǎn)品，專注于流程優(yōu)化、版本交付和團(tuán)隊成長。愛好旅游、乒乓和美食。《網(wǎng)易一千零一夜》主要作者之一。

本文由 @網(wǎng)易杭研項目管理（微信公眾號：NetEasePM） 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。