本文根據筆者的心得體會，跟大家分享，產品經理工作中做數據埋點的一些經驗和看法。
作為一名產品經理，你必然知道數據分析對於產品的生命週期的重要性。
解決用戶需求，解決痛點是產品的立足之根本；運營是傳遞產品價值的重要手段；而數據，則給產品和運營提供了指向的重要意義。
數據，既是產品分析的基礎，同樣，數據的採集和來源也是每個產品經理頭疼的地方。
好的數據收集和分析，可以輔助產品經理更好的瞭解用戶，讓團隊少做一些無用需求，或者在錯誤的需求方向上停止腳步，遏制一些異想天開的想法。
一、需求收集和分析
1.1 梳理產品，清晰產品的脈絡和架構
梳理產品的產品結構
首先，先別急著馬上就去建立埋點，此處應該是優先覆盤當前的產品或者模塊，整理出產品結構和頁面結構。梳理出產品完整的結構、頁面邏輯，這些都是決定了用戶在使用產品時的任務路徑，所以需要做一次完整的覆盤。
梳理產品頁面流程
有了基礎的梳理後，我們需要再將業務或頁面流程梳理出來。將用戶與系統的交互故事完整的梳理出來。藉助它，你更容易知道流程中的潛在地雷是什麼，哪裡的效率比較低，有助於系統化、全局化、周全性的思考。我們後續可以在每個流程步驟，考慮好用戶的目的、場景，提煉出重要指標。
1.2 收集統計，明確統計目的和意義
如果是產品經理做埋點收集，也可以從以下的幾點思路出發：
功能流程轉化率：關鍵業務的留存轉化指標尤為重要，用戶在哪個關鍵節點發生了流失，
改版調整：如果產品做了改版，肯定會在一些關鍵入口進行了佈局上的優化，那麼埋點統計有利於收集變化前後的不同。產品是否更加聚焦的解決了用戶的痛點，還是
用戶軌跡：用戶來到了你的產品，第一件事情是做什麼，然後還會做什麼。如果你的產品，滿足了用戶的需求，那麼主要路徑我們是可以猜測得到的。但唯獨那麼一小塊路徑，是否會挖掘出更深層次的需求。
面向運營方面的，一次完整的活動運營，在工作的前中後階段，對數據的需求都不太一樣：
活動前，需要了解面向的用戶、興趣、標籤、來源，入口的引導和佈局，有了這些，才可以更好地評估面向對象、渠道。而這些，在產品早期建立數據的時候，需要第一時間就考慮的問題。
活動中：對數據的時效性要求更高，落地頁或者活動頁面的PV/UV、活動參與數、頁面登陸數、中獎數、兌獎數、活動轉化人數/金額以及用戶信息等。必要的時候根據數據反饋及時調整問題和優化。
活動後：更加註重反饋和總結，對活動的覆盤；本次活動的帶來了多少的訪問流量，轉化率如何，不同渠道過來的用戶表現如何，最終這些用戶轉化成活躍用戶的又有多少？
其他：
Boss：“小李啊，這個活動上了，但是效果不怎麼樣，你覺得哪裡可以再優化優化？”
小李：“偉大的老闆，是這樣的，關於這次活動的，我整理了一份報表，通過分析這些數據後，有一個方案，請看看….”
不管來自哪個方面的需求，收集數據必然是來源於分析目的，基於目的，才會有分析指標，才會有數據的收集。
1.3 根據產品流程設計指標
在前面做了一系列的功課之後，我們就開始要根據產品的功能流程或者頁面結構，定義好分析的目的，剝離關鍵流程，提煉關鍵指標。
購物環節：寶貝詳情頁>加入購物車>訂單確定>訂單提交>支付>支付結果
在這個過程中，你可能需要採集到從詳情頁到購物車的轉化，從詳情頁到訂單確認的轉化，訂單從確認到支付成功之間的漏斗模型。
那麼對應的可以為詳情頁UV、購物車添加事件、訂單確認事件、訂單提交事件、支付事件、支付成功反饋事件。
註冊流程：進入註冊>註冊信息填寫>獲取驗證>註冊成功
對應的可能想要了解到註冊流程的轉化，那麼可以主要採集註冊按鈕點擊事件、提交信息事件、獲取驗證事件、註冊成功事件，再加上能夠統計到渠道包信息，那麼也就可以分析出，不同渠道下的用戶轉化效果。
二、提出需求
可能前面的內容，大部分的乾貨可能會講的比這個更清楚了，那麼筆者在這裡更多的是想要跟大家分享一下，如何提出埋點的需求。
有些公司可能會有自己獨立的數據系統，用於收集用戶數據。但是大部分公司而言，更多的是專注業務本身，所以埋點也是用了第三方。
目前有很多做埋點和數據支持的公司，例如友盟、諸葛IO、GrowingIO、神策等等，也有埋入移動端、H5、Web等，在進行選擇的時候，不妨多進行對比，沒有哪家最好，只有哪家最合適。
在這裡，筆者用的是友盟統計。
2.1 收集事件
首先先理解什麼是“事件”，可以理解為觸發一個動作、行為或者到達某個條件，都是一個事件（Event）。
例如：在登錄中，填寫完信息後，點擊一下“登錄”按鈕，或者點視頻的“播放”按鈕，頁面流程的“下一步”按鈕，獲取到“登錄成功”，訪問某個頁面，這些觸發的行為都可以理解為一個事件。
因此，沿著流程和產品結構，會得到這麼一個表格：
（可能會存在iOS跟Android的event ID不同，所以這裡分開記錄）
2.2 設置事件的參數和參數值
除了統計事件的觸發次數外，還可以收集觸發這個動作時，其他的附帶信息。利用這類信息，有助於對事件有更加精準的統計，又稱為參數（Key）和參數值（Value）。
事件、參數、參數值的關係如下：
舉個簡單的例子，電影播放平臺上，當用戶點擊“播放”電影時，這裡可以為一個事件。出了統計這個事件發生的次數之外，我們還可以收集到這一次播放的電影類型、地區；
其中，參數就是類型、地區。類型下對應的參數值就有：喜劇、愛情片、科幻片等等；地區下對應的參數值就有：歐美、日本、韓國、大陸等。
（事件-參數-參數值）
當然，還有另外一種情況，那就是所統計參數的參數值，是一串連續的數值，我們無法使用參數值=1,2,3,4這樣去統計。
例如說付款頁面，點擊“確定付款”時，參數為“付款金額”，因為這個時候，我們可能會想到參數值可以=1、2、3、4等一直排列下去。但是實際操作上，參數的值會有很多，可能從1元到1萬元都會有。
這個時候，採用的是計算統計，只需定義好統計值的類型（整數型int還是float）和範圍，例如統計金額的，那麼就是統計付款金額，類型為float，範圍0-10000.00。
根據以上的步驟，可以定期維護這麼一份表格：
3.3 維護表格，定期溝通
在整理完以上的表格之後，別忘了和其他產品、運營、開發對一下這份文檔，看看是否有其他遺漏，同時，再進對應的事件參數等，對應到產品結構和流程中，看是否跑得通。
以後在維護需求文檔的時候，當產品發生變化的時候，可以增刪改這份表格的內容，這樣一來，開發人員就會知道了。
但是記得最重要的一點，還是得跟開發溝通，正確地描述我們埋點的意義和背景。有時候開發人員也會補充和完善你的埋點需求。
四、測試和校驗
接下來就是測試和校驗的環節，如果是接入第三方的，可以根據幫助文檔，將新加入的埋點，進行一輪測試。
因為有時候可能開發大哥對需求的理解有所偏差，或者溝通不到位，導致埋錯了位置或者定義錯了。
而在最終驗收的環節中，需要做一個校驗，避免辛辛苦苦埋下的點，等到上線後，產生了一堆無效的數據，甚至會影響後續對產品的判斷。
五、寫在最後
其實埋點也只是整個產品規劃中，關於數據分析的一小塊。
除了埋點分析外，還需要和後臺的日誌數據做整合分析，善於發現每個異常，善於調研趨勢背後的原因。產品經理跟運營工作相互配合，才能夠是產品走得更快更遠。
以上就是做埋點需求時，總結出的一些心得，如果對您有幫助，那是最好不過，如果您有其他的意見或者看法，也歡迎隨時溝通。
題圖來自 Unsplash ，基於 CC0 協議
閱讀更多 人人都是產品經理 的文章
