官术网_书友最值得收藏!

2.2 用戶行為數據采集

本節以電商產品為例,講一下如何采集用戶的行為數據。

用戶行為數據的采集有如下三種方式。

(1)與第三方移動應用統計公司合作完成數據采集。

(2)采用前后端埋點結合的方式完成數據采集。

(3)采用可視化埋點與后端埋點結合的方式完成數據采集。

接下來筆者分別介紹這三種用戶行為數據的采集方式以及它們各自的優、缺點。

2.2.1 與第三方移動應用統計公司合作的數據采集方式

第一種方式是與第三方移動應用統計公司合作完成數據埋點。

前端開發工程師需要按照第三方移動應用統計公司的對接要求,集成第三方移動應用統計公司提供的數據采集SDK(Software Development Kit,即軟件開發工具包)。一般來說,第三方移動應用統計公司會提供H5端、安卓端、iOS端、小程序端的SDK。前端開發工程師完成了SDK的集成,就能在他們的后臺查看自己的應用的數據。市場上比較主流的第三方移動應用統計產品包括百度移動分析、Google Analytics、騰訊移動分析等,接入這些公司的SDK就能完成基礎數據的采集。

這種方式的優點是開發工作量少,一般每個客戶端花費1~2天的開發時間就可以完成集成,而且數據分析相關功能都不需要開發,這些第三方移動應用統計公司會直接提供相關功能。采集到的數據相對來說比較準確,因為這些產品都是比較成熟的,有很多公司都在使用,一般不會出現數據質量的問題。

不過,這種數據采集方式也有幾個缺點。

(1)產品線的流量相關數據比較豐富,但是因為只做了最基礎的頁面和按鈕埋點,很難采集到產品線的業務數據,比如對于電商產品來說,我們不但要看坑位的流量,更要看坑位的轉化率,而轉化率這個指標就涉及交易額,但是第三方移動應用統計產品是無法獲取我們產品的交易額的。如圖2-1所示,這是百度移動統計大致的演示頁面,我們只能看到流量相關數據,不能看到業務數據。

圖2-1 百度移動統計

(2)能看到的數據有限。第三方移動應用統計產品都是標準化的產品,提供的都是標準化的數據,其數據的范圍不一定能覆蓋公司所有數據方面的需求。

(3)第三方移動應用統計產品提供的數據很難同步到數據中臺的數據中心。第三方移動應用統計公司一般不會提供這樣的數據同步接口,只有產品用戶活躍度很高的大客戶才能獲得這些分析數據,小型公司則很難獲得。

2.2.2 前后端埋點結合的數據采集方式

第一種方式采集到的用戶行為數據無法結合用戶的業務數據,而通過前后端埋點結合的數據采集方式就可以解決這個問題。所有數據埋點相關的工作都是為了解決實際項目中的問題,接下來筆者以電商產品為例介紹一下如何通過前后端埋點的方式完成產品線的用戶行為數據的采集,同時會進一步介紹如何使用采集到的行為數據解決電商產品的實際問題。

(1)如何分析電商產品主路徑每天的訪問情況

用戶訪問電商產品的主路徑一般為:訪問首頁→訪問商品列表頁→訪問商品詳情頁→加購→下單→支付。

有了埋點數據就可以知道訪問主路徑每個步驟的用戶數,從而可以分析出哪兩個步驟之間的轉化率比較低,接著可以進一步分析轉化率低的原因,從而根據原因進一步優化產品。如圖2-2所示,這是一個典型的用戶訪問電商產品主路徑示意圖。

圖2-2 用戶訪問電商產品主路徑示意圖

(2)如何解決坑位的轉化率問題

電商產品都由一個個坑位組成,每個坑位分布在不同的位置,不同的商品在不同的坑位中售賣。采用與第三方移動應用統計公司合作完成數據采集的方式只能獲得坑位的流量數據,比如PV(頁面瀏覽量)和UV(獨立訪客數),但是評價一個坑位的好壞不能僅僅靠流量數據。有些坑位的流量比較高但是卻沒有產生多少交易額,有些坑位的流量很低,放在十分不顯眼的地方,卻產生了可觀的交易額,因此僅用PV、UV兩個指標衡量坑位的好壞是不公平的,需要定義一個比較公平的指標——坑位轉化率。

坑位轉化率即坑位UV與支付用戶數的比值。

使用坑位轉化率可以很好地判定一個坑位的性價比。如果坑位處于很明顯的位置,而轉化率很低,那就要分析原因,改變運營策略,比如調整圖片、調整商品、調整位置等。

(3)如何打通用戶的行為數據和用戶的業務數據

我們需要清楚地了解用戶在什么時候訪問我們的產品、訪問了哪些商品、什么時候“加購”了我們的商品、“加購”了哪些商品、什么時候買了我們的商品、買了哪些商品。用戶訪問商品的數據屬于行為數據,用戶加購、下單、支付商品的數據屬于用戶的業務數據。

(4)如何弄清楚用戶的留存情況

留存的定義分為兩種:第一種是訪問留存率,在新用戶第一次訪問后,看他接下來7天后、14天后、一個月后是否再次訪問;第二種是購買留存率,在用戶第一次支付后,看他接下來7天后、14天后、一個月后是否再次支付。通過訪問留存率,我們能清楚地看到用戶對平臺的黏性;通過購買留存率,我們能檢測平臺的價值,因為有價值才會產生交易。

接下來我們看一下如何通過前后端埋點的方式解決以上問題。

首先介紹一下技術方案。電商產品一般包含H5端、移動端(iOS端或安卓端)、小程序端。要解決以上問題,首先要針對電商產品的每個客戶端做全面的埋點,如果讓前端開發工程師采用手工埋點的方式,工作量是比較大的,而且沒有統一的數據采集標準會導致后期的數據質量比較差。市場上有很多數據采集的開源軟件供選擇,選擇這些開源的軟件一方面能節省大量的開發成本,另一方面各個客戶端的開發工程師都采用同一個采集標準,十分有利于后期的數據處理。如果開源的軟件不能滿足數據采集的需求,前端開發工程師可以使用源代碼進行一些定制開發。

市場上還有比較多的開源SDK,可以從是否開源、SDK是否支持H5端/安卓端/iOS端、部署方式是私有化還是SaaS化(采集的用戶數據是公司的重要資源,出于安全考慮,需要本地化部署)這幾個方面來考慮。如表2-1所示,這是幾個比較主流的數據產品公司的SDK,供大家參考。

表2-1 數據采集SDK對比

在選好SDK后,就可以進行下一步的工作,定義埋點的接口文檔。讓前端開發工程師按照接口文檔完成數據埋點。埋點的接口文檔主要定義如下這些內容。

● 哪些公共字段需要統一采集?

● 哪些頁面和哪些按鈕需要埋點?

● 特殊的頁面和按鈕需要通過埋點獲取什么參數?

首先看一下公共字段的定義。這些信息都封裝在SDK中,只要前端開發工程師基于SDK的開發文檔進行工程部署即可,當用戶瀏覽某個頁面或者點擊某個按鈕時,SDK就會自動收集用戶的這些基礎信息。這樣,用戶在哪里、用戶使用什么設備、用戶什么時間訪問了我們的產品等基礎數據的收集問題就解決了。具體埋點接口公共字段的定義如表2-2所示。

表2-2 埋點接口公共字段的定義

① 注:如果字段英文名帶有“$”前綴,代表其是SDK的預設字段,SDK被部署后,會自動采集該字段信息。

接下來我們看一下瀏覽頁面事件的采集。針對瀏覽頁面事件,SDK也會預設公共信息,當用戶瀏覽頁面時,我們要獲取當前的用戶是誰。如果有用戶登錄信息,我們就可以獲取用戶手機號,如果用戶未登錄,可以把瀏覽設備ID設為用戶的唯一身份標識,還要獲取當前的頁面是什么、從哪個頁面過來、當前的產品線信息等,具體信息如表2-3所示。

表2-3 瀏覽頁面事件的接口定義

為了完成用戶瀏覽事件的數據收集,需要梳理一下當前產品的每個客戶端都有哪些關鍵頁面。比如電商產品,其核心頁面有推廣頁、首頁、商品列表頁、商品詳情頁、加購頁、下單頁、支付頁等關鍵頁面,需要針對這些頁面統一進行數據采集,如表2-2所示的字段就會自動收集。對于比較重要的頁面,還可以加入自定義的參數,如表2-4所示,比如電商產品的商品詳情頁,我們要收集用戶從哪里進入商品詳情頁。用戶有可能是從坑位進入商品詳情頁的,也有可能是通過搜索方式進入商品詳情頁的,還有可能是從分類頁面進入商品詳情頁的,那么就要記錄用戶的訪問來源信息,才能具體確定商品是從哪里賣出去的,這里就需要增加坑位ID、來源類型等關鍵字段。

表2-4 商品詳情頁特殊字段信息定義

接下來筆者講一下用戶點擊事件的數據收集,其和用戶瀏覽事件的數據收集一樣,需要整理一下每條產品線都有哪些關鍵按鈕,比如電商產品的關鍵按鈕有注冊、登錄、收藏、加購、下單、支付等,根據這些關鍵按鈕,我們就可以知道用戶使用什么設備、在什么時候、點擊了電商產品的哪個按鈕。前端開發工程師需要針對這些關鍵按鈕的點擊進行埋點,點擊事件的接口定義如表2-5所示。

表2-5 點擊事件的接口定義

埋點有兩方面作用。一方面,針對前文提到的“弄清主路徑”問題,需要監控“加購”事件。電商產品主路徑中的“加購”是按鈕點擊事件而不是頁面瀏覽事件,這就需要通過埋點方式先收集數據,以后將“加購”事件轉化為頁面瀏覽事件來處理,才能更加方便地計算每一步的轉化率。另一方面,如果我們要看關鍵按鈕的點擊次數、關鍵頁面的轉化率(如登錄頁、注冊頁轉化率等),就都需要統計按鈕點擊事件。

接下來再看一下如何進行后端埋點。

電商的主路徑數據采集有個關鍵問題:用戶在“加購”后可能隔幾天才會下單,而同樣的商品進入購物車后只是令購買數量發生變化,如果出現這種情況,當用戶從購物車中進行商品下單時,我們很難通過前端埋點的方式判斷這個商品到底是從什么位置上“加購”的,所以在這種情況下就必須進行后端埋點,當用戶“加購”時可以將商品的來源信息記錄至數據庫,這樣當用戶從購物車中針對商品支付時,再將商品來源信息取出放入訂單,那么后端埋點就解決了用戶“加購”再下單這個問題。訂單來源信息一般通過JSON的形式存儲,具體格式如下。

首先需要記錄用戶是從哪個客戶端“加購”的,即使用CLIENT(客戶端)這個參數,接下來要記錄“加購”的來源信息。用戶可能是從坑位瀏覽商品并“加購”的,這時需要記錄當時坑位的SPM值(SPM是每個坑位的唯一ID);用戶也可能是從某個活動頁面進入的,公共信息中有每個事件的地址(也就是活動頁面地址),這個地址可以當成來源信息記錄下來;用戶也可能是搜索過某個關鍵字,瀏覽商品后“加購”的,可以通過KEYWORD(關鍵字)這個字段記錄用戶的搜索關鍵字是什么;用戶還有可能是通過推薦位“加購”的,可以記錄推薦場景ID(RECSCENEID)和算法ID(ALGORITHMID),這為后續做推薦算法效果的分析做基礎。

對于微信小程序端來說還有一個比較重要的場景。小程序產生的購買基本都是通過分享商品信息到微信群或者分享給微信好友實現的,那么在分享商品信息時可以記錄當前分享的客戶端(SHARECLIENT)、微信的場景值(WXAPPSCENE),微信已經定義了一套計算場景值的規則,其他的參數由分享的客戶端以及來源信息來填充,這樣我們就知道商品是從哪個客戶端、哪個坑位分享出去并產生“加購”和下單的。

前后端埋點結合的優點很明顯,采集的數據很全面。前端埋點已經有了一些通用的封裝,前端開發工程師只需做少量的開發;后端埋點解決了數據流失的問題,保證了關鍵指標數據的準確性。但是這個方式的缺點也很明顯——依賴前端開發工程師和后端開發工程師開發埋點模塊,每新增一個頁面就需要增加埋點開發的工作量。

首先,數據中臺產品經理要和產品線產品經理溝通需求,在評審需求后,需要每個客戶端的開發工程師進行開發、部署。然后,還需要測試工程師的測試。埋點的測試比較麻煩,測試工程師需要測試每個客戶端并點擊所有的頁面和按鈕,并在控制臺查看參數是否設置正確。最后,如果測試沒問題,還需要發布App新的版本,等上線后還需要進一步跟蹤。

前后端埋點結合的數據采集方式的主要缺點是:工作量比較大,需要依賴多個角色配合才能完成,整個開發過程比較煩瑣。

2.2.3 可視化埋點與后端埋點結合的數據采集方式

筆者先講一下什么是可視化埋點。

上文已經說過,前端埋點會依賴前端開發工程師,而可視化埋點則可以解決這個問題。可視化埋點的主要特點是可以讓產品/運營人員通過可視化的界面自行完成頁面和按鈕埋點配置。可視化埋點目前也有很多比較成熟的開源SDK,只要前端開發工程師將可視化埋點SDK部署完畢,產品/運營人員就可以通過可視化的操作完成普通頁面及普通按鈕的埋點工作,如圖2-3所示。

圖2-3 可視化埋點界面

可視化埋點只能針對普通的頁面和按鈕(如登錄頁面、注冊頁面、登錄按鈕、注冊按鈕、個人中心的頁面)等使用,這些頁面和按鈕只用于采集公共的信息(如設備信息、地理位置、當前用戶等),如圖2-4所示,這樣就可以知道哪個用戶在什么時間點擊了哪個按鈕、瀏覽了哪個頁面。一些重要的頁面(比如電商產品的商品詳情頁)所關聯的業務參數比較多,還是建議讓前端開發工程師使用代碼埋點的方式采集。

圖2-4 可視化埋點采集的信息

可視化埋點的優點比較明顯,這種方式進一步降低了埋點的開發成本。數據中臺在和其他產品線進行埋點合作時,只需提供可視化埋點的SDK給各條產品線,并且定義好哪些頁面和按鈕是必須進行埋點的,接下來讓產品線自行完成埋點即可。在產品線埋點完成后,數據中臺再做一次測試,檢查哪些頁面或者按鈕沒有埋點,測試通過后就基本能夠采集用戶對普通頁面或者按鈕的行為數據。由于產品的大部分頁面和按鈕都屬于普通的頁面和按鈕,并不需要十分個性化的參數,故可視化埋點可以解決產品的大部分頁面和按鈕的埋點數據的收集。可視化的埋點不但統一了數據標準,還進一步降低了埋點的工作量。

可視化埋點的缺點在于,將埋點工作都交給各條產品線完成,就必須定義好合作的機制,講清楚哪些頁面和按鈕在上線前是必須完成埋點的。另外,可視化埋點沒有解決重要按鈕、重要頁面的埋點問題,也沒有解決后端埋點的問題,這些工作還是依賴產品線前端和后端開發工程師一起完成。

主站蜘蛛池模板: 沙田区| 陈巴尔虎旗| 武城县| 祥云县| 家居| 桃园县| 家居| 潮安县| 建平县| 阿荣旗| 湘潭县| 马鞍山市| 乌海市| 丰都县| 水城县| 镇雄县| 上杭县| 甘孜| 万州区| 灵寿县| 邓州市| 连州市| 苏尼特右旗| 耒阳市| 旺苍县| 图木舒克市| 邛崃市| 昂仁县| 阿拉善右旗| 凉城县| 金门县| 清远市| 海盐县| 盐城市| 嫩江县| 西盟| 景洪市| 临武县| 长春市| 清涧县| 武穴市|