Hey 有埋點嗎？我想看個數據

【 為什麼做埋點？】

數據驗證對於產品設計效果驗證的重要性不言而喻，但在實際工作中，種種原因導致分析查看數據成了一件非常麻煩的事。如我們正在做的一款分期支付產品，產品經理更在乎用戶的消費金額、逾期率等等業務數據，而從體驗層面上講，用戶在關鍵頁面的停留時長、流失率等是重要數據。為了彌補在這一xx的遺漏，作為交互設計師我的參與度從一開始跟產品要數據，說明埋點重要性；到後面與產品一起整理埋點內容；到現在直接自己整理、補充埋點內容，與前後端溝通，區分埋點上線的優先順序、建立更好的數據採集規範，也運用得到的數據進行後續分析。

有人會說，這個不是產品經理的工作嗎？但是當產品的側重點不在這裡時，為了守護好用戶體驗，就要求設計師前行一步，獲取所需內容（如數據），在一定程度上指導後面的設計方向。大家採用不同的方式，同心協力打造更好產品。當然當規範建立好以後，後期不必再繼續自己完成，可以交給其他人去做。

【不同限制條件下的行動方式不同】

實際工作中需要根據自己公司的數據採集提供情況決定埋點的方式。如之前在大廠實習時，平台本身提供了大量的數據採集工具，也有專門的數據分析團隊給出結果，此時我們的工作就會簡單一些。

目前我司BI部門提供的數據採集工具有一定局限性，具體埋點過程中：

一方面要基於BI平台特點，盡量把數據要求提的清楚明白。了解數據識別的可行性和後台數據分析的邊界，區分哪些是能夠直接獲取的，哪些一定要內部的前後端主動埋點提供數據，有針對性的進行差異化處理。如之前我們製作單頁後，url中？後面的內容BI就無法識別，對於這類內容為了從而保證能夠看到更加精準的數據，需要我們的開發主動埋點，從而補充數據完整性。

另一方面，對於一些不太合理或者不夠好用的功能，可以根據需要主動向BI部門提出需求，說明使用痛點和新功能的重要性後，由BI評估是否可行，如果可以那麼後續方便很多，如果不行，也可以考慮要求拿到數據介面，然後自己團隊內部頁面分析呈現數據。

對於此類需求，重點要考慮成本問題，如果數據需求的周期性較長，如一個月收集一次，那麼短期內人工提取也是可行的。

【埋點的優先順序】

產品設計評審過後，馬上補充埋點，內容過多後，可能會出現量太大而需花大量時間完成的情況。容易勞心勞力，且遺落內容。

1. 核心數據：

埋點前思考好數據採集的目的，對於核心頁面、核心用戶路徑、一些特殊觀察點，並根據目的拆分數據，必須進行完整的埋點，或確保有地方可以查看數據。上線後觀測數據，然後再補充其他更多的，以及遺漏的內容。

2. 其他數據

首先保證所有可點擊項、跳轉頁面等都有完整的埋點需求，然後根據項目時間情況分步完成，除了上面提到的核心數據之外，有些數據採集一開始不是很清楚其目的，但是後面在查看時卻能夠帶來意想不到的啟發。

【如何保證埋點清晰不遺漏？】

幾個實用性規則：

1. 按照項目 - 端 - 大功能模塊 - 頁面 - 埋點項的專屬名稱為維度分別整理埋點內容

2. 命名精簡，清晰易懂，具有獨一性

【一般形式】

項目名_操作_具體事件[_其他備註]（中括弧內為可選）

具體事件可以駝峰單片語合

平時幾乎沒有寫代碼的情況，因此命名時為了更容易讀懂內容，想當然的使用了中劃線-、斜杠/等符號，但與開發核對時才發現，這樣的方式進入代碼後會引起混亂，根本不能使用，因此一起整理了如下的命名規範，供後續埋點時參考。

【事件ID規範】

1）字母、數字、下劃線組合，長度≤50

2）不能以數字開頭

3）單詞以下劃線分隔

4）單詞盡量精簡，以名詞為主，請勿主謂賓定狀補都寫全，沒有意義。

命名一個容易記憶 & 後期容易識別的，有邏輯關係的。確保埋點名稱的獨一性，避免低級錯誤。以錯誤碼為例，之前產品埋點時使用了wrongmessage1~100的表述方式，每次使用都要回去查看對應表格，麻煩低效。且在後續檢查或補充埋點時容易出錯。

【使用簡寫】

「需在內容可輕鬆識別 & 長度精簡間尋找平衡。」避免url過長出現問題。

* MA — modal_appear 彈窗出現

* ST — StayTime 頁面停留時間

* CB — ClickButton 點擊按鈕

3. 合理分類，分合清晰

有時，可以打破頁面的限制，提取出全局公共的模塊統一維護。也可以把同類內容的埋點放在一起。

eg1. 把核心流程中涉及到的多個用戶協議整理到一起。

eg1. 我們的某個產品中有大量的表單內容，使用一個大的Form把所有表單報錯放在一起，既減輕了前端埋點的工作量，又方便後期分析不同表單項報錯的佔比，只要能夠在查看參數時能夠看到url鏈接，就能有效區分錯誤來源，從而幫助我們定位具體的錯誤原因。

4. 用好參數，提高效率

另外當同一個內容涉及不同屬性時，應搭配使用不同的參數進行區分，方便後期修改、拓展和區分查看，命名也更規範統一。否則可能出現大量的單一埋點。

eg.同一個頁面採集用戶信息時，需要針對新老用戶分別記錄數據，就適合把新用戶、老用戶作為內容項的參數進行埋點。 {user: new || old}

【如何保證埋點不遺漏？】

目前為了提高團隊協作效率和可用性，我們採用Google表格整理了「明確的數據埋點需求表」，並實時同步調整。對於新的調整內容標註不同的顏色，並在群里同步所有相關人員。

我在表格中補充了針對「需求、走查、測試」的不同勾選欄，並基於我們的業務特徵區分了「PC、mc」，實際產品的兩端功能有差異時，相應的埋點也是不同的，對應埋點條目做好端的勾選，方便開發確認信息，減少多次溝通的成本。

【寫在最後的幾個注意事項】

1. 你以為自己以為的可能不是你以為的，你以為別人跟你一樣以為的，其實不是別人以為的你以為的，或者別以人為Ta以為的。所以一定要明確的把需求講清楚。eg. 頁面停留時長，要考慮各種進入和跳離頁面的情況，盡量避免誤讀。

2. 早定規則，嚴格執行

舊的不規範內容：按優先順序逐步整理更新。否則越積越多，龐大的數量會讓人更不願意整理，後患無窮。

新的內容：按照規則補充進去。

讓信息的規範性一致性更佳，方便後續查看和補充。有新的夥伴加入時也能降低認知成本。

3. 和開發哥哥處好關係。需要數據支持就趕緊找人解決。他們的敬業和耐心會讓你效率更高，也能夠及時發現需求中不恰當、有所遺漏的地方，有時候他們也會提出更簡便的解決方案。

4. 警惕反對和質疑聲，以正確態度回應

當你認定埋點是非常重要的事情時，面對質疑和反對，請有理有據的說明需求原因，並在後續實際使用數據解決問題，讓大家意識到它的重要性。

5. 做好產品發生變更記錄！！做好產品發生變更記錄！！做好產品發生變更記錄！！重要的事情說3遍。如果沒有清晰記錄功能內容的改動點，可能導致後續看到數據時分析出現偏差，影響結果指向。

6. 埋點只是獲取用戶反饋的一種手段，後續的數據分析和創新優化方案才是重點。最近正在考慮學習數據建模和分析，目前市面上也有很多便捷的埋點數據（eg. Growing io），我也在研究學習中。經歷過這次埋點後，我發現後續自己要學習的東西還有很多。前進路上，勿忘初心。