中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

《數(shù)據(jù)埋點(diǎn)，一次講個夠》系列文章的第二篇，討論用戶行為數(shù)據(jù)采集工作的核心——埋點(diǎn)模型。

主要討論：

• 主流的埋點(diǎn)模型–事件模型
• 按照事件模型的思路，如何設(shè)計(jì)埋點(diǎn)

下面來聊一聊埋點(diǎn)模型：

一、事件模型

埋點(diǎn)體系中一個非常重要的角度是埋點(diǎn)模型，它決定了我們以什么樣的架構(gòu)收集用戶行為信息。

換句話說埋點(diǎn)模型反應(yīng)的是數(shù)據(jù)采集的世界觀，我們用什么樣的視角去理解用戶行為；比如，以產(chǎn)品的視角，用戶和產(chǎn)品的交互可以理解為瀏覽了頁面、點(diǎn)擊了按鈕，對于頁面瀏覽的行為，埋點(diǎn)會記錄用戶id、ip、進(jìn)入頁面時間、頁面名稱等等，然后把這些數(shù)據(jù)單獨(dú)落到一個表中，后續(xù)我們基于這張表可以查詢 PV、UV 這樣的指標(biāo)。

對于點(diǎn)擊行為，埋點(diǎn)會記錄用戶id、ip、點(diǎn)擊時間、按鈕名稱、按鈕所屬頁面名稱，這些信息會落在另外的表中，后續(xù)基于這張表可以查詢點(diǎn)擊某元素的用戶數(shù)等指標(biāo)；這樣的埋點(diǎn)模型是基于產(chǎn)品視角的，我們把用戶對產(chǎn)品的操作分為幾種類型，針對不同類的行為設(shè)置不同的字段；這是 PC 時代的設(shè)計(jì)方式，埋點(diǎn)能采集到的內(nèi)容相對固定，能統(tǒng)計(jì)的指標(biāo)也比較有限，也是 PV、UV、跳出率、停留時長這些，和業(yè)務(wù)數(shù)據(jù)打通比較困難，筆者就職的上一家公司，就采用這種模型來設(shè)計(jì)埋點(diǎn)。

目前主流的埋點(diǎn)模型是「事件模型」，市面上提供用戶行為分析服務(wù)的絕大多數(shù)廠商都采用這種模型，比如，GrowingIO、神策、諸葛IO、TalkingData、友盟、Mixpanel等。

所謂的「事件模型」，其實(shí)是「事件 – 用戶模型」，簡單理解，我們把用戶的行為記錄為事件和用戶，分別存在事件表和用戶表中，事件表中記錄 Who、When、Where、What、How，即誰在什么時間，什么地點(diǎn)，以什么樣的方式，做了一件什么樣的事，用戶表里面記錄了某個用戶有什么樣的屬性特征，比如年齡、性別等。

在我看來，事件模型有三個優(yōu)點(diǎn)：

1）抽象能力強(qiáng)，能全面、精細(xì)地描述的用戶行為

相比于 PC 時代的頁面模型，事件模型表達(dá)能力更強(qiáng)，能刻畫更多類型的用戶行為；因?yàn)椋瑢τ陧撁婺Ｐ偷穆顸c(diǎn)，在最開始的時候已經(jīng)固定好了采集哪幾種類型的行為，比如頁面瀏覽、按鈕點(diǎn)擊、push點(diǎn)擊等等，不同類型的埋點(diǎn)也確定了其中會采集哪些字段，如果后續(xù)業(yè)務(wù)同學(xué)想在某個埋點(diǎn)中新增個性化的字段是比較麻煩的。

針對添加個性化字段的需求，一種解決方式是，我們在每類埋點(diǎn)中都預(yù)留一個 valvus 字段，以 k-v 的形式來記錄此類埋點(diǎn)下所有個性化的字段，這樣是可以解決問題，但成本比較高：

• 一個字段中存了多個信息，埋點(diǎn)元數(shù)據(jù)的管理成本增加；
• 這樣的字段非常靈活，難以約束業(yè)務(wù)方按照約定上報數(shù)據(jù)，有可能會出現(xiàn)一個 values 字段包含了上千個k-v，數(shù)據(jù)質(zhì)量難以把控；
• 在后期處理數(shù)據(jù)時，需要做額外的解析工作。另外，對于頁面模型，如果后面要再采集一類埋點(diǎn)，需要重新設(shè)計(jì)一類埋點(diǎn)，后面的表、查詢模型都要重新開發(fā)，非常的不靈活。

2）可打通業(yè)務(wù)數(shù)據(jù)和行為數(shù)據(jù)，實(shí)現(xiàn)更精細(xì)的用戶行為分析

要把業(yè)務(wù)數(shù)據(jù)放入頁面模型中是比較困難的，而對于事件模型，只要這個業(yè)務(wù)過程是有用戶參與，就可以把業(yè)務(wù)數(shù)據(jù)表示為誰在什么時間、什么地點(diǎn)、以什么樣的方式、做了一件什么樣的事；隨著用戶行為分析越來精細(xì)，越來越深入業(yè)務(wù)，打通業(yè)務(wù)數(shù)據(jù)和行為數(shù)據(jù)已經(jīng)是一件必要的事了，而事件模型在數(shù)據(jù)采集階段就解決了這個問題。

3）容易理解，埋點(diǎn)設(shè)計(jì)起來相對容易

事件模型把用戶和用戶行為描述為「誰在什么時間，什么地點(diǎn)，以什么樣的方式，做了一件什么樣的事，這個用戶有什么樣的屬性特征」，非常貼近自然語言，在很大程度上降低了模型的理解難度。

鑒于業(yè)界主流已經(jīng)從頁面模型切換到事件模型了，建議在構(gòu)建埋點(diǎn)體系時盡量采用事件模型。后面的埋點(diǎn)設(shè)計(jì)也會以事件模型來說。

二、設(shè)計(jì)埋點(diǎn)

設(shè)計(jì)埋點(diǎn)是按照埋點(diǎn)模型把將業(yè)務(wù)需求翻譯成為開發(fā)能懂的語言。

如果采用事件模型，翻譯過程可以概括為四個步驟：業(yè)務(wù)分析、定義指標(biāo)、事件設(shè)計(jì)、屬性設(shè)計(jì)。

首先，需要梳理業(yè)務(wù)過程，然后針對細(xì)分的業(yè)務(wù)場景定義能夠衡量業(yè)務(wù)目標(biāo)的指標(biāo)，確定埋點(diǎn)的內(nèi)容和范圍；之后就可以按照事件模型設(shè)計(jì)事件，以及事件下的屬性了；比如，來看一個電商搜索的場景來看如何進(jìn)行埋點(diǎn)設(shè)計(jì)。

下面用電商搜索場景為例，說明如何進(jìn)行埋點(diǎn)設(shè)計(jì)：

1. 業(yè)務(wù)分析

梳理業(yè)務(wù)流程，以及每個業(yè)務(wù)流程下的用戶路徑和各種細(xì)分場景。

一般思路是——根據(jù)用戶在產(chǎn)品上具體的操步驟，定義用戶行為路徑；比如在電商搜索的場景中，核心操作步驟是用戶發(fā)起搜索/ 點(diǎn)擊搜索結(jié)果/購買商品，那么就可以把業(yè)務(wù)分解為「輸入關(guān)鍵詞搜索」、「點(diǎn)擊返回搜索結(jié)果」、「購買商品」，在「輸入關(guān)鍵詞搜索」環(huán)節(jié)；可以通過輸入的關(guān)鍵詞，分析用戶對不同商品的需求情況，在「點(diǎn)擊返回搜索結(jié)果」環(huán)節(jié)，可以評估不同關(guān)鍵詞運(yùn)營狀況是否健康；譬如，是否存在沒有搜索結(jié)果返回的關(guān)鍵詞，或者用戶點(diǎn)擊的搜索結(jié)果排在很后面等等。

2. 指標(biāo)拆解

完成業(yè)務(wù)拆解之后，需要結(jié)合業(yè)務(wù)分析目標(biāo)思考，每個細(xì)分的業(yè)務(wù)過程可以有哪些指標(biāo)來分析。

在電商搜索的場景中，常見的分析是視角是：

• 用戶對不同商品的需求情況如何，相關(guān)的指標(biāo)是「不同關(guān)鍵詞的搜索次數(shù)/人數(shù)」；
• 不同關(guān)鍵詞當(dāng)前的健康度如何，相關(guān)的指標(biāo)是「搜索結(jié)果點(diǎn)擊人數(shù)/次數(shù)」、「搜索結(jié)果點(diǎn)擊率」、「不同關(guān)鍵詞返回結(jié)果數(shù)」、「搜索結(jié)果點(diǎn)擊位置均值」等；
• 用戶對商品的需求是否都能得到滿足，相關(guān)的指標(biāo)是「不同關(guān)鍵詞返回結(jié)果數(shù)」、「關(guān)鍵詞返回結(jié)果點(diǎn)擊-成功購買的轉(zhuǎn)化漏斗」，此時，我們就完成了指標(biāo)定義。

3. 事件設(shè)計(jì)

在上面的步驟中，我們定義出了「不同關(guān)鍵詞的搜索次數(shù)/人數(shù)」、「搜索結(jié)果點(diǎn)擊人數(shù)/次數(shù)」、「搜索結(jié)果點(diǎn)擊率」、「不同關(guān)鍵詞返回結(jié)果數(shù)」、「搜索結(jié)果點(diǎn)擊位置均值」、「關(guān)鍵詞返回結(jié)果點(diǎn)擊-成功購買的轉(zhuǎn)化漏斗」等要統(tǒng)計(jì)的指標(biāo)。

事件設(shè)計(jì)，其實(shí)就是把指標(biāo)中設(shè)計(jì)也行為提煉出來；回來電商搜索這個例子中，我們可以提煉出七個用戶行為，分別是：「點(diǎn)擊搜索按鈕」、「返回搜索結(jié)果」、「點(diǎn)擊搜索結(jié)果」、「瀏覽商品詳情頁」、「商品加入購物車」、「確認(rèn)訂單」、「支付訂單」。

在實(shí)際的設(shè)計(jì)中，有一個重要的問題需要考慮：針對某個具體的行為是否需要設(shè)計(jì)單獨(dú)的事件，比如「點(diǎn)擊搜索按鈕」這個行為是否可以用「APP 元素點(diǎn)擊」這個事件采集，還是需要有一個單獨(dú)的「點(diǎn)擊搜索按鈕」事件去采集？

在這個問題上，有兩條經(jīng)驗(yàn)分享：

1）對于重要的點(diǎn)擊事件，建議單獨(dú)設(shè)置事件采集，而不要使用「APP 元素點(diǎn)擊」「Web 元素點(diǎn)擊」等這樣的全埋點(diǎn)事件。

重要的點(diǎn)擊事件往往需要記錄更全面、更精細(xì)的字段，需要根據(jù)具體的點(diǎn)擊事件的類型以及個性化屬性，進(jìn)行歸類采集；常見的點(diǎn)擊事件有 Banner 位點(diǎn)擊、ICON 點(diǎn)擊、頻道 TAB、功能重要操作點(diǎn)擊等事件。

2）有兩個相似的行為，如「信息流廣告點(diǎn)擊」和「Banner 廣告位點(diǎn)擊」這兩個行為，由于要記錄較多豐富的屬性，已確定要設(shè)置單獨(dú)的事件；但這兩個事件采集的字段非常相似，都需要采集廣告 id、廣告名稱、排序、所屬頁面等字段，是按照下面的 a 方案采集，還是 b 方案采集呢？

這里需要回到業(yè)務(wù)，如果在后續(xù)的分析中業(yè)務(wù)需要將信息流廣告和 Banner 廣告匯總起來看總的廣告點(diǎn)擊次數(shù)/人數(shù)；那需要按照 a 方案合并設(shè)計(jì)，如果后續(xù)業(yè)務(wù)上不會合并看數(shù)據(jù)，建議按照 b 方案分開設(shè)計(jì)（其實(shí) a 方案也能滿足分別統(tǒng)計(jì)兩種廣告的需求，不過查詢要麻煩一些）。

另外，在事件設(shè)計(jì)時還需要說明數(shù)據(jù)的采集時機(jī)以及在哪個端采集。

舉個例子，我們設(shè)計(jì)了一個「信息流條目曝光」的埋點(diǎn)事件，如果不對采集時機(jī)加以說明，研發(fā)很有可能在信息流條目只在屏幕上露出 50% 時就采集上報數(shù)據(jù)，而業(yè)務(wù)需要的是信息流條目在屏幕上完全露出時才采集上報；于是，在事件設(shè)計(jì)時需要描述清楚在什么樣的情況下會觸發(fā)事件數(shù)據(jù)的采集。

從事件上報的觸發(fā)邏輯上面來講，可分為前端觸發(fā)上報、前端獲取后端匯總結(jié)果后上報、后端觸發(fā)上報、后端獲取前端屬性后上報四個比較類別，如下圖所示。

以淘寶下單流程中的「購買成功」為例，詳細(xì)介紹下單埋點(diǎn)事件的觸發(fā)邏輯類型。

例：以購買成功為例看事件的觸發(fā)邏輯。

前端觸發(fā)就上報：點(diǎn)擊「立即付款」按鈕就觸發(fā)，這是最常見的前端采集方式，如果業(yè)務(wù)方是想了解「用戶是否有意愿支付」，那么當(dāng)用戶點(diǎn)擊「支付訂單」這個按鈕或者發(fā)出支付請求就采集即可。

前端獲取后端匯總后上報：這種方式一般是由于除了記錄用戶操作外，還需要獲取用戶操作的結(jié)果；比如需要收到后端結(jié)果的返回，以判斷用戶是否支付成功，以及失敗情況下具體的報錯原因，那么其觸發(fā)機(jī)制必須等到前端拿到后端服務(wù)器處理結(jié)果后，再進(jìn)行上報。

后端觸發(fā)就上報：這種方式是指后端處理后直接上報，比如后端處理付款請求出結(jié)果時直接后端觸發(fā)上報；采用這種方式的主要好處是數(shù)據(jù)不會出現(xiàn)漏報，但也由于是后端直接上報，基本是拿不到用戶的設(shè)備終端及軟硬件環(huán)境屬性的，比如用戶在支付時使用的是什么設(shè)備、網(wǎng)絡(luò)環(huán)境是什么等信息。

后端獲取前端屬性且觸發(fā)上報：這種情況就是為了解決后端埋點(diǎn)的軟硬件環(huán)境屬性問題，讓前端在用戶點(diǎn)擊「立即支付」時，將相應(yīng)的屬性一并傳回服務(wù)器，服務(wù)器發(fā)生「支付成功」時，帶上相應(yīng)的前端屬性上報數(shù)據(jù)；當(dāng)然這種方式理論上時數(shù)據(jù)準(zhǔn)確度、完備性最高的，但同時這種方式的采集成本會比較高，意味著所有端的前后端接口需要做變更，建議是只在數(shù)據(jù)準(zhǔn)確性、前端屬性獲取兩個需求都非常強(qiáng)烈時采用。

4. 屬性設(shè)計(jì)

埋點(diǎn)設(shè)計(jì)的最后一步是在每個事件下設(shè)計(jì)包含的屬性，這里的屬性到后續(xù)的數(shù)據(jù)分析中，就是維度和修飾詞，對應(yīng)到 SQL 查詢語句中就是 where 和 group by。

回到電商搜索的例子，要深入分析用戶對不同商品的需求情況、不同關(guān)鍵詞的健康度，需要對比分析不同關(guān)鍵詞的數(shù)據(jù)表現(xiàn)；那么關(guān)于關(guān)鍵詞的維度屬性，例如關(guān)鍵詞內(nèi)容、關(guān)鍵詞分類（推薦詞、熱門詞）等屬性就非常關(guān)鍵。

需要強(qiáng)調(diào)的是——在屬性設(shè)計(jì)時，除了維度全面之外，還必須保證每個屬性都是獨(dú)立采集，比如關(guān)鍵詞分類和關(guān)鍵詞內(nèi)容不能合并為一個字段采集，以保證后續(xù)靈活的下鉆分析；一般可以把屬性分為用戶屬性、事件屬性、對象屬性、環(huán)境屬性，下面列舉出每個分類下常見的屬性，供大家參考。

當(dāng)然，要想把屬性設(shè)計(jì)好，關(guān)鍵是要對業(yè)務(wù)場景和數(shù)據(jù)分析的訴求非常熟悉，知道哪些維度會影響業(yè)務(wù)的數(shù)據(jù)表現(xiàn)。

• 用戶屬性：用戶ID、新老用戶、活躍天數(shù)等
• 事件屬性：前向頁面、功能入口、操作方式等
• 對象屬性：商品名稱、商品分類、商品金額等
• 環(huán)境屬性：設(shè)備型號、平臺、城市、運(yùn)營商等

埋點(diǎn)設(shè)計(jì)完成之后，將會輸出一份 DRD 文檔，文檔中詳細(xì)描述了滿足本次業(yè)務(wù)需求需要采集多少個事件，每個事件下又包含了哪些屬性，每個事件在什么時候觸發(fā)，像下面這樣：

三、數(shù)據(jù)埋點(diǎn)，一次講個夠

這一系列的文章會和大家系統(tǒng)地分享我對埋點(diǎn)體系建設(shè)的實(shí)踐與思考，后續(xù)的文章會進(jìn)一步和大家討論這些問題：

• 如何讓業(yè)務(wù)線的產(chǎn)品/運(yùn)營更高效地提埋點(diǎn)需求？
• 如何更快的響應(yīng)業(yè)務(wù)需求，輸出 DRD？
• 如何設(shè)計(jì)更簡潔、更靈活、拓展性更強(qiáng)的埋點(diǎn)模型？
• 如何協(xié)調(diào)好參與埋點(diǎn)工作的各方，快速產(chǎn)出高質(zhì)量的埋點(diǎn)？
• 如何有效地管理成千上萬個已線上、未上線、需要下線的埋點(diǎn)？

希望可以幫助數(shù)據(jù)產(chǎn)品新手快速上手建設(shè)埋點(diǎn)體系，同時，如果你在企業(yè)里負(fù)責(zé)埋點(diǎn)相關(guān)的工作，也希望這些文章能夠貢獻(xiàn)一些好的思路，幫助你們的埋點(diǎn)體系更上一層樓。

Thea，微信公眾號：Thea的若干好奇；從事大數(shù)據(jù)產(chǎn)品工作六年，設(shè)計(jì)、管理埋點(diǎn)已有三年，經(jīng)手過上萬個埋點(diǎn)，經(jīng)歷過從 0 到 1 自建埋點(diǎn)體系，也使用過第三方的埋點(diǎn)服務(wù)。

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

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