作為一名產品經理，你必然知道資料分析對於產品的生命週期的重要性。
解決使用者需求，解決痛點是產品的立足之根本；運營是傳遞產品價值的重要手段；而資料，則給產品和運營提供了指向的重要意義。
資料，既是產品分析的基礎，同樣，資料的採集和來源也是每個產品經理頭疼的地方。
好的資料收集和分析，可以輔助產品經理更好的瞭解使用者，讓團隊少做一些無用需求，或者在錯誤的需求方向上停止腳步，遏制一些異想天開的想法。
一、需求收集和分析
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 維護表格，定期溝通
在整理完以上的表格之後，別忘了和其他產品、運營、開發對一下這份文檔，看看是否有其他遺漏，同時，再進對應的事件參數等，對應到產品結構和流程中，看是否跑得通。
以後在維護需求文檔的時候，當產品發生變化的時候，可以增刪改這份表格的內容，這樣一來，開發人員就會知道了。
但是記得最重要的一點，還是得跟開發溝通，正確地描述我們埋點的意義和背景。有時候開發人員也會補充和完善你的埋點需求。
四、測試和校驗
接下來就是測試和校驗的環節，如果是接入協力廠商的，可以根據説明文檔，將新加入的埋點，進行一輪測試。
因為有時候可能開發大哥對需求的理解有所偏差，或者溝通不到位，導致埋錯了位置或者定義錯了。
而在最終驗收的環節中，需要做一個校驗，避免辛辛苦苦埋下的點，等到上線後，產生了一堆無效的資料，甚至會影響後續對產品的判斷。
五、寫在最後
其實埋點也只是整個產品規劃中，關於資料分析的一小塊。
除了埋點分析外，還需要和後臺的日誌資料做整合分析，善於發現每個異常，善於調研趨勢背後的原因。產品經理跟運營工作相互配合，才能夠是產品走得更快更遠。
以上就是做埋點需求時，總結出的一些心得，如果對您有幫助，那是最好不過，如果您有其他的意見或者看法，也歡迎隨時溝通。
留言列表
