終於有人把能把資料採集給講明白了

1.資料採集的常見方式

為什麼要去研究資料採集呢?

大家可以回想一下自己在工作中是否會經常遇到以下問題：

☑ 真實資料與後臺獲取到的資料差距很大。

☑ 同一資料在不同的指標內有兩個完全不同的結果。

☑ 需要統計的資料與採集獲取的資料不是同一類。

其實，這些問題的本質都是因資料採集環節定義不清晰造成的，可見，我們必須要重視資料採集的方法與定義，而不僅僅是將需求扔給開發部門完成。

下面先來學習一下日常工作中用到的資料採集方式，具體可以分為如下兩類。

非透明採集：指看不到原始資料，只能透過統計上報採集，常見的方法如埋點。

透明採集：直接提取業務線中現有的系統資料庫中的資料，如日誌伺服器資料的整理抽取，在收款裝置的交易資料庫中抽取訂單資料等。

(定義1：資料採集方式)

在日常工作中，這兩種採集方式通常是結合使用的，可以此來豐富資料採集維度。但必須要強調的是，大家在設計資料採集方案時，一定要把握設計的度，否則很多新入行的產品經理可能會走向如下兩個錯誤極端。

1)採集資料顆粒度過細，導致應用緩慢。

很多產品經理在定義資料指標時，由於不能清楚地定位資料平臺的監控範圍，害怕遺漏，便將產品中的所有元素都埋上點，導致一個圖文資訊類產品在使用者開啟後流量消耗和看影片一樣巨大，嚴重拖累產品體驗。

2)資料統計點過少(顆粒度過大)，導致發現問題時無法定位具體原因。

當然，除了以上問題，也出現過另外一種過激的場景：為了避免應用過於臃腫，而只採集了日活、月活、留存等通用的使用者資料，當使用者量抖動變化時，根本無法定位究竟是什麼原因導致的，資料使用者看到了這樣的結果卻又無法追溯問題，內心其實比不知道使用者流失還難受。

讓我們繼續回到L公司的案例中，瞭解具體實戰中要怎麼正確進行資料採集設計。

2.資料核心採集方式：埋點

到底什麼是埋點呢?埋點的完整定義如下：

所謂埋點，又稱事件追蹤(Event Tracking)，是指標對特定標識使用者的行為或事件進行捕獲、處理與傳輸等操作的全過程。 (定義2：埋點)

通俗點來說，就是在使用者使用的客戶端中加入一個記錄者，忠實地記錄使用者的每一步操作，幫助我們洞察使用者的真正行為。例如，使用者到底喜歡什麼，厭惡什麼，從而讓我們獲取到正確的一手使用者資料。

通常情況下，一個埋點主要由三部分組成：目的、所服務的指標和埋點細節說明。

對於埋點的設計，在工作中有如下三個一般性的設計原則。

• 反應事件：必須能準確地獲取要監測的事件。
• 描述完整：必須能清晰地反饋使用者的完整行為。
• 使用者追蹤：必須能判斷出哪類使用者有問題。

滿足這三個一般性設計原則才稱得上是一個比較完整的資料埋點方案。

原則1：反應事件

在工作中我們需要統計的使用者行為是多種多樣的，因此在設計埋點時也應該按照不同的型別進行劃分，埋點的監測行為可以分為如下三類事件。

• 點選事件：使用者點選按鈕觸發的事件。
• 展現事件：使用者的操作介面中出現了多少次該事件。
• 停留事件：使用者停留在該頁面的時長。

原則2：描述完整

劃分不同的使用者事件只是完成了需要監測的事件，為了能清晰地反饋使用者行為，我們還需要將使用者的行為再做一個細分，使用者的行為可以劃分為如下兩類。

• 有效行為：指觸發了帶有業務含義的操作，通常用來分析活動/產品的有效性。比如，Banner廣告位點選、推薦商品點選等，據此來得到轉化事件的觸發率，並評估運營活動/推薦演算法的有效性。
• 點選行為：指使用者在產品內的一般性點選，通常用來幫助推進產品迭代。比如，使用者經常誤觸某些元素，我們就要分析是什麼設計誤導使用者認為那裡是可以點選的，從而進行產品迭代，將使用者的操作引導到有效行為上。

原則3：使用者追蹤

要想實現使用者追蹤，我們就需要使用多種埋點方式來獲取全面的使用者資料。在埋點技術的發展過程中，埋點一共被劃分為四類，如下表所示。

下面從兩個維度來對這幾種埋點方式進行排序。

1)從準確性上來說，程式碼埋點 = 伺服器埋點<視覺化埋點<全埋點。

2)從個人推薦上來說，程式碼埋點 = 伺服器埋點 >視覺化埋點 > 全埋點。

關於作者：劉天，曾為國家科研專案帶頭人，TMT領域投研顧問/MBA特約講師/網際網路峰會特邀演講嘉賓，先後就職於萬達、叮咚買菜等公司，負責過多個集團級中臺與電商平臺業務的產品整體規劃。

本文摘編於《高階產品經理必修課：企業戰略驅動下的資料體系搭建》，經出版方授權釋出。(ISBN：9787111694502)轉載請保留文章出處。