編輯導(dǎo)語：在產(chǎn)品運(yùn)行流程中，數(shù)據(jù)分析尤為重要。有效的數(shù)據(jù)分析有助于優(yōu)化產(chǎn)品設(shè)計(jì)、助推產(chǎn)品運(yùn)營，有利于用戶體驗(yàn)的提升與產(chǎn)品后續(xù)的迭代升級(jí)。而合理的數(shù)據(jù)埋點(diǎn)可以幫助跟蹤用戶情況、采集數(shù)據(jù)以反饋信息。本篇文章里，作者介紹了快速學(xué)會(huì)數(shù)據(jù)埋點(diǎn)的方法，一起來看一下。

對(duì)于產(chǎn)品經(jīng)理、運(yùn)營、數(shù)據(jù)分析師來說，數(shù)據(jù)的重要性非比尋常，直接影響最終的決策，好的數(shù)據(jù)源才是數(shù)據(jù)分析的基礎(chǔ)。而數(shù)據(jù)分析的第一步就得做好數(shù)據(jù)的埋點(diǎn)工作，也是最為重要的環(huán)節(jié)之一。

本來近5000字和大家一起聊聊如何快速學(xué)會(huì)埋點(diǎn)操作，歡迎查缺補(bǔ)漏，本文目錄如下：

1. 什么是埋點(diǎn)；
2. 埋點(diǎn)的作用；
3. 埋點(diǎn)方式 （3種）；
4. 埋點(diǎn)步驟 （6大步）。

一、什么是埋點(diǎn)

所謂“埋點(diǎn)”，是數(shù)據(jù)采集領(lǐng)域的術(shù)語，指的是針對(duì)特定用戶行為或事件進(jìn)行捕獲、處理和發(fā)送的相關(guān)技術(shù)及其實(shí)施過程。在此過程中收集所需信息，以跟蹤用戶的使用情況，最后分析數(shù)據(jù)作為后續(xù)迭代產(chǎn)品或者運(yùn)營工作的數(shù)據(jù)支撐。

埋點(diǎn)也是為了滿足快捷、高效、豐富的數(shù)據(jù)應(yīng)用而做的用戶行為過程及結(jié)果記錄。數(shù)據(jù)埋點(diǎn)是一種常用的數(shù)據(jù)采集的方法。埋點(diǎn)是數(shù)據(jù)的來源，采集的數(shù)據(jù)可以分析網(wǎng)站/APP的使用情況，用戶行為習(xí)慣等，是建立用戶畫像、用戶行為路徑等數(shù)據(jù)產(chǎn)品的基礎(chǔ)。

比如訂單成交率：我們進(jìn)入到商品詳情頁操作，同時(shí)按要求進(jìn)行數(shù)據(jù)采集和上報(bào)，告訴服務(wù)器我們主動(dòng)干了什么或者被動(dòng)出發(fā)了什么？然后進(jìn)入訂單結(jié)算頁面，進(jìn)行其他操作，以此類推。

最后后臺(tái)可以統(tǒng)計(jì)出各個(gè)點(diǎn)擊事件和預(yù)置事件，根據(jù)得到的數(shù)據(jù)還原出用戶的各種行為，最終將這些數(shù)據(jù)可視化出來，進(jìn)行深入分析。

二、埋點(diǎn)的作用

提高渠道轉(zhuǎn)化：通過跟蹤用戶的操作路徑，找到用戶流失的節(jié)點(diǎn)，比如支付轉(zhuǎn)化率，通過下圖的漏斗分析，就能分析出用戶在哪個(gè)環(huán)節(jié)流失率最大，找到問題并給予優(yōu)化。

圖1：支付率漏斗分析

• 精準(zhǔn)客戶運(yùn)營：按照一定需求對(duì)用戶打標(biāo)簽或分組，實(shí)現(xiàn)精準(zhǔn)營銷、智能推薦（千人千面——等。比如根據(jù)（電商）用戶瀏覽行為、收藏行為、加購行為、 購買行為，可用按商品到底等維度進(jìn)行分組，推薦不同價(jià)格的商品給不同分組的用戶。
• 完善客戶畫像：基本屬性（性別、年齡、地區(qū)等），行為屬性；
• 數(shù)據(jù)分析：埋點(diǎn)作為原料放在數(shù)據(jù)倉庫中。提供渠道轉(zhuǎn)化、個(gè)性推薦等；
• 改善產(chǎn)品：通過用戶行為分析產(chǎn)品是否有問題，例如用戶有沒有因?yàn)樵O(shè)計(jì)按鈕過多導(dǎo)致用戶行為無效等問題，以此發(fā)現(xiàn)功能設(shè)計(jì)缺陷等。

三、埋點(diǎn)方式

埋點(diǎn)方式分為：代碼埋點(diǎn)、可視化埋點(diǎn)、無埋點(diǎn)（全埋點(diǎn)）。

1. 代碼埋點(diǎn)

它的技術(shù)原理也很簡單，在APP或網(wǎng)站加載的時(shí)候，初始化第三方服務(wù)商數(shù)據(jù)分析的SDK，然后在某個(gè)事件發(fā)生時(shí)就調(diào)用SDK里面相應(yīng)的數(shù)據(jù)發(fā)送接口發(fā)送數(shù)據(jù)。目前，國內(nèi)的主要第三方數(shù)據(jù)分析服務(wù)商有百度統(tǒng)計(jì)、友盟、TalkingData、神策等。

優(yōu)點(diǎn)：

靈活性強(qiáng)，使用者可以比較方便的自定義屬性、事件，傳遞各種所需的數(shù)據(jù)到服務(wù)端。

缺點(diǎn)：

1. 人力成本高，每一個(gè)埋點(diǎn)都需要技術(shù)人員手動(dòng)的添加代碼；
2. 更新成本較大，每一次更新埋點(diǎn)方案，可能都需要改代碼。

2. 可視化埋點(diǎn)

又稱框架化埋點(diǎn)，利用可視化交互手段，業(yè)務(wù)人員都可以直接在頁面上進(jìn)行簡單圈選，以追蹤用戶的行為（定義事件），節(jié)省了開發(fā)時(shí)間。不過可視化埋點(diǎn)仍需要先配置相關(guān)事件，再采集。

優(yōu)點(diǎn)：

1. 可視化埋點(diǎn)很好地解決了代碼埋點(diǎn)的人力成本高和更新成本較大的問題；
2. 只需一開始技術(shù)在頁面接入SDK的代碼，后續(xù)埋點(diǎn)只需業(yè)務(wù)人員自己按規(guī)則操作即可，無需開發(fā)再次接入。

缺點(diǎn)：

1. 可視化埋點(diǎn)無法做到自定義獲取數(shù)據(jù)，覆蓋的功能有限，目前并不是所有的控件操作都可以通過這種方案進(jìn)行定制；
2. 上報(bào)行為信息容易受限。

圖2：諸葛IO可視化埋點(diǎn)部分操作

3. 無埋點(diǎn)

無埋點(diǎn)是指開發(fā)人員集成采集 SDK 后，SDK 便直接開始捕捉和監(jiān)測用戶在應(yīng)用里的所有行為，并全部上報(bào)，不需要開發(fā)人員添加額外代碼。

或者是說用戶展現(xiàn)界面元素時(shí)，通過控件綁定觸發(fā)事件，事件被觸發(fā)的時(shí)候系統(tǒng)會(huì)有相應(yīng)的接口讓開發(fā)者處理這些行為。

使用者通過管理后臺(tái)的圈選功能來選出自己關(guān)注的用戶行為，并給出事件命名。之后就可以結(jié)合時(shí)間屬性、用戶屬性、事件進(jìn)行分析了，所以無埋點(diǎn)并不是真的不用埋點(diǎn)了。

優(yōu)點(diǎn)：

1. 由于采集的是全量數(shù)據(jù)，所以產(chǎn)品迭代過程中是不需要關(guān)注埋點(diǎn)邏輯的，也不會(huì)出現(xiàn)漏埋、誤埋等現(xiàn)象；
2. 無埋點(diǎn)方式因?yàn)槭占氖侨繑?shù)據(jù)，可以大大減少運(yùn)營和產(chǎn)品的試錯(cuò)成本，試錯(cuò)的可能性高了，可以帶來更多啟發(fā)性的信息；
3. 無需埋點(diǎn)，方便快捷。

缺點(diǎn)：

1. 缺點(diǎn)與可視化埋點(diǎn)相同，未解決個(gè)性化自定義獲取數(shù)據(jù)的問題，缺乏數(shù)據(jù)獲取的靈活性；
2. 無埋點(diǎn)采集全量數(shù)據(jù)，給數(shù)據(jù)傳輸和服務(wù)器增加壓力；
3. 無法采集自定義屬性、事件。

圖3：GrowingIO無埋點(diǎn)部分操作

四、埋點(diǎn)步驟

那么，埋點(diǎn)操作過程又是怎樣的呢？一般可以分成以下六個(gè)步驟：確定目標(biāo)/指標(biāo)、數(shù)據(jù)采集規(guī)劃、埋點(diǎn)采集數(shù)據(jù)、數(shù)據(jù)評(píng)估和數(shù)據(jù)分析、確定優(yōu)化方案、如何評(píng)估解決方案的效果。

1. 確定目標(biāo)/指標(biāo)

為什么要有埋點(diǎn)指標(biāo)呢，因?yàn)楫a(chǎn)品需要量化，量化了之后才知道產(chǎn)品做得好不好。所以在真正設(shè)計(jì)埋點(diǎn)之前，就要想好怎么分析這些埋點(diǎn)，只有確定好了分析思路，你才知道需要哪些埋點(diǎn)。

比如，我們發(fā)現(xiàn)App每天的日活很高，但是最終完成付款卻很少。那么我們的目標(biāo)就是提高支付轉(zhuǎn)化率，了解為什么用戶沒有有效支付，是哪一個(gè)環(huán)節(jié)讓用戶猶豫了。

我們一起看看常見的指標(biāo)有哪些：

• PV（page view）：即頁面瀏覽量，用戶每次對(duì)頁面訪問均被記錄計(jì)數(shù)；
• UV（unique visitor）：即獨(dú)立訪客，訪問您網(wǎng)站的一臺(tái)電腦客戶端為一個(gè)訪客，00:00-24:00內(nèi)相同的客戶端只被計(jì)算一次；
• 轉(zhuǎn)化率：只在一個(gè)統(tǒng)計(jì)周期內(nèi)，完成轉(zhuǎn)化行為的次數(shù)占總數(shù)的比率；
• 活躍度：主要衡量產(chǎn)品的粘性，用戶的穩(wěn)定性以及核心用戶的規(guī)模，觀察產(chǎn)品在線的周期性變化，如日活、月活；
• 留存率：在統(tǒng)計(jì)周期（周/月）內(nèi)，每日活躍用戶數(shù)在第N日仍啟動(dòng)該App的用戶數(shù)占比的平均值。其中N通常取2、3、7、14、30，分別對(duì)應(yīng)次日留存率、三日留存率、周留存率、半月留存率和月留存率。

2. 數(shù)據(jù)采集規(guī)劃

只有對(duì)產(chǎn)品的結(jié)構(gòu)和邏輯足夠了解，才知道哪些是需要關(guān)注的數(shù)據(jù)和指標(biāo)，以及怎樣通過對(duì)這些指標(biāo)的監(jiān)控實(shí)現(xiàn)最終的目標(biāo)，因此這時(shí)我們需要將產(chǎn)品功能抽象化、邏輯化和結(jié)構(gòu)化，拆分成具體的邏輯層次。

比如之前圖1：支付率漏斗分析的目標(biāo)，我們需要拆解用戶從進(jìn)入App頁面到完成支付的每一個(gè)步驟的數(shù)據(jù)，每一次輸入的數(shù)據(jù)。比如：進(jìn)入商品詳情頁（PV/UV）→點(diǎn)擊購買（次數(shù)） →提交訂單（次數(shù)） →支付操作（結(jié)果返回）等步驟。

在這環(huán)節(jié)我們可能要輸出一份埋點(diǎn)文檔，這是埋點(diǎn)需求分析結(jié)果的落地方案。不同平臺(tái)、不同渠道，對(duì)于業(yè)務(wù)需求的不同，所產(chǎn)出的埋點(diǎn)文檔結(jié)構(gòu)和埋點(diǎn)方案都不同，接下來以神策平臺(tái)埋點(diǎn)文檔進(jìn)行大致講解。

1）公共屬性

如果某個(gè)事件的屬性，在所有事件中都會(huì)出現(xiàn)，可以將該屬性設(shè)置為事件公共屬性。設(shè)置公共屬性后，之后觸發(fā)的所有事件，都會(huì)自動(dòng)加上設(shè)置的公共屬性。

2）預(yù)置事件/預(yù)置屬性

預(yù)置事件指平臺(tái)已經(jīng)定義好的事件，后端埋點(diǎn)時(shí)，無法自動(dòng)采集預(yù)置屬性，需要手動(dòng)傳輸（其他平臺(tái)可能會(huì)有不同定義）。

圖4：預(yù)置事件

圖5：預(yù)置屬性

3）自定義事件

產(chǎn)品經(jīng)理和技術(shù)人員約定好相關(guān)規(guī)則，如事件命名規(guī)則、變量命名規(guī)則等，然后才可以開始自定義自己想要的事件。自定義事件主要由事件名稱、參數(shù)、參數(shù)值組成。

列舉一個(gè)“取消訂單”埋點(diǎn)自定義事件：從文檔中可看出cancelOrder是取消訂單的事件名，同時(shí)cancelOrder時(shí)間被觸發(fā)后，可傳入order_id （訂單ID）、order_amount （訂單金額）等參數(shù)。

3. 埋點(diǎn)采集數(shù)據(jù)

如果我們采用的是代碼埋點(diǎn)的話，那就需要把4.2整理好埋點(diǎn)文檔交給技術(shù)人員，讓他們通過代碼的手段去埋點(diǎn)。

這里要注意一下，手工埋點(diǎn)流程存在著較大的數(shù)據(jù)風(fēng)險(xiǎn)：

• 埋點(diǎn)名稱不規(guī)范不統(tǒng)一，對(duì)于一些參數(shù)的定義也較為隨意，這樣就容易造成后續(xù)的埋點(diǎn)名稱冗余且混亂，不利于后續(xù)的統(tǒng)一管理；
• 流程中諸多環(huán)節(jié)均為口頭溝通，產(chǎn)品驗(yàn)收較為繁瑣，某個(gè)版本漏埋點(diǎn)或埋點(diǎn)不正確的風(fēng)險(xiǎn)大大提高，對(duì)于數(shù)據(jù)的及時(shí)提供帶來較大隱患。

如果是可視化埋點(diǎn)或者無埋點(diǎn)，那么由使用者通過管理后臺(tái)的按照規(guī)則進(jìn)行操作，基本上不需要技術(shù)人員操作。

埋點(diǎn)操作完成后，要對(duì)埋點(diǎn)采集的數(shù)據(jù)進(jìn)行觀測：每個(gè)事件是否正常上傳數(shù)據(jù)？采集到數(shù)據(jù)是否正常范圍（過大或過?。?/p>

4. 數(shù)據(jù)評(píng)估和數(shù)據(jù)分析

在一段時(shí)間的數(shù)據(jù)采集之后，形成相應(yīng)的數(shù)據(jù)樣本，要注意的是時(shí)間上過短，或者用戶很少的數(shù)據(jù)是沒有多大意義的。

思考一下，收集上來的數(shù)據(jù)質(zhì)量如何，數(shù)據(jù)該如何分析呢？數(shù)據(jù)分析的方式還是比較多，這里不重點(diǎn)展開說，接下來列舉一些常用的分析方法。

1）對(duì)比分析

通常用于對(duì)比迭代前與迭代后的數(shù)據(jù)對(duì)比。

2）分布分析

通常用于分析特定行為的在某個(gè)維度的分布情況，可以展現(xiàn)出用戶對(duì)產(chǎn)品的依賴程度，分析客戶在不同地區(qū)、不同時(shí)段所購買的不同類型的產(chǎn)品數(shù)量、購買頻次等。

如電商APP的下單行為，一天24h的下單量分布，來分析一天內(nèi)哪個(gè)時(shí)間內(nèi)是下單高峰期。

3）漏斗分析

反映用戶行為狀態(tài)以及從起點(diǎn)到終點(diǎn)各階段用戶轉(zhuǎn)化率情況的重要分析模型，比如上面提到的電商下單流程的轉(zhuǎn)化率。

4）用戶路徑分析

用戶在 APP 或網(wǎng)站中的訪問行為路徑。為了衡量網(wǎng)站優(yōu)化的效果或營銷推廣的效果，以及了解用戶行為偏好，時(shí)常要對(duì)訪問路徑的轉(zhuǎn)換數(shù)據(jù)進(jìn)行分析。

以電商為例，買家從登錄網(wǎng)站／APP 到支付成功要經(jīng)過首頁瀏覽、搜索商品、加入購物車、提交訂單、支付訂單等過程（用戶真實(shí)的選購過程是一個(gè)交纏反復(fù)的過程）。

5）留存分析

用來分析用戶參與情況/活躍程度的分析模型，考察進(jìn)行初始行為的用戶中，有多少人會(huì)進(jìn)行后續(xù)行為。這是用來衡量產(chǎn)品對(duì)用戶價(jià)值高低的重要方法。常見指標(biāo)有次日留存、7日留存、15日留存、30日留存等。

上述是一些常用的分析思路，除此之外還有很多：點(diǎn)擊分析、用戶分群分析、屬性分析、行為事件分析等等，感興趣的同學(xué)可以自行學(xué)習(xí)。

5. 確定優(yōu)化方案

產(chǎn)品經(jīng)理的職責(zé)就是發(fā)現(xiàn)問題，然后解決問題。

通過數(shù)據(jù)分析來定位問題，找到影響上述量化指標(biāo)的產(chǎn)品問題點(diǎn)在哪里？

比如：確認(rèn)訂單到支付這步的轉(zhuǎn)化率這么低情況有哪些？可能是用戶無法在確認(rèn)訂單頁面查看商品細(xì)則，為了返回上一頁，因此放棄了付款，也可能是用戶想修改商品數(shù)量或規(guī)格，但是確認(rèn)訂單頁面不能修改，因此放棄了付款，當(dāng)然也有可能是提交支付按鈕存在Bug或者理解的偏差等等。

最后找到了問題，就得對(duì)癥下藥，制定解決方案。

6. 如何評(píng)估解決方案的效果？

優(yōu)化方案上線，我們的工作不意味就結(jié)束了，重點(diǎn)要觀察對(duì)應(yīng)的指標(biāo)有所提高或者降低，與優(yōu)化前的版本相比較是否有所改善。很多時(shí)間往往不可能一步到位就把問題解決掉，需要迭代優(yōu)化，不斷通過數(shù)據(jù)跟蹤來修正設(shè)計(jì)策略，達(dá)到我們最終的設(shè)計(jì)目標(biāo)。

大數(shù)據(jù)時(shí)代的到來，對(duì)產(chǎn)品經(jīng)理提出了更加嚴(yán)格的數(shù)據(jù)分析要求，一個(gè)懂?dāng)?shù)據(jù)分析的產(chǎn)品經(jīng)理可以利用數(shù)據(jù)驅(qū)動(dòng)產(chǎn)品設(shè)計(jì)優(yōu)化，并提升客戶體驗(yàn)，實(shí)現(xiàn)更多的價(jià)值。

#專欄作家#

道三，微信公眾號(hào)：產(chǎn)品大秘籍，人人都是產(chǎn)品經(jīng)理專欄作家。以前寫過代碼，現(xiàn)在產(chǎn)品圈摸爬滾打，專注于電商領(lǐng)域產(chǎn)品設(shè)計(jì)、主要分享電商和供應(yīng)鏈領(lǐng)域知識(shí)點(diǎn)。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。