產品助理的職位描述中有一條：「知道如何埋數據點，取數據」 是什麼意思？

懇請諸位前輩簡述下埋點的基本策略和原則，並舉例分析

---

入門： 在代碼的關鍵部位植入統計代碼，用來追蹤每次用戶點擊/行為， 統計關鍵功能的使用次數。

中級： 通過植入多段代碼追蹤用戶連續行為，以及通過建立模型來量化用戶操作行為。

高級： 能夠通過和開發人員的溝通和共同學習樹立團隊的數據意識。以數據說話。為了達到這個目的建立產品的數據系統，埋點只是其中一個環節。

對於產品助理，在經驗不足的情況下，建議與具體開發的程序員多溝通，多學習。

---

數據運營，大致分為這幾個流程：明確目的，埋點採集，數據存儲，數據分析，數據展現，業務應用，效果分析。

（1）明確目的

數據並不是平白無故出現的，而是要經過系統的規劃，然後在開發過程中把相應的數據報上來。

數據分析是一個假設與論證的過程，「先有分析，再有數據」，運營人員一定事先知道自己要做什麼樣的分析：

• 出於什麼目的？希望得出什麼結論？

• 相應的流程、路徑是怎麼樣的？

• 整個流程要用到什麼數據？

我們以一個常見的小案例來貫串說明數據上報的完整過程，其他所有數據收集大同小異，聰明的你一定可以觸類旁通的。

假如我們要監測首頁焦點圖的運營情況，那麼首先是明確目的：

（2）埋點採集

產品經理剛開始可能會對一個名詞感到陌生，就是「埋點」。顧名思義，埋點的意思就是在某個地方埋下一個收集數據的點，更專業的說法是關鍵節點植入統計代碼。

目前流行的埋點有三種方式，各有優缺點。

①代碼埋點

定義：在APP或網頁初始化的時候，通過第三方SDK或者自己植入統計代碼收集數據，某個時間發生時，就會向伺服器發送一段統計日誌。

代表應用：中大型企業一般自己收集；第三方SDK有百度統計、友盟、TalkingData等等。

優點：（1）使用者可以控制精準，可以非常精確地選擇什麼時候發送數據；（2）同時使用者可以比較方便地設置自定義屬性、自定義事件，傳遞比較豐富的數據到服務端。

缺點：（1）埋點代價比較大，每一個控制項的埋點都需要添加相應的代碼，不僅工作量大，而且限定了必須是技術人員才能完成；（2）靈活性差，每一次更新埋點方案，都必須改代碼，而且總會有相當多數量的用戶不喜歡更新APP，這樣埋點代碼也就得不到更新了

#代碼埋點 via 友盟

②可視化埋點

定義：用所見即所得方式植入統計事件，不需要專門編寫代碼或調用SDK。

代表應用：國外Mixpanel；國內的 TalkingData、諸葛IO 等也都提供了類似的技術手段。

優點：（1）簡單易用，第一不懂代碼的人也可以通過Mixpanel後台配置統計錨點並實時下發到客戶端生效；（2）靈活性高，直接避免手工修改代碼，需要更新版本成本才能生效的笨拙方式。

缺點：（1）埋點能夠覆蓋的功能有限的，目前並不是所有的控制項操作都可以通過這種方案進行定製；（2）數據維度局限性大，不能自己設置屬性，只能收集點擊事件。例如搜索，只能發送搜索按鈕點擊事件，而不能上傳用戶搜索關鍵詞。

#可視化埋點 via mixpanel

③無埋點

定義：儘可能收集所有的控制項的操作數據，然後再通過界面配置哪些數據需要在系統裡面進行分析。

代表應用：國外Heap Analytics，Mixpanel；國內諸葛IO，TalkingData，Growing IO。

優點：（1）數據全面，這種方式持續不斷地自動向伺服器發送數據，因此不會出現人為疏忽遺漏情況；（2）更有利於數據分析，收集數據非常全面，有助於使用者進行完整分析，例如可以看到一個頁面上每個控制項的點擊率分別是多少，有助於了解用戶行為。

缺點：（1）靈活性差，不能自定義屬性；（2）數據量大，傳輸速度慢，給伺服器、資料庫帶來不小的壓力。

#無埋點 via Heap

*關於數據埋點，這裡有一篇博文講得非常詳細，感興趣的讀者可以進一步閱讀：數據採集與埋點

（3）數據存儲

程序上報數據會同時把非常多東西傳過來，就像下圖所示，是一段上報的日誌。那麼在服務端的程序就要有一個處理過程，即ETL，是英文 Extract-Transform-Load 的縮寫，用來描述將數據從來源端經過抽取（extract）、轉換（transform）、載入（load）至目的端的過程。這一過程把繁雜的數據處理成規範的數據表結構。

抽取：將數據從各種原始的業務系統中讀取出來，這是所有工作的前提。

轉換：按照預先設計好的規則將抽取得數據進行轉換，使本來異構的數據格式能統一起來。

裝載：將轉換完的數據按計劃增量或全部導入到數據倉庫中。

#混雜的原始數據

#ETL過程

（4）數據分析

上一步處理的結果是建立了資料庫，但依然是原始的數據，不能直接拿來用。還需要寫數據分析腳本，把海量的原始數據分析出一個普通人可看懂的數據結果。

回到我們一開始說的焦點圖監控項目，我們需要的是焦點圖的使用情況，但是資料庫可是有非常多的數據。假如我們APP的日活躍用戶有1億，那麼資料庫原始的數據可能每天都會產生100億條，甚至更多，取決於業務需要上報的數據多少。

例如，我們需要看每個位置焦點圖分別有多少個人點擊，那麼這裡數據分析的過程是：以位置為維度，計算點擊的人數（根據用戶ID去重計算），點擊次數（計算所有點擊日誌總條數）。

確定好所需要的維度、指標、計算方法之後，需要數據分析人員編寫代碼從資料庫中提取和計算，一般所用的是SQL語言。SQL是結構化查詢語言(Structured Query Language)，主要用於資料庫操作。可能也是產品經理能夠接觸到的最簡單但是最實用的語言，簡單掌握常用語句之後就可以自己從資料庫中提取想要的數據，而不必勞煩程序員同事。

這一步數據分析至關重要，是讓數據有「生命」的過程。如果數據只是存儲在資料庫，那麼它們還是一堆無價值的位元組，然而通過你的提取和分析，就變成反映和指導業務運行情況的羅盤。

#從數據收集到數據分析

（5）報表展示

終於到了最關鍵的一步：把數據分析的結果用直觀的報表展示出來。

並不是每個人都懂數據分析的過程，例如你的老闆、運營夥伴、商業化同事等等，他們可能完全對我們上述的過程沒有任何概念。但是他們卻需要直觀地看到數據，所以我們用可視化報表展現給所有人看數據分析結果。

關於報表，一般大公司都有自己特別開發的系統，一方面是靈活性高，另一方面也是考慮到數據安全，不會使用第三方服務。像阿里巴巴有數據魔方、騰訊有羅盤/遊戲分析系統等。市面上也有很多第三方數據服務，例如友盟、百度分析、谷歌分析、騰訊雲分析等。

對於中小企業，尤其是創業公司來說，自己搭建一個數據系統是不現實的，用第三方服務可以節約數據處理的時間、人力成本，極大地提高起步階段的效率。然而隨著企業發展壯大，建立自己的數據體系也要提上日程，數據是企業最寶貴的資產，掌握在自己手裡更加靈活和安全。

#數據報表

（6）業務應用

數據報表可不是看看就算的，數據反映了業務運轉情況，根據結果來改進業務。

例如，我們通過數據報表發現，只要是硬廣類的焦點圖（品牌廣告、兄弟產品互推廣告），點擊率都非常低，嚴重影響了用戶體驗。那麼以後就需要限制這類焦點圖的投放，比如只能一周一次，並且位置要排在第4位之後。

通過數據來指導產品運營，才能形成數據化運營的閉環。

（7）效果反饋

我們曾說到，數據是「尚方寶劍」。那麼為了強調數據化運營的標準，我們需要將運營策略展現給大家，使得每個利益相關者（stakeholder）明白其中的運營規則，以及這種運營規則下取得的成果。

互聯網團隊有個獨特的現象，往往是業務人員（產品經理、運營、商業化）主導項目的發展，他們對項目的進展、成果和問題掌握著第一線的信息。但是與此同時，其他利益相關者缺乏足夠信息。信息不均衡也會影響團隊的工作效率。

因此優秀的團隊總是會把項目結果反饋給所有利益相關者，讓大家同時知道項目的收穫和需要改進的問題，有助於大家繼續朝著同一個目標前進。

例如我手上的活動、產品改進等，取得了比較好的數據上漲，又或者收到很多用戶的讚賞，都會通過群或者郵件的方式告知項目組同事。程序員和設計師同學表示看到結果反饋會更有士氣去工作，因為這證明了大家的付出是有回報的。

上面7個過程是一個比較完整的數據運營流程，每個項目中可能並不會涉及到這麼多環節，但產品經理如果能完整經歷一次流程，會對數據運營有個非常深入的了解。

---

作為一名產品助理相對考驗的是你的潛力，一般的網站埋數據點和取數據則是簡單的窗口或者頁面或者是按鈕banner一些的數據，並且以承上啟下的方式找到該數據的來源和落地。之後對數據進行分析和整理。總結出期間用戶的行為以及盈利點。小朱大哥說得對，前期一定要多向開發學習，知道如何設置數據id，如何進行數據追查。

---

瘦腰。

大家回答已經比較全面了，不贅述。試考慮如下問題：

一個app，已知下載量。

欲知：激活量，註冊用戶數，註冊率，註冊成功率，活躍用戶數（天），每功能點擊數（每用戶），頁面停留時間。

假設沒有第三方支持，怎麼埋點。

---

我覺得是針對用戶行為數據和產品運營數據，知道哪些數據有價值，如何記錄和分析

---

1. 確定業務目標
2. 確定衡量目標達成好壞的評價維度
3. 根據評價維度，轉換為對應的數據指標
4. 分析影響數據指標的環節
5. 根據每個環節特性，設立可表徵此環節的數據項
6. 根據數據項，轉換為產品中用戶具體動作行為的統計點

---

數據的作用 最基本的目的 知道用戶的行為是否符合產品設計的預想 然後改進設計

用玩家在遊戲中副本的行為來舉例

設計一個 A B 兩個boss的單人副本 希望80%的玩家打倒B所需時間多於A的2倍

那麼如何用監測這個設計

---------設計驗證--------

1、埋點

觸發A時的時間點a1，擊倒A的時間點a2

觸發B時的時間點b1，擊倒B的時間點b2

2、取數據，數據轉化，分析，驗證

時間段

a = a2 - a1

b = b2 - b1

然後對b &> 2a的情況進行佔比統計

發現這其中的玩家沒有達到80%

3、發現問題

那請問，問題發生在哪裡，如何改進

boss的屬性 b是否比a強

地形是否影響

某個門派的技能特性

等等

結合自己團隊的體驗及玩家反饋 找到一個或幾個最大的可能

---------問題驗證--------

4、再次埋點

結合上述可能再次埋點

比如猜測某個門派傷害是血量百分比扣除，大部分玩家發現後，都用這個門派去打

那為了驗證這個猜測及得到詳細的數據

埋點：進入此副本的每個門派的數量統計

5、取數據，數據轉化，分析，驗證

的確如問題推測，改進BOSS，之後再次取數據分析驗證

不對，則再次推測問題所在，根據問題再次設計埋點

有經驗的人在於盡量一次把設計驗證和問題驗證所需的埋點搞定，當問題暴露後，下一個版本就可以修復問題。而不是多次版本更新都還在找問題。

不論宏觀數據、功能數據都需要正確埋點及分析跟進，才能時時做到產品在心中有數，正確迭代改進。

---

「知道如何埋數據點，取數據」

首先是如何埋數據點：JD的意思肯定不是讓你自己寫代碼埋進去，當然如果你會寫代碼，對於產品來說就是如虎添翼了。你要知道網站上哪些地方可能是用戶的關注點，一方面是用戶訂單流上的各個步驟，另一方面是非訂單流上用戶也可能會點擊的頁面內容；在這些地方埋點。

埋點之後，將來數據分析時你得對這個埋點的各個屬性進行分析，所以你的做後台功能，把將來分析時可能需要的欄位做成功能。

到了數據分析階段，你要全面的分析埋點的各個欄位

---

http://xbin999.com/2012/01/11/%E5%88%B0%E5%BA%95%E4%BB%80%E4%B9%88%E6%98%AF%E6%95%B0%E6%8D%AE%E6%A8%A1%E5%9E%8B%E5%92%8C%E6%95%B0%E6%8D%AE%E5%BB%BA%E6%A8%A1/

請看這個鏈接，講得比較清楚

---

在我做數據產品的日子裡，從確定數據指標、數據源獲取、數據可視化等方面入手豐富我們自身的產品，還要幫助用戶運用我們的分析結論指導實際行為，對於自身產品的數據分析也經歷從無到有的過程。

關鍵指標異常提醒我們去改進數據源，我們改變導航後話題頁面轉化率有所提升，但是我的感受是：數據沒有指導我做過任何改進，它只是幫助我驗證了一些事情。

對於數據如何推動產品發展，其實很難用一個例子來說清楚。因為一個產品的推動在於功能的改進同時觀察數據的變化行為，以此來判斷功能改進是否正確。如此循環往複，通過數據來決策未來的功能，通過數據來驗證已經實現的功能。

數據tell you nothing，如果比不能理解用戶背後的行為和心理，異常永遠是異常。

產品改進的最大動力永遠是對用戶需求和產品邏輯的理解，對於用戶需求和產品體驗的忽視才是導致產品失敗的最大問題。

---

產品經理有一個重要的作用就是做正確的事情。如何評價一個事情有沒有作對，就需要用事實的數據來驗證，並且產品的迭代也是就當前數據反饋的某種問題進行迭代從而優化數據。至於怎麼埋數據這點，基本上常用的數據統計只能夠檢測pv.uv等數據，如果你想了解其他的數據需要研發進行埋點，比方說對某一個按鈕的點擊進行計數，或者對滑鼠軌跡進行記錄。

---

在關鍵數據介面處，加上統計數據，就是數據埋點，個人理解

---

我覺得是針對產品來說，用戶行為數據和產品運營數據，分析這些數據的來源，怎麼留住用戶。

---

數據埋點，在鏈接中加一串指定代碼吧，我之前做推廣的時候做過。

不知道會不會摺疊...

---

推薦閱讀：