大環境：
在流量紅利基本消失殆盡的大背景之下，流量逐步呈現愈發明顯的馬太效應（註解：馬太效應指強者愈強、弱者愈弱的現象。）智勇雙全的前輩們遂提出了精細化產品探索之道，等各種方法論，（翻譯成人話就是：1、別人吃剩扔掉的，我撿起來吃掉。2、別人吃完的羊蠍子扔掉的骨頭，我撿起來把骨頭砸開，把骨頭裡的骨髓吃掉的意思），透過資料分析團結一切可以團結的力量，利用可以利用的一切工具透過資料驅動產品迭代，透過資料驅動產品最佳化從而在激烈的同行競爭中殺出一條血路來，謀生存，求發展。最終透過資料始終在戰略上比競品（同行競爭對手）快一步，在戰略上藐視敵人，在戰術上重視敵人，讓對手摸不著套路，我們出一個新功能競品立即跟進就會陷入被牽著鼻子走的尷尬境地，永遠慢一步，即使是豪華團隊有錢有人模仿的再快，跟上了迭代速度，如果沒有看透競品迭代的本質原因，則很可能輸掉整場遊戲，從而對手無法模仿，跟不上、看不懂——-（surprise O（∩_∩）O~會心一笑）
基於以上背景首先就要學會以資料思維驅動產品迭代，精細化產品探索，及時發現產品問題，持續最佳化，提升使用者體驗讓使用者爽、滿足使用者的深層次情感需求，來達到“大吉大利，今晚吃雞”的目的。
文章背景：
透過隨機抽樣調查，發現關於資料產品經理、資料分析、產品設計等關鍵詞的單篇文章不在少數，不乏乾貨、或者大佬寫的文章，但像每一篇文章只寫一個點，每個點連成線寫成一個系列，甚至組成一個面，讓看官老爺能系統性的瞭解某一條線的系列文章卻少之又少，看官老爺很難系統性的提升對某一個知識分支的認知，或者只能憑文章中提及的一些線索自己去探索，歸納（葛優癱。。生無可戀的看官老爺可能會說：我能怎麼辦，我也很無奈呀）就像：1、我聽了好多大道理，但是依然過不好這一生。1、我看了好多戀愛秘籍，搭訕攻略，但是卻依然找不到女盆友，比如我（雙狗特效加持：單身狗+產品狗）buling buling…的效果是一樣一樣的。
基於知識點分散，系統性歸納低效的場景，面向0-1歲或者即將入坑資料產品的看官老爺，解決資料產品入門的問題，帶來幫助看官老爺整體理解資料產品基礎，系統性入門的價值。
文章更新規劃：
計劃將實際工作中最高頻的與資料相關的一些工作經驗以及技巧與大家做一個交流溝通，初步計劃整體分6-8篇文章、每篇1-2周的頻率由外到裡，由淺入深，並伴隨實際工作中案例系統性的分享。根據看官老爺的反應調整後面要寫的內容，以及更新文章的速度。
以上都是廢話，分割線以下是重點。
——————————————————————-我是可愛的分割線——————————————————————————
埋點概述：
資料埋點是資料產品經理、資料運營以及資料分析師，基於業務需求（例如：CPC點選付費廣告中統計每一個廣告位的點選次數），產品需求（例如：推薦系統中推薦商品的曝光次數以及點選的人數）對使用者行為的每一個事件對應的位置進行開發埋點，並透過SDK上報埋點的資料結果，記錄資料彙總後進行分析，推動產品最佳化或指導運營。
埋點分析，是網站分析的一種常用的資料採集方法。資料埋點分為初級、中級、高階三種方式。資料埋點主流部署的方式有：一種是私有化部署（即部署在自己公司的伺服器上，如果期望提高資料安全性，或者定製化的埋點方案較多，則適合私有部署，並開發一套針對自己公司定製化的資料後臺查詢系統保證資料的安全性和精確性，缺點是成本較高）。
另外一種是接入第三方服務，比如國內的某盟和國外的GA（Google Analytics）統計，在以後的文章中會單獨介紹，此處不再展開。（優點是成本較低，部分基礎服務免費，缺點是：資料會存在不安全的風險，另外一個就是隻能進行通用的簡單分析，無法定製化埋點方案）
此處只展開初級：在產品、服務轉化關鍵點植入統計程式碼，據其獨立ID確保資料採集不重複（如收藏按鈕點選率）；
主要的埋點事件分類：
1：點選事件:
點選事件，使用者點選按鈕即算點選事件，不管點選後有無結果；
2：曝光事件：
成功開啟一次頁面記一次，重新整理頁面一次記一次，載入下一頁新頁，載入一次記一次。home鍵切換到後臺再進入頁面，曝光事件不記；
3：頁面停留時間事件：
表示一個使用者在X頁面的停留時長記為停留時長。例如：小明9：00訪問了X網站首頁，此時分析工具則開始為小明這個訪問者記錄1個Session（會話）。接著9：01小明又瀏覽了另外一個頁面列表頁，然後離開了網站（離開網站可以是透過關閉瀏覽器，或在位址列鍵入一個不同的網址，或是點選了你網站上鍊接到其他網站的連結……）為了簡單，我們把這個過程當做一個Session。
則最終小明在首頁的頁面停留時間：
（Time on Page，簡稱Tp）Tp（首頁） = 9：01 – 9：00 = 1 分鐘。
When？什麼時間做？
產品經理的需求來源眾多，可能來自一線市場人員，可能來自身旁油膩的領導。可能來自使用者反饋的一條吐槽…無論需求來自哪裡，首先要搞清楚的就是做了這個需求以後，想清楚：
（一）在什麼樣的場景下？
（二）面向哪些目標使用者？
（三）解決了哪些問題？
（四）帶來了什麼價值？
梳理清楚問題後，拆分問題：
（一）哪些是主要問題？
（二）哪些是次要問題？
（三）重不重要？
（四）緊不緊急？
將每個問題拆解後下一步就是帶著PRD文件找親愛的資料分析師童鞋與產品經理一起溝通，解決以下問題：
（一）每個問題應該怎麼量化？
（二）量化指標是什麼？
（三）怎麼透過資料定義每個問題以及整個需求的成功與否？
（四）有哪些輔助指標？
定義好資料指標後，此時則需要資料產品或者資料分析師定義埋點。同時為幫助各位看官老爺理解，可參考以下流程圖：
How？怎麼定義埋點？
無規則不成方圓，良好的定義規範可以幫助埋點相關人員更好的維護，以及理解，極高的提升工作效率，降低推倒重來的風險，基於此分享一份埋點的定義規範幫助各位看官老爺以後維護自己產品的埋點。使用此規範後，本汪一人就可以維護一個APP版本（包含點選事件、曝光事件、停留事件）累計1500多個埋點，井然有序，完全不會亂。（懷念那些加班維護埋點跑數的日日夜夜，讓我與看門大叔成了摯友，結下了深厚的友誼。咳咳，此處應該有掌聲…）
埋點分類概述：
（圖一）思維導圖
1、首先從事件屬性這個維度上分為三份Excel（點選事件表、曝光事件表、停留事件表）
2、其次每一個事件表中新建三份子表（Sheet），以點選事件表為例拆分為：首頁事件集合、列表頁事件集合、詳情頁事件集合
3、每當APP釋出新版本時，從上一個版本的埋點中做一份Copy，新版本中新增了哪些埋點，刪除了哪些埋點？都用不同的顏色，或者時間標記進行標註說明。
真實環境中分類更為複雜，僅以上面例子說明分類思路，各位看官老爺可以根據業務需求做針對自己產品更合適的分類。
欄位明細：
功能欄位：
用於說明當前埋點是在哪個頁面的哪個功能。例如：收藏功能，對應功能欄位名：我的收藏
中文名：
用於描述X功能模組內X位置，例如起名叫：收藏功能-文章收藏
事件型別：
用於說明當前埋點是點選事件還是曝光事件還是其他
事件ID：
如果是自己公司開發的資料查詢系統，則每一個埋點都對應一個事件ID，上線後用於拿著事件ID去後臺取數使用。事件ID的命名規範：事件英文簡寫_哪一端的產品_產品名稱簡寫_頁面名稱_模組名稱_功能名稱。
例如：點選事件_APP端_二手車_個人中心_收藏_文章收藏對應事件ID== click_app_2sc_Personal Center_ Collection_ Article Collection
如果是用的第三方統計工具：例如某盟，同理定義好事件ID，上線後去X盟後臺，輸入事件ID查詢響應的資料。
Key欄位與value欄位:
當一個埋點對應不同型別的多種位置的埋點時，則需要命名當前埋點的key引數與value引數，一個key可以對應1個value或者多個value，但一個value不能對應多個key。只能對應唯一的一個key 例如：二手車資訊網站有2個關鍵按鈕，一個是砍價按鈕，一個是撥打電話按鈕，但是在多個頻道中每個頻道都有多個砍價按鈕多個撥打電話按鈕，在這樣的場景下就可以設計2個KEY值，key01=source用於標記當用戶點選了一次按鈕後是在哪個頻道的頁面點選的這個按鈕X，value01=X1，value2=X2用於標記不同位置同屬性的按鈕。Key02=type用於標記使用者是點的砍價還是點的撥打電話按鈕，01value用於標記砍價按鈕，02value對應的撥打電話按鈕。
記錄規則欄位：
定義什麼情況下觸發埋點，例如：在列表頁點選一次記錄一次
備註：
用於描述當前埋點什麼時間新增？什麼時間修改過？原因？什麼時間被刪除？誰刪除的？等資訊記錄，此處好多看官可能以為寫不寫無所謂，但是為了資訊的完整性和可追溯性最好每一次變動都要備註。（認真臉）
結語：
本篇主要介紹了工作中埋點相關的基礎，以及闡述了埋點在流程中應在什麼時間實現，怎麼實現，定義埋點時對應規則規範等細節內容，幫助各位看官老爺理解以及實踐。
最後一句：以上我說的都是錯的，只有適合你的才是正確的！
再加一句：各位看官老爺，如果您
覺的
本文對您有幫助，記得給個贊哦，(* ￣3)謝謝啦。
