數據分析入門初識數據埋點埋點數據監控 _經驗分享

什么是埋點埋點，是網站分析的一種常用的數據采集方法。數據埋點分為初級、中級、高級三種方式。數據埋點是一種良好的私有化部署數據采集方式。
埋點技術如何采集數據，有何優缺點？
數據埋點分為初級、中級、高級三種方式，分別為：
初級：在產品、服務轉化關鍵點植入統計代碼，據其獨立ID確保數據采集不重復（如購買按鈕點擊率）；
中級：植入多段代碼，追蹤用戶在平臺每個界面上的系列行為，事件之間相互獨立（如打開商品詳情頁——選擇商品型號——加入購物車——下訂單——購買完成）；
高級：聯合公司工程、ETL采集分析用戶全量行為，建立用戶畫像，還原用戶行為模型，作為產品分析、優化的基礎。
無疑，數據埋點是一種良好的私有化部署數據采集方式。數據采集準確，滿足了企業去粗取精，實現產品、服務快速優化迭代的需求。
但，因手動埋點工程量極大，且一不小心容易出錯，成為很多工程師的痛。且其開發周期長，耗時費力，很多規模較小的公司并不具備自己埋點的能力。無埋點成為市場新寵。最后埋點、無埋點兩種技術誰能成為最后贏家，我們拭目以待。
關于數據埋點，你需要知道的技術方案和規范流程埋點是數據采集的專用術語，在數據驅動型業務中，如營銷策略、產品迭代、業務分析、用戶畫像等，都依賴于數據提供決策支持，希望通過數據來捕捉特定的用戶行為，如按鈕點擊量、閱讀時長等統計信息。因此，數據埋點可以簡單理解為：針對特定業務場景進行數據采集和上報的技術方案。
數據埋點非常看重兩件事，一個是數據記錄的準確性，另一個則是數據記錄的完備性。
先講數據的準確性。數據埋點非常強調規范和流程，因為參數的規范與合法，將直接影響到數據分析的準確性，如果準確性得不到保障，那么所有基于埋點得出的結論，都是不可信的。辛辛苦苦做了很久的方案，一旦因為一個疏忽的小問題，導致下游集中投訴，其實非常劃不來。
道理每個人都懂，但現實情況中，數據埋點所面對的客觀環境，其實非常復雜，例如：
因此本文有非常長的篇幅來寫流程問題，其實是非常有必要的。
再講數據的完備性。因為埋點主要是面向分析使用，對用戶而言是個額外的功能，因此埋點的業務侵入性很強，很容易對用戶體驗造成影響。別的不說，僅僅是流量的消耗，就很容被用戶噴。因此，要提前想清楚，我們要采集哪些東西，因為修改方案的成本，是傷不起的。
通常情況下，我們需要記錄用戶在使用產品過程中的操作行為，通過4W1H模型可以比較好的保障信息是完備的。4W1H包括：
規定好記錄信息的基本方法之后，按照固定的頻率，如每小時、每天，或者是固定的數量，比如多少條日志，或者是網絡環境，比如在Wifi下上傳，我們就可以開心的把埋點數據用起來了。
當然，數據記錄的時效性也比較重要，但因為埋點數據通常量級會比較大，且各個端數據回傳的時間不同，因此想做到實時統計，還是需要分場景來展開。在Flink技術日漸成熟的今天，全鏈路的實時采集與統計，已經不是什么難題。
在埋點的技術方案中，首先要重視的，是用戶唯一標識的建設。如果做不到對用戶的唯一識別，那么基礎的UV統計，都將是錯誤的。
因此，在數據埋點方案中，有兩個信息是一定要記錄的，即設備ID+用戶ID 。設備ID代表用戶使用哪個設備，如安卓的ANDROID_ID/IMEI ， IOS中的IDFA/UDID ，瀏覽器的Cookie ，小程序的OpenID等。用戶ID ，代表用戶在產品中所注冊的賬號，通常是手機號，也可以是郵箱等其他格式。
當這兩個信息能夠獲得時，不論是用戶更換設備，或者是同一臺設備不同賬號登錄，我們都能夠根據這兩個ID ，來識別出誰在對設備做操作。
其次，我們來看一下Web的數據采集技術。Web端數據采集主要通過三種方式實現：服務器日志、URL解析及JS回傳。
瀏覽器的日志采集種類又可以分為兩大類：頁面瀏覽日志和頁面交互日志。
除此之外，還有一些針對特定場合統計的日志，例如頁面曝光時長日志、用戶在線操作監控等，但原理都基于上述兩類日志，只是在統計上有所區分。
再次，我們來看下客戶端的數據采集。與網頁日志對應的，是手機應用為基礎的客戶端日志，由于早期手機網絡通訊能力較差，因而SDK往往采用延遲發送日志的方式，也就是先將日志統計在本地，然后選擇在Wifi環境下上傳，因而往往會出現統計數據延遲的情況。現如今網絡環境好了很多， 4G、5G流量充足，尤其是視頻類APP基本上都是一直聯網，因而很多統計能夠做到實時統計。
客戶端的日志統計主要通過SDK來完成，根據不同的用戶行為分成不同的事件， “事件”是客戶端日志行為的最小單位，根據類型的不同，可以分為頁面事件（類比頁面瀏覽）和控件點擊事件（類比頁面交互）。對于頁面事件，不同的SDK有不同的方式，主要區別為是在頁面創建時發送日志，還是在頁面瀏覽結束后發送日志，區別在于業務統計是否需要采集用戶的頁面停留時長。
頁面事件的統計主要統計如下三類信息：
埋點其實還需要考慮數據上傳的方案，批量的數據可以通過Flume直接上報，流式的可以寫到Kafka ，或者直接使用Flink來處理。這些框架相關的內容不是本文考慮的重點，有興趣的可以自行查閱資料。
有了指導思路和技術方案后，我們就可以著手制定相應的數據埋點流程規范了。
籠統上，流程規范會分成五個步驟，即需求評審、埋點申請、技術開發、埋點驗證、發布上線。
第一步，需求評審。
前文提到過，數據埋點的方案一旦確定，返工和排查問題的成本都很高，但數據埋點之后的分析工作，又涉及到了PD、BI、算法、數據等多個角色。因此非常有必要，將需求內容和數據口徑統一收口，所有人在一套口徑下，將需求定義出來，隨后業務側再介入，進行埋點方案的設計和開發。
以前文提到的4W1H模型為例，常見的記錄內容如下：
最后我們統計時，按照上述約定，統計用戶在某個時間和地點中，看到了哪些信息，并完成了怎樣的動作。上下游的相關人員，在使用這份數據時，產生的歧義或者是分歧，會小很多。
第二步，埋點申請
當下的熱門應用，大多是以超級APP的形式出現，比如微信、淘寶、支付寶、抖音，超級APP會承載非常多的業務，因此技術方案上會十分統一。
因此，當我們的技術方案確定后，通常要在相應的埋點平臺上，進行埋點申請。申請的內容包括分配的SPM、SCM碼是什么，涉及到的平臺是哪些，等等。SPM、SCM是什么，有什么用，同樣可以自行查閱。
第三步，技術開發
當需求確定、申請通過后，我們就可以開始開發動作了，這里基本上是對研發同學進行約束。埋點的開發，簡單講，是分成行為埋點和事件埋點兩個大類，每一類根據端的不同進行相應的開發。具體的技術方案詳見前文01章節。
詳細的設計規范，是需要留文檔的，因為代碼不能反應業務的真實意圖，而不論是事后復盤與業務交接，都需要完整的文檔來闡述設計思路。
第四步，埋點驗證
埋點的驗證很關鍵，如果上線后才發現問題，那么歷史數據是無法追溯的。
驗證有兩種方式，一種是實時的功能驗證，一種是離線的日志驗證。
實時功能驗證，指功能開發好后，在灰度環境上測試相應的埋點功能是否正常，比如點擊相應的業務模塊，日志是否會正確的打印出來。通常而言，我們需要驗證如下三個類型的問題：
除去實時驗證，我們也需要把日志寫到測試環境中，查看數據上報的過程是否正確，以及對上報后的數據進行統計，側面驗證記錄的準確性，如統計基本的PV、UV ，行為、事件的發生數量。
很多時候，數據是需要多方驗證的，存在一定的上下游信息不同步問題，比如對某個默認值的定義有歧義，日志統計會有效的發現這類問題。
第五步，發布上線。
應用的發布上線通常會有不同的周期，例如移動端會有統一的發版時間，而網頁版只需要根據自己的節奏走，因此數據開始統計的時間是不同的。最后，應用應當對所有已發布的埋點數據，有統一的管理方法。
大多數時候，數據埋點的技術方案，只需要設計一次，但數據準確性的驗證，卻需要隨著產品的生命周期持續下去，因此僅僅依靠人肉來準確性驗證是不夠的，我們需要平臺來支持自動化的工作。埋點的準確性，大體有兩種方法保障：一種是灰度環境下驗證真實用戶數據的準確性；另一種則是在線上環境中，驗證全量數據的準確性。因此，發布上線之后，后續的管理動作，應該是對現有流程的自動化管理，因為團隊大了，需要埋點的東西多種多樣，讓平臺自己測試、自動化測試，就是很多測試團隊必須走的路
數據分析與埋點，產品經理必須掌握的知識和技能產品經理必須隨時全面而準確地了解自己產品的各項數據，否則只能憑著感性在規劃和設計產品，容易犯錯誤。因此，看哪些數據，如何統計和分析數據，如何進行數據埋點，都是產品經理必須要掌握的知識和技能。
如果你對此還不甚了解，可以通過這篇文章，快速地知道一個大概，然后待到在工作中學習和實踐時，就更加容易上手了。
首先簡單講一下什么是數據埋點。數據埋點通常是指開發工程師基于業務、運營或產品經理的需要，在產品前端程序中植入相關代碼，以獲取用戶行為等數據的一種技術手段。
對開發人員而言，埋點需求同性能需求一樣都屬于非功能性需求，它們與功能性需求一起組成了產品需求。
網頁中最常見的埋點方式是通過JS代碼來實現的。
比如為了統計用戶的點擊事件，那么在每個鏈接或按鈕處，都增加一段JS代碼，用戶一旦點擊，無論頁面是否有跳轉、刷新等，都悄悄地請求了服務器，也就把一大堆信息傳給了服務器存下來，包括用戶的IP地址、地理信息、瀏覽器參數、點擊的對象、時間等等。
又比如為了統計曝光事件，先定義好何為有效曝光（例如完成加載、渲染并進入用戶視界），然后在有效曝光發生時，執行一段JS代碼，把相關信息傳輸到服務器。
如果是手機APP或智能設備，則不同于網頁主要使用JS代碼的方式，它們往往被植入SDK（Software Development Kit ，即軟件開發工具包）來實現數據埋點。同時，為了避免頻繁連接網絡上傳或下載數據，通常會將數據先存儲在手機本地或智能設備中，等到一定的時機，再一次性同步至服務器。
一定要記住的是，數據埋點只是數據統計和分析的一種技術手段，并非所有的數據統計都必須要有數據埋點。
比如網頁事件。在通過HTTP或HTTPS協議請求時，也就是訪問各種網址時，瀏覽器發送給服務器的數據包中，不僅僅是地址欄中你看得見的那一行鏈接地址，而且還已經包括了諸如瀏覽器信息、用戶信息、來源URL等，這些信息無需再通過埋點，只需要在后端接受請求的程序中加以解析，把有用的存下來即可。
還有一類數據，也是無需埋點的，比如有多少用戶成功收藏了一篇文章，這本就屬于功能需求的范疇，業務數據中已有記錄。
好了，通過前面提到的各種方式，數據有了，但這還不是最重要的。
有了數據之后，還需要根據需要，從這些可能相當雜亂、冗余的數據中選出有用的，按照有利于查詢和分析的方式進行二次加工和存儲，使之與生產環境中實時變化著的數據隔離開。然后在此基礎上，生成各類報表，或者提供一個可自行敲入SQL語句查詢數據的界面。
稍有規模的公司通常會有專門的BI團隊，他們的主要工作就是開發并維護一個這樣的數據系統，供包括產品經理在內的各方面人員，隨時隨地地查詢和分析數據。
數據埋點是什么【數據分析入門初識數據埋點埋點數據監控】所謂嵌入點，就是在一個應用的特定過程中收集一些信息，用來跟蹤應用的使用情況，然后進一步優化產品或者為運營提供數據支持，包括訪問量、訪客、在站時間、瀏覽量、跳出率等。
這樣的信息收集大致可以分為兩種:跟蹤這個虛擬頁面視圖和通過一個事件跟蹤這個按鈕。
有兩種方法可以埋葬主流的觀點:
第一種:我公司研發在產品中注入代碼統計，并設置相應的后臺查詢。
第二:第三方統計工具，如友盟、廁神、Talkingdata、GrowingIO等
如果是產品前期，通常采用第二種方法收集數據，直接使用第三方分析工具進行基礎分析。對于那些比較注重數據安全、業務相對復雜的公司，通常采用第一種方法來收集數據，并構建相應的數據產品來實現其數據應用或分析的需求。
埋藏點含量
看完這些關鍵指標，埋點大致可以分為兩部分。一部分是應用頁面訪問量的統計，即頁面統計，發生頁面訪問時會上報；另一部分是統計應用中的操作行為，在頁面中操作的時候(比如組件暴露的時候，組件被點擊的時候，組件上下滑動的時候)上報。
為了統計所需指標，對應用中的所有頁面和事件進行唯一標記，并額外上報用戶信息、設備信息、時間參數和滿足業務需求的參數等具體內容，即埋點。
埋資料注意:不要太追求完美。
關于隱藏數據，有一點很重要。掩埋數據是為了更好地利用數據。不要試圖得到準確的數據。你需要的是高質量的埋藏數據。前面討論的跳出率就是一個例子。當你獲得了可用的數據，你就可以用不完善的數據來實現下一步的行動，你追求的是高質量而不是準確性。這也是很多數據產品容易入坑的地方，所以你要時刻提醒自己。
https://iknow-pic . cdn . BCE Bos . com/622762 d0f 703918 ff 2 DAC 25 a 433d 269759 EEC 413？x-BCE-process = image % 2f resize % 2Cm _ lfit % 2Cw _ 600% 2Ch _ 800% 2c limit _ 1% 2f quality % 2Cq _ 85% 2f format % 2Cf _ auto
埋點，數據產品經理必備的技能數據是數據產品的根基，而埋點是數據的起點；如果沒有埋點，那數據產品則是無源之水。
可以說埋點是互聯網行業里遇到的關鍵且無法繞過的問題。
以下是企業不同位置的同學內心OS：
業務同學對于埋點是什么都不知道，也不清楚要埋什么；所以往往會做了功能但是沒有做埋點，在需要進行數據分析的時候去找數據團隊要數據，數據團隊會反問：“你們埋點了嗎？”
數據產品，因為他們對于業務的認知并不深刻，所以經常會出現漏埋、錯埋的情況，導致最后無數可取的結果。
業務開發，本質上他們是解決業務相關問題，數據開發對他們來說一個比較額外的工作，所以他們的開發成本會隨著埋點需求而增加，也有可能伴隨項目延期的風險；其次過得的埋點開發需求也會導致代碼的冗余。
數據分析，他們更多地是用數據，數據埋點的規則找不到，以至于無法很好的通過數據驅動進行分析。
外部數據的交互：比如API數據的傳輸、數據文件的傳輸等；目前某平臺的大數據標簽系統就是通過這種方式傳輸補齊企業的人群標簽等。
而數據產品在整個數據鏈路上來說，基本可以劃分為以下流程：
首先數據采集我們要從不同的端采集不同的數據，然后進行數據清洗加工處理（ETL），然后匯總到數據倉庫中，供用戶分析、用戶畫像、精準營銷等使用；
我們知道數據采集、數據埋點的重要性后，在實際的業務功能需求提出的時候，一定是要提相關埋點需求的，那在做數據采集我們需要遵循怎么樣的流程呢？
以上環節缺一不可，只有規范的流程，才可以在最后的分析中發現正確的現狀問題。
現在互聯網行業主流的埋點方案主要分為四種：
1. 第一種：代碼埋點，代碼埋點又分為前端埋點和后端埋點；前端埋點是通過前端的代碼埋點來監控用戶觸發某個頁面的數據采集
前端埋點的優點很明顯，但是缺點也很明顯，由于前端埋點的數據是通過延遲上報的機制，比如用戶點擊某個頁面按鈕它不會立刻上報，而是累計到一定的值以后才會按批上班，受限于當前網絡情況，如果遇到網絡堵塞等問題就會數據丟包，因此前端埋點丟失率比較高，一般在5%~10% 。
而且前端埋點如果有漏埋和錯埋的情況，那就要通過app發版進行優化，而客戶端發版就要很久的時間。
優點是在每次用戶觸發這次請求，都會觸發埋點代碼進行數據統計，所以無需發版，及時觸發及時更新。
缺點是服務端埋點需要依賴服務請求，無法覆蓋所有前端交互，以及對于用戶路徑采集也比較弱。
3. 第三種：全埋點；是目前互聯網做用戶增資的企業提出的一種埋點思路，通過埋點SDK接入，針對頁面所有的采集頁面元素的瀏覽和點擊行為做統一的收集，不是按次和需求采集，而是提前全部采集
優點是開發成本高， SDK接入后后期維護成本也低，且埋點流程也很簡單；先采集后定義，在一定程度上能避免漏埋錯埋。
缺點是數據的冗余，導致很多數據并無用處，且數據采集范圍僅僅是頁面可見元素，比如像曝光這種就無法采集到；數據準確性也有問題。
4. 第四種：可視化埋點；也是接入埋點SDK ，但是并不是隨時隨地采集，而是按需采集，通過可視化圈選觸發埋點采集
優點是操作簡單，且按需埋點不會采集無效數據，開發成本比較低；并且數據埋點是可支持撤銷操作的，總體來說比全埋點數據量會小很多。
缺點：歷史數據是無法恢復的，因為在我們圈選動作之前的數據是無法進行采集的；統計范圍僅支持頁面前端的動作，比如曝光也是無法采集到的。
選擇埋點方案的參考主要基于三點：
比如我們可以根據業務發展階段來定，比如說現在業務發展較快，版本迭代速度快、開發投入成本高，那我們做客戶端埋點和服務端埋點是不太適合的，因為可能沒過多久版本就更新了，所以全埋點和可視化埋點比較適合；
那對于比較強的業務數據分析場景來說，需加上前端客戶端埋點；以及需要考慮分析深度，如果僅僅是想看用戶前端行為路徑的，那全埋點和可視化埋點就能滿足需求，但是如果分析業務全流程那一定是需要配合上代碼埋點。
我是比較推薦全埋點+代碼埋點組合，如何服務端能做，優先服務端做，這樣數據準確度會更高。
事件是埋點里最核心的要素，如果我們要清晰的定位埋點，就要從6個維度進行定義，我們可以總結為who、when、where、what、why、How；這幾個元素就構建了事件的基本要素。
那對于埋點事件主要可分為三類：
通過以上我們基本就可以判斷出我們需要記錄用戶什么行為，采集什么數據， for后續的什么分析了。
寫在最后，在工作生涯中，過往的坑告訴我，一個好的埋點管理平臺是多么的重要。
首先流程線上化，我們往往在一封封埋點的郵件中迷失自我，但是如果是線上申請，那需求申請、處理、接入、驗證、測試就非常方便和快捷，規避信息溝通中的缺失；
其次可以管理規范，埋點都統一管理，信息集中管理，方便后期的分析和使用；
最重要的是監控實時化，減少漏埋、錯埋的問題。
當然如果沒有埋點管理平臺，確定下規范的埋點流程，選擇適合當下業務的埋點方案，我相信你也一定也可以做好埋點以及通過數據完成豐富的場景分析！
作者：Goodnight；專注用戶、產品等運營領域。
題圖來自 Unsplash ，基于 CC0 協議
數據分析入門初識數據埋點數據分析入門：初識數據埋點
計劃將實際工作中最高頻的與數據相關的一些工作經驗以及技巧與大家做一個交流溝通，初步計劃整體分6-8篇文章、每篇1-2周的頻率由外到里，由淺入深，并伴隨實際工作中案例系統性的分享。根據看官老爺的反應調整后面要寫的內容，以及更新文章的速度。
埋點概述
數據埋點是數據產品經理、數據運營以及數據分析師，基于業務需求（例如：CPC點擊付費廣告中統計每一個廣告位的點擊次數），產品需求（例如：推薦系統中推薦商品的曝光次數以及點擊的人數）對用戶行為的每一個事件對應的位置進行開發埋點，并通過SDK上報埋點的數據結果，記錄數據匯總后進行分析，推動產品優化或指導運營。
埋點分析，是網站分析的一種常用的數據采集方法。數據埋點分為初級、中級、高級三種方式。數據埋點主流部署的方式有：
私有化部署（即部署在自己公司的服務器上，如果期望提高數據安全性，或者定制化的埋點方案較多，則適合私有部署，并開發一套針對自己公司定制化的數據后臺查詢系統保證數據的安全性和精確性，缺點是成本較高）。
接入第三方服務，比如國內的某盟和國外的GA（Google Analytics）統計，在以后的文章中會單獨介紹，此處不再展開。（優點是成本較低，部分基礎服務免費，缺點是：數據會存在不安全的風險，另外一個就是只能進行通用的簡單分析，無法定制化埋點方案）
此處只展開初級：在產品、服務轉化關鍵點植入統計代碼，據其獨立ID確保數據采集不重復（如收藏按鈕點擊率）；
主要的埋點事件分類：
點擊事件：
點擊事件，用戶點擊按鈕即算點擊事件，不管點擊后有無結果；如下圖紅框標注所示，點擊一次記一次。
曝光事件：
成功打開一次頁面記一次，刷新頁面一次記一次，加載下一頁新頁，加載一次記一次。home鍵切換到后臺再進入頁面，曝光事件不記；
頁面停留時間事件：
表示一個用戶在X頁面的停留時長記為停留時長。例如：小明9:00訪問了X網站首頁，此時分析工具則開始為小明這個訪問者記錄1個Session（會話）。接著9:01小明又瀏覽了另外一個頁面列表頁，然后離開了網站（離開網站可以是通過關閉瀏覽器，或在地址欄鍵入一個不同的網址，或是點擊了你網站上鏈接到其他網站的鏈接……）為了簡單，我們把這個過程當做一個Session 。
則最終小明在首頁的頁面停留時間：
（Time on Page ，簡稱Tp）Tp(首頁) = 9:01 – 9:00 = 1 分鐘
When？什么時間做？
產品經理的需求來源眾多，可能來自一線市場人員，可能來自身旁油膩的領導。可能來自用戶反饋的一條吐槽…無論需求來自哪里，首先要搞清楚的就是這個需求涉及的問題：
在什么樣的場景下？
面向哪些目標用戶？
解決了哪些問題？
帶來了什么價值？
梳理清楚問題后，拆分問題：
哪些是主要問題？
哪些是次要問題？
重不重要？
緊不緊急？
將每個問題拆解后下一步就是帶著PRD文檔找親愛的數據分析師童鞋與產品經理汪一起溝通，解決以下問題：
每個問題應該怎么量化？
量化指標是什么？
怎么通過數據定義每個問題以及整個需求的成功與否？
有哪些輔助指標？
定義好數據指標后，此時則需要數據產品或者數據分析師定義埋點。
How?怎么定義埋點？
無規則不成方圓，良好的定義規范可以幫助埋點相關人員更好的維護，以及理解，極高的提升工作效率，降低推倒重來的風險，基于此分享一份埋點的定義規范幫助各位看官老爺以后維護自己產品的埋點。
使用此規范后，本汪一人就可以維護一個APP版本（包含點擊事件、曝光事件、停留事件）累計1500多個埋點，井然有序，完全不會亂。
（懷念那些加班維護埋點跑數的日日夜夜，讓我與看門大叔成了摯友，結下了深厚的友誼。咳咳，此處應該有掌聲…）
埋點分類概述：
首先從事件屬性這個維度上分為三份Excel（點擊事件表、曝光事件表、停留事件表）
其次每一個事件表中新建三份子表（Sheet）,以點擊事件表為例拆分為：首頁事件集合、列表頁事件集合、詳情頁事件集合
每當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對應的撥打電話按鈕。
記錄規則字段：
定義什么情況下觸發埋點，例如：在列表頁點擊一次記錄一次
備注：
用于描述當前埋點什么時間新增？什么時間修改過？原因？什么時間被刪除？誰刪除的？等信息記錄，此處好多看官可能以為寫不寫無所謂，但是為了信息的完整性和可追溯性最好每一次變動都要備注。
關于埋點數據和埋點數據監控的內容就分享到這兒！更多實用知識經驗，盡在 m.apearl.cn

數據分析入門 初識數據埋點 埋點數據監控

數據分析入門初識數據埋點埋點數據監控