1. 關於數據埋點，你需要知道的技術方案和規范流程
埋點是數據採集的專用術語，在數據驅動型業務中，如營銷策略、產品迭代、業務分析、用戶畫像等，都依賴於數據提供決策支持，希望通過數據來捕捉特定的用戶行為，如按鈕點擊量、閱讀時長等統計信息。因此，數據埋點可以簡單理解為：針對特定業務場景進行數據採集和上報的技術方案。
數據埋點非常看重兩件事，一個是數據記錄的准確性，另一個則是數據記錄的完備性。
先講數據的准確性。數據埋點非常強調規范和流程，因為參數的規范與合法，將直接影響到數據分析的准確性，如果准確性得不到保障，那麼所有基於埋點得出的結論，都是不可信的。辛辛苦苦做了很久的方案，一旦因為一個疏忽的小問題，導致下游集中投訴，其實非常劃不來。
道理每個人都懂，但現實情況中，數據埋點所面對的客觀環境，其實非常復雜，例如：
因此本文有非常長的篇幅來寫流程問題，其實是非常有必要的。
再講數據的完備性。因為埋點主要是面向分析使用，對用戶而言是個額外的功能，因此埋點的業務侵入性很強，很容易對用戶體驗造成影響。別的不說，僅僅是流量的消耗，就很容被用戶噴。因此，要提前想清楚，我們要採集哪些東西，因為修改方案的成本，是傷不起的。
通常情況下，我們需要記錄用戶在使用產品過程中的操作行為，通過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，行為、事件的發生數量。
很多時候，數據是需要多方驗證的，存在一定的上下游信息不同步問題，比如對某個默認值的定義有歧義，日誌統計會有效的發現這類問題。
第五步，發布上線。
應用的發布上線通常會有不同的周期，例如移動端會有統一的發版時間，而網頁版只需要根據自己的節奏走，因此數據開始統計的時間是不同的。最後，應用應當對所有已發布的埋點數據，有統一的管理方法。
大多數時候，數據埋點的技術方案，只需要設計一次，但數據准確性的驗證，卻需要隨著產品的生命周期持續下去，因此僅僅依靠人肉來准確性驗證是不夠的，我們需要平台來支持自動化的工作。埋點的准確性，大體有兩種方法保障：一種是灰度環境下驗證真實用戶數據的准確性；另一種則是在線上環境中，驗證全量數據的准確性。因此，發布上線之後，後續的管理動作，應該是對現有流程的自動化管理，因為團隊大了，需要埋點的東西多種多樣，讓平台自己測試、自動化測試，就是很多測試團隊必須走的路
2. 在mac中web前端頁面埋點怎麼測
1234567891011大於648寬度@media screen and (max-width:648px){div{ width:100%; align:center; }}小於648寬度@media screen and (min-width:648px){ div{width:100%;}}使用css判斷下解析度寬度就可以了
3. 想問問web埋點第三方平台選擇哪個阿
web埋點主要是為了採集數據，ab測試也需要在web上埋點採集重點業務數據，這樣測試才能有的放矢，吆喝科技提供的AppAdhoc
AB Testing可以實現快速簡單的web埋點。
4. 網頁里埋點怎麼製作
埋點：監控用戶點擊的每一步動作。
它不做頁面相關的事情而是把用戶當前點擊的東西，傳到伺服器，記錄用戶點擊的每一步。
網頁設置埋點的方法如下：
在2的位置插入<a name="2"></a>
懸浮導航那裡插入<a href="#2">點擊我連接到2</a></b>
錨點的名字是可以隨便改的。</b>
頁面埋點的作用，其實就是用於流量分析。而流量的意思，包含了很多：頁面瀏覽
(PV)、獨立訪問者數量(UV)、IP、頁面停留時間、頁面操作時間、頁面訪問次數、按鈕點擊次數、文件下載次數等。