本篇無論是埋點的新手還是老手都可以進行參考，不會浪費大家太多時間。
如果對於資料埋點還沒有概念的同學，可以先閱讀本文的前篇《產品經理資料埋點文件指南（入門）》後再回來。通過對本篇的簡單學習，將會讓你比目前90%以上的產品經理更了解如何有效的獲得自己的產品的真實資料，為之後通過資料來驅動產品發展打下基礎。
筆者最近接手了一些公司的老專案，為了能夠更好弄清專案現狀，用於對未來產品進行迭代，在專案交接時讓前端研發同學重新進行了埋點。
產品功能不算複雜，但也有八個頁面，筆者根據產品經驗和專案的輕重緩急，只把其中最主要的三個頁面進行比較詳細的埋點，剩餘的頁面則只是進行了頁面訪問計數。這樣能夠讓獲得的資料更聚焦，將注意力放在主要流程上，次級頁面我們先對頁面的訪問量保有基本的感知即可。等主體環節優化好後，再根據情況進行埋點優化。
寫文件+溝通確認+埋點+測試，其實也蠻花時間的，少一點是一點。
如果把使用者的行為理解為過程，那麼上面這些所說的這些就是結果。通常這些結果都會在伺服器進行了儲存，比如支付結果會生成訂單，做題的結果會計算分數等。而這些結果是否需要直接從伺服器返回後又通過埋點方式傳入資料庫，則可以根據個人的需求來。如果你每天都需要觀察資料，或者沒有人幫你處理資料，則盡量把資料放一起，保證使用者資料流的連續性，相反則可以少埋或者不埋，提公升安全和效能。
埋點文件中，每個點其實都有自己的名字。起乙個好名字能讓你採集到的資料更直觀，實用。
這一點是很多新手都會犯的誤區，特別是在入門篇沒有學習私有屬性之前。取乙個好名字，能夠快速的讓你定位到你要查詢的事件資料，不好的事件會把各種資訊揉在一起，把why,what,where,when,who等資訊一股腦全放在名字裡，就像我們偉大的龍母，每次的開場白一樣：
丹妮莉絲 坦格利安，舊瓦雷利亞的後裔，安達爾人先民的女王，維斯特洛的統治者暨全境守護者，大草原多斯拉克人卡麗熙，不焚者，彌林的女王，鐐拷打破者，龍之母，阿斯塔波的解放者，羅伊拿人和先民的女王，龍石島公主。
如果把上面的介紹比作乙個資料埋點的話，名字可以只是丹妮莉絲 坦格利安，其它的都是補充屬性，比如：
擅用私有屬性，能夠讓最終產生的資料更清晰，也能夠讓資料分析起來更容易。
頁面命名，頁面的主要功能+型別字尾，型別字尾主要是為了增加辨識度。舉例：
這裡page_view是筆者偏好的名字體別字尾，覺得不舒服的可以不加，或者只加page。接下來再聊一下在頁面上發生的事件，如前圖所示，每個動作都會承載於某個頁面之上，所以頁面點選事件會以
頁面名稱字首+動作+型別字尾，三個模組來組合：
如此，當我們的拿到資料時，只看資料本身，也可以看到一條非常清晰的資料鏈。這裡筆者展示乙個使用者訪問頁面的真實案例：
只用掃一眼，就能立即知道：
以此來感知，使用者對我們的產品的乙個真實反饋。
最後，請務必保證點名稱的單詞拼寫正確。這是乙個產品經理基本的態度問題，拼寫錯誤會讓你的合作夥伴對你的信任度降低。錯誤的埋點一但進入資料庫，一般也是不可變更，隨意的變更同乙個點的名稱則很容易造成分析上的斷層，但不改又會讓人很難堪，陷入乙個兩難的局面。
學會了給點起名字，乙個名字對應乙個點，那我們回到之前**大全的原型圖，請讀者思考一下，這一塊的四個按鈕需要幾個點來描述？4個，3個還是1個？
這個原型畫得比較粗糙，需要根據大家的需求和實際情況來結合。
如果這個原型畫的只是固定的四個按鈕，則直接將四個點分別起名字也不失為一種高效的方法。但如果是個列表，表中有數量可變，內容可變，排序可變的選擇，則強烈推薦通過私有屬性來對事件多維度的補充區分。
這裡也給大家留乙個小作業，知道入門篇最後那個埋點文件中，有乙個什麼樣的優化點了嘛？
前面也提到了，盡量使用私有屬性。但在一些情況下，區域性的私有屬性也可以單獨抽離出來，形成頁面的私有屬性。比如，使用者進入一些次級頁面時，會帶一些狀態，或者使用者的每個行為都與當前所處的頁面內容有關。
對比一下，是不是又清爽了很多呢？
再近一步，產品中有一些元件是不屬於任何乙個頁面，卻又可能隨時出現在產品中的任何地方。比如彈窗提醒、支付、登入失效等。這種元件所產生的行為則可以單獨的寫在一起，這個比較好理解就不單獨展示了。
埋點文件其實程式設計師們寫的**一樣，是有版本管理，且要可以追溯。但相比他們，我們並沒有很好的文件管理工具情況下，筆者通過以下三個方法來對埋點文件進行管理與歸檔操作。
筆者在入門篇就已經申明，產品不埋點不能上線。同樣的，產品的每次需求發版，埋點文件也要發更新；
埋點文件也是有版本的，筆者會習慣將埋文件的版本號與產品版本號保持一致，且每次都簡單記錄了產品迭代的內容；
埋點文件只做新增，不做覆蓋，即如果產品發了十次版本，則會有十份埋點文件。且最新版本的埋點文件，一定是最新、最全的版本。
這樣，筆者在整理過去一年時間中，產品各個迭代所產生的資料結果，及相應的事件分類都可以輕鬆快速的找到。
除了每份埋點文件有版本，筆者的每個點都有版本號。是不是聽上去很複雜？其實這也是融合之前筆者程式設計師的經歷，相當於git中，每一行**可以不斷的融合與迭代，但又能追溯到每一行**的**。
我們倒不用記錄得那麼詳細，在埋點文件中，每乙個點把出現的產品版本號記錄上就好了。一般情況下，點的版本號不會高於當前產品的版本號。
除非是這個點當前版本條件技術條件不滿足，提醒自己下個版本需要實現一般文件中的點版本號會有以下幾種情況：
如果點的版本號低於文件版本號，則此點是乙個更早期的資料埋點，可以提示研發同學如果沒有修改則可以不需要做任何修改；
如果點的版本號與當前產品版本號相同，且沒有人進行埋點，則此點是乙個新點，需要在當前版本中加上；
如果在新的版本中，如果對老的點要進行修改，比如新增修改屬性等，則會把原來的老版本號和埋點人刪除，換上新的版本號；
如此，研發同學能夠快速的找到所有當前版本中需要埋的新點。
跟著前面的案例繼續，每乙個埋點文件都需要在研發完成埋點後進行簽名記錄。
這樣一是提醒研發同學哪些點埋了，哪些點沒有埋；
雖然埋點之前都會溝通，但實際資料採集還是有多種實現手段，特別是讀者不太了解技術的情況下。一旦出現第三方引用時，還可以第一時間找到相應的負責人；
結合埋點版本，則可以知道最早這個點是什麼時候埋下去的，即從哪乙個版本開始有資料；
如下圖所示，我們會發現2.0版本的埋點還沒有埋，趕快督促一下研發吧。
通過這種方法，即使是數十個版本之前的埋點，只要不出現大的遷移或者重構，還是可以穩定的工作，提供資料。
但埋點和埋點文件多嘗試，筆者的這套埋點文件從思考到實戰也就經過大約半年後就基本穩定。取得了比較好的效果，得到了公司的資料團隊的認可（可惜他們沒有能力推廣），筆者的團隊的埋點規範就按照筆者的這套規範來進行編寫。相信大家能夠有所收穫。
最後，就是不要沉迷於資料，資料只是當前和曾經發生的事情的反饋，只能作為大家在決策和思考時的輔助，人不能兩次踏進同一條河流，產品也是。
資料埋點學習之資料埋點概念學習
資料埋點概念拆分成三部分來學習 會話，使用者訪問網際網路的某個 時，儲存在會話中的資料不會丟失，只有當使用者x分鐘沒有訪問或者退出訪問時，會話才會結束。會話結束後，使用者開始新的訪問，這裡產生的是新的會話。對於埋點的意義 通過會話我們能知道開始時間和結束時間，從而用於路徑分析。研究定義是針對口徑而言...
產品經理三大文件
在這裡分享產品經理三大需求文件 向公司申請需要的費用 資源得到各級領導的支援 簡潔，明了，易懂 通常用來講述市場機遇，盈利方式等 具體包括 商業價值 成本估算 收益預期 工具 ppt word mindmanager 在獲得了公司領導和資源的支援後，根據自己的想法 在產品層進行表述，使相關人員了解將...
埋點日誌MySQL 資料採集之js埋點
worker processes 2 events if ngx.var.arg domain then ngx.location.capture i log?ngx.var.args utrace uid end add header expires fri,01 jan 1980 00 00 0...