從用戶(hù)行為到數(shù)據(jù):數(shù)據(jù)采集全景解析

1 評(píng)論 12730 瀏覽 77 收藏 47 分鐘

本文為讀者系統(tǒng)講解了數(shù)據(jù)采集的核心原理、埋點(diǎn)技術(shù)、工具、組織建設(shè)等方面知識(shí)。文章探究了采集的整個(gè)過(guò)程,包括后端交互采集方式、用戶(hù)行為采集方式(即埋點(diǎn)技術(shù)),以及數(shù)據(jù)采集中的工具、團(tuán)隊(duì)組織建設(shè)等多方面內(nèi)容,通過(guò)閱讀本篇文章,希望你對(duì)數(shù)據(jù)采集有更清晰的認(rèn)知和了解。

數(shù)據(jù)采集是數(shù)據(jù)體系建設(shè)的最上游,是非常重要的一個(gè)環(huán)節(jié),除了專(zhuān)業(yè)的數(shù)據(jù)人員,人們普遍對(duì)數(shù)據(jù)采集的認(rèn)知度不高。

如果你提起埋點(diǎn),應(yīng)該很多人都熟悉它。它應(yīng)該也是絕大部分人對(duì)數(shù)據(jù)采集的認(rèn)知了。數(shù)據(jù)上報(bào)其實(shí)是一個(gè)系統(tǒng)性工程,它涉及了工具、團(tuán)隊(duì)、團(tuán)隊(duì)協(xié)同、標(biāo)準(zhǔn)、流程等多方面的內(nèi)容,其中任何一個(gè)部分出現(xiàn)問(wèn)題都有可能讓上報(bào)過(guò)程變得復(fù)雜,下游數(shù)據(jù)出現(xiàn)問(wèn)題的概率增高。

本文系統(tǒng)的講解了數(shù)據(jù)采集的核心原理是什么,以及工具、組織改如何建設(shè),希望能讓你對(duì)數(shù)據(jù)采集有一個(gè)清晰的認(rèn)知和了解。

一、數(shù)據(jù)采集的整個(gè)過(guò)程

我最早接觸的數(shù)據(jù)采集是從業(yè)務(wù)的數(shù)據(jù)庫(kù)中COPY各種表到數(shù)據(jù)倉(cāng)庫(kù)中,就是從一個(gè)庫(kù)中的一些表以各種形式拷貝到另一個(gè)庫(kù)中再以各種形式存儲(chǔ)下來(lái)的過(guò)程。這是一個(gè)后端交互的采集方式。

后來(lái)逐步了解到,原來(lái)還可以去采集用戶(hù)的行為,名詞叫埋點(diǎn)。采集用戶(hù)的行為主要目的是為了以數(shù)據(jù)的視角觀(guān)察用戶(hù)是怎么在你的產(chǎn)品里“活動(dòng)”的,為了幫助設(shè)計(jì)者了解設(shè)計(jì)的缺陷,優(yōu)化交互設(shè)計(jì),提高產(chǎn)品的體驗(yàn)。

數(shù)據(jù)采集中埋點(diǎn)的概念絕大多人都有聽(tīng)說(shuō),但基本上是停留在聽(tīng)說(shuō)階段。知道要埋點(diǎn),反正埋點(diǎn)了就能有數(shù)據(jù),然后就可以分析了。這么理解沒(méi)問(wèn)題,對(duì)于使用者本身,就足夠了。

直到真正開(kāi)始做數(shù)據(jù)采集這個(gè)工作時(shí),慢慢了解到數(shù)據(jù)采集是個(gè)比較復(fù)雜的事情,它涉及眾多角色,涉及繁長(zhǎng)的流程,和建設(shè)指標(biāo)一樣,是個(gè)既簡(jiǎn)單而又復(fù)雜的的工程。

二、從行為到指標(biāo),數(shù)據(jù)是怎么來(lái)的

1. 用戶(hù)行為動(dòng)作的抽象過(guò)程

應(yīng)用程序的出現(xiàn)是為了滿(mǎn)足用戶(hù)的各種需要。例如網(wǎng)上購(gòu)物、看視頻、玩游戲、社交等場(chǎng)景,所有的場(chǎng)景活動(dòng)都會(huì)有用戶(hù)在應(yīng)用上的各種行為操作。

下圖是京東移動(dòng)端的首頁(yè),京東的核心場(chǎng)景是購(gòu)物,用戶(hù)在應(yīng)用上瀏覽商品,挑選,購(gòu)買(mǎi)。用戶(hù)在京東上的所有的操作行為都可以歸類(lèi)為“動(dòng)作”。

用戶(hù)和應(yīng)用程序的交互,不像現(xiàn)實(shí)生活中的“動(dòng)作”那么豐富,例如走路、開(kāi)門(mén)、跑、跳,這些實(shí)際的物理動(dòng)作在應(yīng)用程序范圍內(nèi)是不會(huì)發(fā)生的。人在應(yīng)用程序的動(dòng)作會(huì)受限于使用載體本身(手機(jī)、電腦、電視..)的人機(jī)交互,如早期的手機(jī)用按鍵,控制電視需要用遙控器,psxbox等游戲機(jī)用手柄等。

人機(jī)交互動(dòng)作更多是像登錄、瀏覽、點(diǎn)擊等動(dòng)作,用戶(hù)在應(yīng)用程序的操作,就是這些實(shí)際的物理操作,不會(huì)囊括太多現(xiàn)實(shí)中的其他物理動(dòng)作。

例如“扔手機(jī)”這個(gè)動(dòng)作,沒(méi)有和手機(jī)發(fā)生實(shí)際的交互,只是在現(xiàn)實(shí)中進(jìn)行了物理的動(dòng)作,該動(dòng)作就不會(huì)讓手機(jī)本身“知道”并記錄下來(lái)。

2. 從動(dòng)作到日志的交互過(guò)程

既然動(dòng)作被限定在人機(jī)交互這個(gè)范圍內(nèi),記錄用戶(hù)行為就有規(guī)律可循。識(shí)別用戶(hù)的動(dòng)作,并把它記錄下來(lái)是數(shù)據(jù)采集的核心目標(biāo)?,F(xiàn)在以京東商城購(gòu)物為例,看看從動(dòng)作發(fā)生到數(shù)據(jù)記錄的過(guò)程是什么。

下圖是京東商城手機(jī)端的首頁(yè),我們現(xiàn)在準(zhǔn)備記錄我的兩個(gè)2個(gè)動(dòng)作:

  1. 我瀏覽了該頁(yè)面。
  2. 我點(diǎn)擊了家電家具的按鈕。

我的兩個(gè)動(dòng)作是瀏覽和點(diǎn)擊,但動(dòng)作的實(shí)際發(fā)生是要作用于具體的實(shí)體對(duì)象的,也就是“我對(duì)誰(shuí)做了什么”:我點(diǎn)擊了哪個(gè)實(shí)體,我瀏覽了哪個(gè)實(shí)體。

通常來(lái)說(shuō),用戶(hù)在應(yīng)用上的動(dòng)作(誰(shuí)對(duì)什么做了哪些動(dòng)作),統(tǒng)一歸納理解為“事件”,可以理解為,發(fā)生了一件什么事。

事件的基本要素可以用這四點(diǎn)來(lái)描述:一個(gè)用戶(hù)在某個(gè)時(shí)間點(diǎn)、某個(gè)地方,對(duì)誰(shuí)做了什么什么動(dòng)作。

總結(jié)歸納一個(gè)事件需要包括的四個(gè)要素:誰(shuí)、什么時(shí)間、對(duì)誰(shuí)、做了什么動(dòng)作

定義了“事件”,應(yīng)用程序就需要在動(dòng)作實(shí)際發(fā)生時(shí),把這個(gè)事件以數(shù)據(jù)形式記錄下來(lái)。

在技術(shù)上,通常以記錄日志的形式表現(xiàn)出來(lái)。也就是說(shuō),當(dāng)我“點(diǎn)擊”了京東家電家居的按鈕時(shí),應(yīng)用會(huì)把我這個(gè)動(dòng)作存儲(chǔ)成一條數(shù)據(jù):

$user_id:用戶(hù):勍爺(誰(shuí))
$event_time:時(shí)間:5:30:30(在什么時(shí)間)
$event_postion:”位置:jd_home_detail(對(duì)誰(shuí),頁(yè)面)
$event_content內(nèi)容:eid_jd_home_app(對(duì)誰(shuí),按鈕元素)
$event_action:動(dòng)作:click(做了點(diǎn)擊動(dòng)作)

日志一般用JOSN的格式來(lái)表示:

{ "user_id": "勍爺”,
"event_time": "5:30:30”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_home_app”,
"event_action": "click”,
}

如果我繼續(xù)在京東首頁(yè)上分別點(diǎn)擊“京東電器”、“京東到家”、“京東超市”三個(gè)按鈕,則會(huì)產(chǎn)生三條日志記錄:

京東電器:

{ "user_id": "勍爺”,
"event_time": "5:30:31”,
"event_postion": "jd_home_detail”,
"event_content": "eid_jd_app”,
"event_action": "click", }

京東到家:

{ "user_id": "勍爺”,
"event_time": "5:30:32”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_tohome”,
"event_action": "click", }

京東超市:

{ "user_id": "勍爺”,
"event_time": "5:30:33”,
"event_postion": "jd_home_detail”,
"event_content": “eid_jd_market”,
"event_action": "click", }

上面三條記錄中變化的只有envet_content(對(duì)誰(shuí)做),同一個(gè)動(dòng)作(點(diǎn)擊),記錄了4條不同的記錄。

3. 更多的描述——參數(shù)的引入

事件的基本要素描述了事件的主體,他們構(gòu)成了一個(gè)完整的事件。但是僅僅只記錄事件的基本四要素信息,如上面日志記錄里的內(nèi)容,是不夠我們用于業(yè)務(wù)分析的。

例如用戶(hù)勍爺,是注冊(cè)用戶(hù),他用的什么設(shè)備登錄?IP地址是什么?在什么地理位置?用的什么網(wǎng)絡(luò)?點(diǎn)擊的按鈕?跳轉(zhuǎn)地址是什么?

再如,首頁(yè)中的搜索框,“搜索”事件,用戶(hù)輸入了什么關(guān)鍵詞、搜索類(lèi)型?是否觸發(fā)聯(lián)想詞、輸入詞為空的搜索?

分析需求多種多樣,需要記錄的數(shù)據(jù)內(nèi)容就會(huì)變的更多。要想記錄更多的數(shù)據(jù),可以對(duì)事件的四要素進(jìn)行擴(kuò)展。

如下圖:

我們可以增加對(duì)該事件基本要素更多的屬性描述,例如對(duì)用戶(hù)進(jìn)行描述擴(kuò)展,對(duì)動(dòng)作、實(shí)體對(duì)象進(jìn)行更豐富的描述,這些描述統(tǒng)一為擴(kuò)展參數(shù)。擴(kuò)展參數(shù)的記錄,應(yīng)該根據(jù)實(shí)際的需求來(lái)進(jìn)行合理的設(shè)計(jì),從指標(biāo)和維度的實(shí)際使用情況來(lái)倒推所需要的參數(shù)是什么。

例如,根據(jù)上面的例子,如果想了解在北京用IOS端點(diǎn)擊“首頁(yè)家電家居”按鈕的用戶(hù)數(shù)是多少,我們需要在事件中加入?yún)?shù):

$event_ip:IP地址
$event_client:客戶(hù)端

然后再加入一些用戶(hù)的屬性,性別、年齡、身高、體重4個(gè)參數(shù),則日志會(huì)變成這樣:

{ 
"user_id": "勍爺”,
"gender":“男”,
"height":“184”,
"weight":“165”,
"age":“18”,
event_ip“:“114.206.233.55”,
"event_client":“IOS”,
"event_time": "5:30:31”,
"event_postion": "jd_home_detail”,
"event_content": "eid_jd_app",
"event_action": "click",
}

對(duì)于參數(shù),可以基于事件的四要素做歸納:

【用戶(hù)類(lèi)】【頁(yè)面元素類(lèi)】【動(dòng)作類(lèi)】,每個(gè)類(lèi)別都可以做擴(kuò)展。

4. 公有參數(shù)、私有參數(shù)、日志長(zhǎng)度

1)公有參數(shù)

隨著加入?yún)?shù)的增多,日志也需要一定的統(tǒng)一性。

例如想用戶(hù)的基本屬性,設(shè)備號(hào)、用戶(hù)名、注冊(cè)時(shí)間、會(huì)員屬性、性別、年齡等,對(duì)于任何事件來(lái)說(shuō),都是需要包含對(duì)應(yīng)的用戶(hù)參數(shù)的。幾乎絕大多數(shù)統(tǒng)計(jì),都需要用戶(hù)的基本屬性。如今天有多少會(huì)員登錄、有多少新用戶(hù)、有多少年齡18歲的女性用戶(hù)等等。它具有普遍性,幾乎每條日志都會(huì)帶有這些參數(shù)。

這類(lèi)參數(shù)視會(huì)被視為公共參數(shù),他是在一定范圍內(nèi),不論你定義什么事件、不論你分析什么,都會(huì)進(jìn)行采集的。

2)私有參數(shù)

私有參數(shù)的范圍更小,依賴(lài)業(yè)務(wù)自身的特定需求。例如直播這個(gè)業(yè)務(wù)輔助電商進(jìn)行銷(xiāo)售,那直播會(huì)有自己的私有業(yè)務(wù)屬性;例如彈幕、打賞等動(dòng)作,從事件本身就單獨(dú)獨(dú)立于電商整個(gè)體系,它有自己的私有業(yè)務(wù)規(guī)則,所以在直播這個(gè)領(lǐng)域內(nèi),它會(huì)有自己特定的參數(shù)。

這時(shí)候,采集的日志表現(xiàn),只會(huì)在直播這個(gè)業(yè)務(wù)范圍內(nèi),才會(huì)存在這些參數(shù)。

3)日志長(zhǎng)度

如果從日志的視角來(lái)看,把每一條日志都格式化后,每一個(gè)參數(shù)對(duì)一定一個(gè)字段,它們的長(zhǎng)度是不一樣的。

我們假設(shè)有兩個(gè)事件:

【直播進(jìn)房事件】、【商品詳情播放事件】來(lái)看一看他們的格式化后的長(zhǎng)度:

兩個(gè)事件所產(chǎn)生的日志長(zhǎng)度是不同的,因?yàn)椴杉膮?shù)(字段)不相同。這兩條日志結(jié)構(gòu)中,都有三個(gè)類(lèi)型,其中關(guān)于用戶(hù)屬性的參數(shù),是完全一致的,我們認(rèn)定它們是公共參數(shù)。

房間、SKU、主播ID、商品視頻這些具有獨(dú)特的業(yè)務(wù)含義,并不會(huì)再其他領(lǐng)域內(nèi)出現(xiàn),故描述它們的屬性就屬于私有參數(shù)。

用一張圖來(lái)描述Event模型:

5. 日志的格式設(shè)計(jì):定常、擴(kuò)展與嵌套

因?yàn)槿罩鹃L(zhǎng)度不同,在使用以及后續(xù)的處理上就會(huì)帶來(lái)不便,想想看,你的EXCEL中有1萬(wàn)條不同長(zhǎng)度的數(shù)據(jù)是個(gè)多么恐怖的事情。

但是最重要的是,對(duì)于傳輸和解析(把日志結(jié)構(gòu)化)就變的異常困難了。每條日志都不一樣長(zhǎng),每個(gè)日志都具有獨(dú)特的私有參數(shù),批量解析需要規(guī)則,對(duì)某一字段是保留還是解析成結(jié)構(gòu)化需要設(shè)定一個(gè)統(tǒng)一個(gè)規(guī)則。

從成本的角度來(lái)講,如果每一條日志都需要合理的解析成結(jié)構(gòu)化的數(shù)據(jù),那么消耗的計(jì)算資源也會(huì)大很多。從傳輸、解析、理解、擴(kuò)展和后期維護(hù)的角度來(lái)看,日志的格式需要有特定的規(guī)則,而不是雜亂無(wú)章的。

所以,根據(jù)上述的內(nèi)容,日志的格式設(shè)計(jì)需要滿(mǎn)足以下幾點(diǎn):

  1. 日志的字段長(zhǎng)度要一樣,便于維護(hù)。
  2. 為了滿(mǎn)足需求的靈活性,日志需要有擴(kuò)展性。
  3. 擴(kuò)展性字段需要統(tǒng)一定義,方便下游用戶(hù)解析。
  4. 運(yùn)用嵌套滿(mǎn)足擴(kuò)展性所以日志保持定長(zhǎng)、并有共識(shí)的幾個(gè)字段,通過(guò)嵌套來(lái)滿(mǎn)足業(yè)務(wù)的靈活多變添加更多的參數(shù)。

定長(zhǎng)設(shè)計(jì)多少個(gè)字段、不是拍腦袋決定的,需要根據(jù)業(yè)務(wù)長(zhǎng)期以來(lái)的分析需求通過(guò)抽象來(lái)判斷的。

例如設(shè)備號(hào)、IP地址、通信波段等最常用的,然后留有一定的擴(kuò)展位,擴(kuò)展位留幾個(gè),取決于設(shè)計(jì)者的技術(shù)方案與成本、運(yùn)維、解析便利性以及容錯(cuò)性來(lái)綜合判斷。

如上圖,假設(shè)統(tǒng)一定長(zhǎng)的日志是10個(gè)字段,其中7個(gè)字段是最常用,這7個(gè)字段是全局公參,是所有需求都需要的字段。

剩下留有3個(gè)擴(kuò)展位,每個(gè)擴(kuò)展字段下的內(nèi)容還可以再擴(kuò)展,留有足夠的擴(kuò)展空間。在這些擴(kuò)展位中,可以寫(xiě)入業(yè)務(wù)的私有參數(shù),也有可能是局部的業(yè)務(wù)、用戶(hù)的公有參數(shù)。但它不是全局性的(公司級(jí))如何擴(kuò)展、把哪類(lèi)擴(kuò)展內(nèi)容固定在具體的擴(kuò)展字段上,需要與多方達(dá)成協(xié)定,便于后續(xù)的解析工作。后續(xù)解析成結(jié)構(gòu)化,由使用方自行決定。

格式的設(shè)計(jì)沒(méi)有對(duì)錯(cuò)之說(shuō),核心目標(biāo)是要保障穩(wěn)定利于傳輸、具有擴(kuò)展性、可讀性好、容錯(cuò)率高、傳播協(xié)定便于解析的特性。至于是20個(gè)定長(zhǎng)字段,還是10個(gè),外層有一個(gè)擴(kuò)展字段還是多個(gè),需根據(jù)公司的實(shí)際發(fā)展需要來(lái)決定。

6. 一個(gè)完整行為的記錄

看一個(gè)實(shí)際的例子,如上圖,我的行為路徑分成了6步:

  1. 啟動(dòng)京東商城應(yīng)用。
  2. 進(jìn)入首頁(yè),再點(diǎn)擊家電家居按鈕。
  3. 進(jìn)入家電家居頁(yè)面,再點(diǎn)擊家電館按鈕。
  4. 進(jìn)入家電館頁(yè)面,點(diǎn)擊美的空調(diào)廣告頁(yè)。
  5. 進(jìn)入美的空調(diào)詳情頁(yè)。
  6. 點(diǎn)擊商品視頻,播放視頻。

用戶(hù)的動(dòng)作可以分成這幾步,我們對(duì)動(dòng)作進(jìn)行同類(lèi)合并,這幾步中,一共有4類(lèi)動(dòng)作:登錄、瀏覽、點(diǎn)擊、播放。

然后是實(shí)體位置,一共有多少的頁(yè)面和按鈕參與了這些動(dòng)作,用表格來(lái)描述:

瀏覽的動(dòng)作理解起來(lái)比較特殊,頁(yè)面暴露在手機(jī)上,就等同于這個(gè)頁(yè)面讓用戶(hù)看到了。所以一般都把瀏覽動(dòng)作定義為曝光動(dòng)作。

曝光是一個(gè)用戶(hù)被動(dòng)觸發(fā)的動(dòng)作,它是高頻出現(xiàn)的。只要頁(yè)面或者頁(yè)面上的各種內(nèi)容出現(xiàn)在(在手機(jī)上暴露)用戶(hù)面前,都會(huì)觸發(fā)曝光動(dòng)作。如果用戶(hù)只是上下瀏覽滑動(dòng),沒(méi)有點(diǎn)擊具體按鈕,那么用戶(hù)的動(dòng)作就只有曝光。

通過(guò)表格的統(tǒng)計(jì),一共包括了4個(gè)頁(yè)面,4個(gè)按鈕,4個(gè)動(dòng)作。其中每一行都可以理解為一個(gè)獨(dú)立的事件,每個(gè)事件在觸發(fā)后,都會(huì)生成一條日志,這一套動(dòng)作下來(lái),一共產(chǎn)生了14條日志。

此時(shí)如果我退出了應(yīng)用,系統(tǒng)在記錄一條我退出的動(dòng)作,我這個(gè)自然人在應(yīng)用上留痕的記錄就是15條。

假設(shè)該應(yīng)用有1萬(wàn)個(gè)用戶(hù)都做了上面的動(dòng)作,則將會(huì)產(chǎn)生15萬(wàn)條日志記錄。這些日志都會(huì)以定長(zhǎng)的方式發(fā)送到接收服務(wù)器中,最后加工成表。

千萬(wàn)的用戶(hù)會(huì)產(chǎn)生千萬(wàn)的行為軌跡,我們把應(yīng)用的頁(yè)面、元素與動(dòng)作組合成一個(gè)個(gè)事件,每個(gè)用戶(hù)的軌跡就上述的表格一樣一條一條被記錄下來(lái)。

7. 捕捉、傳輸、SDK與管道

前面講述了從動(dòng)作到日志的過(guò)程,但實(shí)際上它是如何具體實(shí)現(xiàn)的呢?

它總的邏輯類(lèi)似于石油的開(kāi)采過(guò)程:

1)客戶(hù)端上的采集

手機(jī)、pc、tv等終端上的各類(lèi)應(yīng)用,都會(huì)設(shè)有固定的采集器,如果想采集每一個(gè)用戶(hù)的行為數(shù)據(jù),那必須在每一個(gè)用戶(hù)的應(yīng)用上,安裝采集器。采集器的核心作用有兩個(gè):采集和上報(bào)。

  • 采集行為日志,把用戶(hù)的動(dòng)作記錄成日志。
  • 把日志傳送給管道,把日志傳輸?shù)教崆霸O(shè)定好的服務(wù)器中。

采集器需要具備小巧精干的特性。一般采集器都是主程序的附屬功能,它不能占用程序的太多資源、不能因?yàn)椴杉挠脩?hù)大量的電量、流量資源,同時(shí)還不能干擾主程序的正常運(yùn)行,不能為此帶來(lái)風(fēng)險(xiǎn)。

2)管道

用戶(hù)日志產(chǎn)生了,日志怎么樣傳輸給服務(wù)器?

需要假設(shè)傳輸管道。類(lèi)似于手機(jī)上插一根usb線(xiàn),另一端插在電腦上。采集器和管道之間存在一個(gè)協(xié)議,采集的日志以什么樣的格式傳輸,一次傳輸多少,傳輸?shù)侥睦锶?,都需要管道?lái)承擔(dān)。如同這個(gè)usb是幾代,線(xiàn)有多粗一樣。

一般管道的設(shè)計(jì)需要考慮幾點(diǎn):

  1. 傳輸容量(帶寬)。
  2. 傳輸開(kāi)關(guān)(類(lèi)似于水管開(kāi)關(guān))。
  3. 分流器(主管道分流到分支管道)。
  4. 解析器(改變數(shù)據(jù)格式)。
  5. 容災(zāi)機(jī)制(確保管道暢通無(wú)阻,抗宕機(jī)數(shù)據(jù)丟失風(fēng)險(xiǎn))。

其中開(kāi)關(guān)、分流、容災(zāi)的設(shè)計(jì)是非常重要的。開(kāi)關(guān)類(lèi)似于水管水龍頭,能夠確保隨時(shí)關(guān)上水龍頭,因?yàn)槌刈涌赡苡袧M(mǎn)的時(shí)候。

分流的意思是不希望水都從一個(gè)管道過(guò)來(lái),這里要考慮的問(wèn)題有:如果水被污染了怎么辦?另一個(gè)是場(chǎng)景是有的業(yè)務(wù)不想用水了,可以自行關(guān)閉,而不是一直開(kāi)著讓水溢出。所以需要提供獨(dú)立自主的控制能力。

解析能力在數(shù)據(jù)采集中是必要的一步。因?yàn)閿?shù)據(jù)上報(bào)上來(lái)的格式不便于直接使用和理解。需要將其解析成格式化數(shù)據(jù)。

例如JSON格式:

{

"name": "John",
"age": “30”,
"city": "New York",
"pets":
[
{"name": "Fluffy",
"type": "cat"},
{"name": "Rover",
"type": "dog"}
]
}

這樣的數(shù)據(jù)不易被理解,不易被SQL直接使用。由于SQL語(yǔ)言具備群眾基礎(chǔ),或者說(shuō)所有數(shù)據(jù)工作者都會(huì)SQL,最理想的方式還是進(jìn)入到數(shù)據(jù)庫(kù)中用SQL語(yǔ)言來(lái)處理。

所以把不同結(jié)構(gòu)的數(shù)據(jù)解析成結(jié)構(gòu)化(表的形式)的能力是數(shù)據(jù)進(jìn)入到數(shù)據(jù)庫(kù)中的必要工作。大多數(shù)時(shí)候,用戶(hù)根據(jù)自己的實(shí)際需要進(jìn)行解析,解析的工作主要由數(shù)據(jù)倉(cāng)庫(kù)工程師來(lái)完成。

解析能力放在管道中是一個(gè)爭(zhēng)議較多的話(huà)題,通常管道不涉及解析能力。如果有,也是單獨(dú)的模塊,它與管道解耦。類(lèi)似于在水龍頭出口加裝一個(gè)凈水器的作用。

之所以不建議設(shè)計(jì)解析能力的原因是管道是一個(gè)傳送單位,它不對(duì)傳送的內(nèi)容做過(guò)多的干預(yù),只是確保傳送的內(nèi)容能夠傳送到制定的地方。如果增加解析能力,則會(huì)對(duì)管道本身增加一個(gè)數(shù)據(jù)質(zhì)量保障的責(zé)任,如果沒(méi)有足夠的服務(wù)能力,就不能保障服務(wù)是可靠的。

三、全埋點(diǎn)與代碼埋點(diǎn)

全埋點(diǎn)與代碼埋點(diǎn)是個(gè)技術(shù)的開(kāi)發(fā)方式,但這個(gè)開(kāi)發(fā)方式影響著很多人對(duì)埋點(diǎn)、數(shù)據(jù)采集的認(rèn)知。除了在數(shù)據(jù)專(zhuān)業(yè)領(lǐng)域的人,很多人對(duì)埋點(diǎn)的認(rèn)知是非全面的,非系統(tǒng)性的。這也無(wú)可厚非,畢竟不同角色只會(huì)專(zhuān)精自己的領(lǐng)域,對(duì)于非本職工作,能夠協(xié)同完成即可,不會(huì)過(guò)多的探究?jī)?nèi)在原理。

所以經(jīng)常有人會(huì)提問(wèn),做全埋點(diǎn)、無(wú)埋點(diǎn)、自動(dòng)化埋點(diǎn)不是更好嗎?希望能夠減少數(shù)據(jù)采集的工作中的工作量。

1. 識(shí)別、抽象、統(tǒng)一設(shè)定

首先,上面講述的事件,日志,這些都不會(huì)憑空出現(xiàn)。采集日志的過(guò)程一定是程序來(lái)實(shí)現(xiàn)的,它運(yùn)轉(zhuǎn)在電腦、手機(jī)上。

所以你要記錄的用戶(hù)的行為一定是有開(kāi)發(fā)代碼的過(guò)程的,例如一個(gè)簡(jiǎn)單的按鈕點(diǎn)擊事件代碼(ChatGPT幫我寫(xiě)的):

document.getElementById("button-id").addEventListener("click", function() {

//記錄按鈕點(diǎn)擊事件
trackEvent("button-clicked", {
buttonId: "button-id",
buttonLabel: "按鈕標(biāo)簽",
userId: "用戶(hù)ID",
timestamp: new Date().getTime()
});
});

其中,trackEvent是一個(gè)自定義的函數(shù),用于記錄事件和數(shù)據(jù)。button-id是需要跟蹤的按鈕的ID,buttonLabel是按鈕的標(biāo)簽或文本,userId是用戶(hù)的ID,timestamp是事件發(fā)生的時(shí)間戳。

要記錄用戶(hù)在某一個(gè)元素上的點(diǎn)擊、曝光等事件,該前端工程師需要按照已經(jīng)設(shè)計(jì)好的埋點(diǎn)方案寫(xiě)一定量的代碼程序,才能夠完成這個(gè)功能的開(kāi)發(fā)。

但往往開(kāi)發(fā)者發(fā)現(xiàn),大部分的需求都是同質(zhì)化的,例如是80%的需求都是曝光、點(diǎn)擊這類(lèi)事件,導(dǎo)致工程師開(kāi)發(fā)過(guò)程中增加的只是重復(fù)勞動(dòng)的工作量

故有很多人想對(duì)此抽象合并:能不能不用寫(xiě)開(kāi)發(fā)代碼,寫(xiě)一次,或者安裝個(gè)什么插件,統(tǒng)一埋點(diǎn),以增加效率減少維護(hù)成本;或者是可視化的方式,在產(chǎn)品上點(diǎn)點(diǎn)功能,就把開(kāi)發(fā)工作完成了呢?

如果想采集用戶(hù)的行為信息,還無(wú)需開(kāi)發(fā),新的產(chǎn)品迭代,也不用理會(huì),新功能都可以自動(dòng)埋點(diǎn)。這種訴求如果通過(guò)技術(shù)方式來(lái)實(shí)現(xiàn)的一個(gè)前提就是要足夠的抽象。必須清晰的定義一個(gè)讓機(jī)器理解的邊界,然后統(tǒng)一按照一個(gè)模式來(lái)完成工作。

類(lèi)似于工廠(chǎng)生產(chǎn)一個(gè)產(chǎn)品,有多少道工序,定義好流程。所有操作需按照這個(gè)工序來(lái),只需要在工序的第一步添加原材料,最后一步收獲產(chǎn)品就可以了。

從埋點(diǎn)的角度來(lái)看,基于event模型,定義事件的要素來(lái)看,【誰(shuí)】、【什么時(shí)間】、【對(duì)誰(shuí)】、【做了什么動(dòng)作】其中【誰(shuí)】、【什么時(shí)間】、【動(dòng)作】是需要由用戶(hù)觸發(fā)的。【對(duì)誰(shuí)(頁(yè)面、元素等)】是產(chǎn)品端上固定設(shè)計(jì)好的。

根據(jù)我們定義event過(guò)程來(lái)看,我們會(huì)預(yù)先定義用戶(hù)的【動(dòng)作】,例如瀏覽(曝光)、點(diǎn)擊這些動(dòng)作。如果所有的要素都變的已知,自動(dòng)埋點(diǎn)就可以實(shí)現(xiàn)。

基于此,我們假設(shè)全埋點(diǎn)可能需要做到這么幾件事:

  1. 需要識(shí)別出位置和實(shí)體(頁(yè)面、元素),且能夠做到更新識(shí)別(產(chǎn)品端的更新,增加頁(yè)面、元素能夠識(shí)別的到)。
  2. 對(duì)實(shí)體能夠定義統(tǒng)一的evnet(事件)。
  3. 采集能力與上報(bào)能力。

其中,1 2 兩點(diǎn),是做到自動(dòng)埋點(diǎn)的關(guān)鍵動(dòng)作。這樣,“用戶(hù)行為采集”這件事,真的就可以交給機(jī)器自動(dòng)來(lái)完成了。

2. 應(yīng)對(duì)復(fù)雜與變化略顯無(wú)力

全埋點(diǎn)從效率上來(lái)看非常好,但它不能解決所有問(wèn)題。絕大多數(shù)業(yè)務(wù)是多變與復(fù)雜的。隨著業(yè)務(wù)發(fā)展的深入和產(chǎn)品對(duì)體驗(yàn)、增長(zhǎng)的需求增加,研究用戶(hù)行為的特定訴求變得更多,變得更多樣化。

例如,看基本的訪(fǎng)問(wèn)量、點(diǎn)擊量只是初始需求,還需要看訪(fǎng)問(wèn)時(shí)長(zhǎng)、用戶(hù)軌跡等。當(dāng)然如果某一類(lèi)分析變得固定下來(lái),不論業(yè)務(wù)如何發(fā)展,該類(lèi)分析訴求都必要需要的話(huà),同樣是可以加入到統(tǒng)一定義event的動(dòng)作中去的。

但是需要數(shù)據(jù)采集的用戶(hù)群體往往不單單是業(yè)務(wù)、產(chǎn)品、還可能包括技術(shù)、財(cái)務(wù)、行政等業(yè)務(wù)的訴求,例如以下幾種:

  1. 業(yè)務(wù)想了解哪些用戶(hù)點(diǎn)擊了XX元素之后直接下單的。
  2. 技術(shù)想知道哪個(gè)頁(yè)面加載的速度大于800ms,哪些頁(yè)面加載后閃退了。
  3. 同一個(gè)大業(yè)務(wù)下,運(yùn)營(yíng)和產(chǎn)品兩個(gè)部門(mén)對(duì)于直播進(jìn)房事件的定義不同。
  4. 分析師想了解視頻自動(dòng)播放對(duì)于DAU的影響是什么。

前后端關(guān)聯(lián)、不同業(yè)務(wù)部門(mén)的不同訴求、分析師的原因探究、實(shí)驗(yàn)、技術(shù)對(duì)性能的追求,這些都是復(fù)雜、特定、多變的場(chǎng)景,與自動(dòng)化處理采集的過(guò)程,天生和抽象、統(tǒng)一就是對(duì)頭。

所以,全埋點(diǎn)是個(gè)理想的方案,但它不適用于復(fù)雜的業(yè)務(wù)形態(tài)。

另外,從成本的角度看,如果產(chǎn)品內(nèi)所有的頁(yè)面元素都規(guī)劃了evnet,那上報(bào)的數(shù)據(jù)量會(huì)非常恐怖。例如有1億DAU的應(yīng)用,收集的日志量會(huì)有幾百億條/天(保守估算),但這些數(shù)據(jù)還僅僅只能看最基本的PVUV,那我們的報(bào)表成本未免也太貴了。

但是,全埋點(diǎn)非常適用于用戶(hù)量級(jí)?。?0萬(wàn)級(jí)),業(yè)務(wù)、產(chǎn)品交互邏輯不復(fù)雜的產(chǎn)品。例如公司的內(nèi)部網(wǎng)站、論壇、行政、報(bào)銷(xiāo)、分析、ERP系統(tǒng),或者一些TOB的系統(tǒng)。并且對(duì)于數(shù)據(jù)的分析訴求不是那么的深,就是想了解DAU,或者DAU是自己的核心OKR等團(tuán)隊(duì)。

同時(shí)這類(lèi)產(chǎn)品團(tuán)隊(duì)也不會(huì)投入太多的精力去做數(shù)據(jù)采集的事情,也不會(huì)把采集的數(shù)據(jù)合理入倉(cāng)。他們只是想看一看基本的數(shù)據(jù),至少在產(chǎn)品0-1,以及1-100的相當(dāng)長(zhǎng)的一段時(shí)間內(nèi),都不會(huì)有太復(fù)雜的變化。

B端的用戶(hù)群體少,尤其是服務(wù)公司內(nèi)部的,性能、穩(wěn)定性、產(chǎn)品交互,都不會(huì)像C端一樣要求甚高,出現(xiàn)問(wèn)題,至少可以司內(nèi)線(xiàn)下溝通解決,容錯(cuò)率和寬容度是有的。所以對(duì)于技術(shù)、體驗(yàn)、交互方面的復(fù)雜采集需求是非常少的。

另外,內(nèi)部工具基本以提高效率為核心目的,大多數(shù)沒(méi)有業(yè)績(jī)、收入等增長(zhǎng)的訴求,也不會(huì)想方設(shè)法的去找如何提高業(yè)績(jī)、增長(zhǎng)的方法。

代碼埋點(diǎn)和全埋點(diǎn)對(duì)比:

四、工具要怎么做

工具的建設(shè)范圍包括SDK+管道+采集的管理能力,其中SDK、管道的能力被管理門(mén)戶(hù)所管理。SDK、管道是采集的必備能力,它相當(dāng)于采集石油的磕頭機(jī)和運(yùn)輸管道。

管理門(mén)戶(hù)的作用主要是控制SDK、管道的能力。所以,理論上來(lái)講,沒(méi)有管理門(mén)戶(hù),石油也是能夠被采集上來(lái)的。

關(guān)于采集的工具設(shè)計(jì),需要結(jié)合上面說(shuō)到的核心原理與采集方式。首先是全埋點(diǎn)的方式,識(shí)別、統(tǒng)一定義、這些能力集成在全埋點(diǎn)的SDK中。SDK要具備采集和上報(bào)的能力,采集和上報(bào)可根據(jù)規(guī)則進(jìn)行調(diào)整,用于適配各種不同的管道。

如果管道和SDK聯(lián)合設(shè)計(jì),就可以結(jié)合組織、技術(shù)、業(yè)務(wù)體量來(lái)設(shè)計(jì)格式、協(xié)議等,這里更多是技術(shù)方案的對(duì)接,就不過(guò)多贅述。

我想重點(diǎn)闡述一下,在核心能力之外的衍生能力建設(shè),這部分能力更多集中在管理能力上。

1. 使用場(chǎng)景與工具的演進(jìn)

采集的工具建設(shè)不是一下子變出來(lái)的,它也是結(jié)合實(shí)際的需求在不同階段有不同的產(chǎn)物。我們可以結(jié)合業(yè)務(wù)的逐步發(fā)展,來(lái)推演工具到底如何建設(shè)。

我們的演進(jìn)路線(xiàn)圖如下:

2. 一個(gè)人的采集

業(yè)務(wù)發(fā)展初期,幾乎很少在一開(kāi)始就考慮如何采集數(shù)據(jù)的。一是沒(méi)有團(tuán)隊(duì)上沒(méi)有專(zhuān)業(yè)領(lǐng)域的人來(lái)設(shè)計(jì),二是團(tuán)隊(duì)更聚焦業(yè)務(wù)與市場(chǎng),精力不夠,三是不會(huì)投入太多的成本在采集數(shù)據(jù)上。

初期的業(yè)務(wù)產(chǎn)品需要快速試錯(cuò),敏捷迭代,所以全套的采集方案和快速迭代的產(chǎn)品節(jié)奏是對(duì)不齊的。絕大多數(shù)情況都是在產(chǎn)品快要上線(xiàn)的兩到三周前才會(huì)思考要看什么數(shù)據(jù)來(lái)監(jiān)測(cè)產(chǎn)品的情況。

并且數(shù)據(jù)分析訴求也非常簡(jiǎn)單,幾乎一個(gè)dau就囊括了所有需要。所以團(tuán)隊(duì)不會(huì)在數(shù)據(jù)采集投入太多的資源,更無(wú)需專(zhuān)業(yè)人員來(lái)做。這個(gè)時(shí)期,幾乎所有的采集任務(wù)都由研發(fā)來(lái)包辦了。

產(chǎn)品、業(yè)務(wù)、運(yùn)營(yíng)的全部精力投入在自身職責(zé)范圍內(nèi)的工作,幾乎很少提出相對(duì)專(zhuān)業(yè)性的分析體系和思路。研發(fā)絕大多數(shù)情況按照自己的理解進(jìn)行采集,同時(shí)還需要對(duì)接數(shù)據(jù)管道、數(shù)據(jù)處理、看板報(bào)表等工作。

假設(shè)公司沒(méi)有健全的數(shù)據(jù)工具體系。這個(gè)時(shí)候的研發(fā)要承接采集上報(bào)+管道+數(shù)據(jù)落地處理加工的角色,研發(fā)可能受制于工作進(jìn)度緊等壓力,部分?jǐn)?shù)據(jù)統(tǒng)計(jì)訴求直接讀取業(yè)務(wù)數(shù)據(jù)庫(kù),基本上怎么簡(jiǎn)單怎么來(lái)。

因?yàn)榧幢闶钦业揭恍┘傻膕dk工具,也需要搭建管道,后續(xù)的etl處理等數(shù)據(jù)專(zhuān)業(yè)工作。對(duì)于業(yè)務(wù)研發(fā)來(lái)講,已經(jīng)跨越職能領(lǐng)域了。有的時(shí)候會(huì)直接去買(mǎi)第三方工具,簡(jiǎn)單的部署環(huán)境后,就可以完成需求,簡(jiǎn)單迅速還有服務(wù)保障。

3. 協(xié)同與質(zhì)量

隨著業(yè)務(wù)的發(fā)展進(jìn)入成熟期,業(yè)務(wù)對(duì)數(shù)據(jù)的訴求越來(lái)越多,越來(lái)越深入,數(shù)據(jù)采集的工作變得復(fù)雜和沉重。這個(gè)時(shí)期用青黃不接來(lái)形容最合適不過(guò)。

數(shù)據(jù)量上來(lái)了,需求多了,采集任務(wù)更復(fù)雜了;客戶(hù)端的研發(fā)在采集上消耗的精力越來(lái)越多,并且不單單是做新增任務(wù),維護(hù)和問(wèn)題排查也會(huì)占用精力,甚至很多時(shí)候已經(jīng)超過(guò)了正常的業(yè)務(wù)功能開(kāi)發(fā)。

這個(gè)時(shí)期,出現(xiàn)了采集協(xié)同。開(kāi)始對(duì)需求進(jìn)行把控,需求的規(guī)范性和合理性開(kāi)始被重視起來(lái),開(kāi)始從需求源頭控制,減少不合理需求、重復(fù)需求、增加需求流程

另一個(gè)主要現(xiàn)象就是數(shù)據(jù)質(zhì)量問(wèn)題開(kāi)始頻繁出現(xiàn),如數(shù)據(jù)不準(zhǔn),不及時(shí),或者某些問(wèn)題導(dǎo)致采集失效等。

問(wèn)題頻發(fā)核心問(wèn)題主要有:

  1. 采集方案的不合理導(dǎo)致的數(shù)據(jù)問(wèn)題。
  2. 缺少相應(yīng)的質(zhì)量保證流程機(jī)制、缺少測(cè)試環(huán)節(jié)。
  3. 組織上缺少專(zhuān)業(yè)的人員來(lái)負(fù)責(zé)整體的采集工作。
  4. 缺少采集標(biāo)準(zhǔn)與規(guī)范。

這個(gè)時(shí)期的采集需求場(chǎng)景通常是,需求者提交一份excel需求單,描述了自己的需求,研發(fā)基于需求單進(jìn)行開(kāi)發(fā),上線(xiàn)后不出問(wèn)題就算結(jié)束。工具在這個(gè)時(shí)期開(kāi)始體現(xiàn)重要性了,它需要具備流程、機(jī)制、規(guī)則的約束性、并具有采集管理能力。

與很多產(chǎn)品不同,采集工具并不能幫我們主動(dòng)寫(xiě)代碼,自行采集(全埋點(diǎn)方式例外)。采集代碼還是需要依靠研發(fā)來(lái)完成,所以工具的能力更注重采集的管理和質(zhì)量能力,他們對(duì)工具的訴求主要是:

  • 我都采集了哪些內(nèi)容?
  • 需要有對(duì)采集內(nèi)容的增刪改查能力
  • 每天數(shù)據(jù)采集的成本是多少?
  • 我采集的數(shù)據(jù)是否按照我的要求采集?是否有采集?
  • 如果出現(xiàn)問(wèn)題時(shí),是不是可以提前告訴我?
  • 如果已經(jīng)出現(xiàn)下游應(yīng)用問(wèn)題,能不能快速排查到問(wèn)題點(diǎn)?
  • 能否在上線(xiàn)前有聯(lián)調(diào)測(cè)試能力?

下圖描述了采集工具需要滿(mǎn)足的上述能力建設(shè)領(lǐng)域:

工具的建設(shè)不是一成不變的,隨著需要的增加和變化逐步調(diào)整目標(biāo)和適配性。數(shù)據(jù)采集的工具主旋律以質(zhì)量為主,效率在采集的層面上是其次需求,它并非是個(gè)主要或必要的需求。

大多數(shù)采集是跟隨客戶(hù)端發(fā)版的迭代速率更新的,在效率層面上的核心用戶(hù)群體是客戶(hù)端研發(fā)和測(cè)試。研發(fā)效率的提升不在于對(duì)新增采集需求寫(xiě)代碼的效率,而是出現(xiàn)問(wèn)題如何快速定位的能力。

所以從效率的角度上來(lái)講,質(zhì)量工具體系建設(shè)的越好,對(duì)研發(fā)的效率提升越明顯。

測(cè)試場(chǎng)景是質(zhì)量的一個(gè)前置環(huán)節(jié),能否測(cè)試充分、提供較為全面的測(cè)試能力非常重要。在業(yè)務(wù)成熟階段,很多部門(mén)配有測(cè)試,測(cè)試業(yè)務(wù)功能的同時(shí)連帶著測(cè)試數(shù)據(jù)埋點(diǎn)。測(cè)試過(guò)程是工具提效能力的一個(gè)重要場(chǎng)景。寫(xiě)測(cè)試用例、測(cè)試過(guò)程相對(duì)耗時(shí)。

經(jīng)常出現(xiàn)的情況是,測(cè)試功能的時(shí)間都很緊迫,埋點(diǎn)測(cè)試的時(shí)間就會(huì)被擠占,甚至是不測(cè)。這樣就會(huì)對(duì)后面的質(zhì)量埋下隱患。

所以,工具的建設(shè)核心是:

  • 盡可能的提高數(shù)據(jù)采集質(zhì)量的把控能力,包括上線(xiàn)前的測(cè)試、合規(guī)性檢查,上線(xiàn)后的監(jiān)控、診斷能力,在提高質(zhì)量的同時(shí),能夠間接幫助研發(fā)、下游提效。
  • 提效不是重心,可以重點(diǎn)幫助測(cè)試高效的測(cè)試充分分擔(dān)測(cè)試壓力。
  • 成本控制最好在采集之初提前設(shè)計(jì),提供全套能力。
  • 具備管道的開(kāi)關(guān)能力,保證數(shù)據(jù)流的控制,防火防災(zāi)。
  • 能夠方便查詢(xún)采集內(nèi)容的元數(shù)據(jù)查詢(xún)能力。
  • evnet的增刪改能力。

五、組織與流程

組織與流程是數(shù)據(jù)采集中最容易出現(xiàn)問(wèn)題也最容易影響效果的環(huán)節(jié)。業(yè)務(wù)是不斷發(fā)展變化的,產(chǎn)品工具也是不斷迭代的,組織也是如此。

組織最好能夠和工具有比較好的配合,或者說(shuō)工具能夠更好的契合組織的運(yùn)轉(zhuǎn)達(dá)到1+1>2的效果。前面說(shuō)過(guò),一個(gè)研發(fā)就可以完成數(shù)據(jù)采集的工作,所以什么樣的組織都可以運(yùn)轉(zhuǎn),就看組織是否高效、專(zhuān)業(yè),能夠發(fā)揮出組織的設(shè)定優(yōu)勢(shì)。

如果依舊拿業(yè)務(wù)的發(fā)展視角去看組織的變化與發(fā)展,先去看在這個(gè)過(guò)程中,有哪些角色參與到實(shí)際的采集工作中。

依舊用這張圖來(lái)看:

隨著業(yè)務(wù)的發(fā)展,數(shù)據(jù)采集工作必然會(huì)從研發(fā)獨(dú)立一個(gè)角色負(fù)責(zé)到專(zhuān)業(yè)團(tuán)隊(duì)負(fù)責(zé)的轉(zhuǎn)變。

但這個(gè)變化不是提前設(shè)計(jì)好的,它是結(jié)合需要來(lái)變的,需要主要來(lái)自于:

  • 解決因?yàn)樾枨髞?lái)自不同部門(mén)或同一部門(mén)的不同角色導(dǎo)致的需求重疊、不合理需求的問(wèn)題。
  • 解決測(cè)試不充分,驗(yàn)收把關(guān)的問(wèn)題。
  • 解決釋放研發(fā)精力的問(wèn)題(排查問(wèn)題等占用的額外精力)。
  • 解決數(shù)據(jù)采集統(tǒng)籌到數(shù)倉(cāng)的問(wèn)題。
  • 解決成本控制問(wèn)題。
  • 增加采集質(zhì)量把控的能力。

在很長(zhǎng)一段時(shí)間內(nèi),公司的埋點(diǎn)方式都是由產(chǎn)品提出需求,研發(fā)來(lái)完成埋點(diǎn),在工具上進(jìn)行管理的方式。

這么做的好處是,產(chǎn)品迭代的過(guò)程中,就可以把采集埋點(diǎn)完成。但主要問(wèn)題是缺少統(tǒng)籌,對(duì)需求的合理性沒(méi)有判斷。需求較為零散,不成整體性。

因?yàn)橥芷趦?nèi),沒(méi)有太多的時(shí)間去思考清楚數(shù)據(jù)分析的需求,但又必須趕在迭代上線(xiàn)前,要完成一些數(shù)據(jù)的采集。

所以,采集的合理性和有效性往往偏低,更取決于提出需求人的思考與設(shè)計(jì)的能力,使得需求的質(zhì)量必然變的參差不齊

也許很多數(shù)據(jù)采集從采集那一刻起就從來(lái)沒(méi)有用過(guò)。所以對(duì)業(yè)務(wù)產(chǎn)品+研發(fā)+工具的形式,必然會(huì)造成需求冗余、研發(fā)精力被過(guò)多占用、測(cè)試不充分、數(shù)據(jù)采集有效性和利用率不高的情況發(fā)生

現(xiàn)在有很多公司會(huì)把埋點(diǎn)工作統(tǒng)一到一個(gè)部門(mén),通過(guò)bp的方式來(lái)做,這樣做減輕了業(yè)務(wù)部門(mén)的負(fù)擔(dān),但對(duì)業(yè)務(wù)需求提出的標(biāo)準(zhǔn)提高了不少。另外還有專(zhuān)職的測(cè)試人員加入進(jìn)來(lái)保障測(cè)試質(zhì)量。

集中管理的好處是:

  1. 對(duì)需求的統(tǒng)籌管理,減少不合理、冗余需求。
  2. 標(biāo)準(zhǔn)較方便統(tǒng)一落地執(zhí)行。
  3. 可以做專(zhuān)業(yè)度較高的事情,例如治理、運(yùn)維等工作。
  4. 不斷提高工具的能力。
  5. 集中做數(shù)據(jù)治理、統(tǒng)一行動(dòng)的項(xiàng)目變的可行。

但這種組織形式也有一些問(wèn)題,比如團(tuán)隊(duì)的成長(zhǎng)性?xún)r(jià)值、投入回報(bào)、與業(yè)務(wù)的合作關(guān)系挑戰(zhàn)(例如強(qiáng)勢(shì)的業(yè)務(wù)提出冗余需求無(wú)法拒絕)流程過(guò)長(zhǎng)等。

以上是兩種主流的組織形態(tài):

  1. PM+研發(fā)自提需求自行消化,借助工具進(jìn)行管理。
  2. 專(zhuān)職人員負(fù)責(zé)采集,借助工具進(jìn)行管理。

我認(rèn)為,隨著工具與技術(shù)的進(jìn)步,未來(lái)的形態(tài)可能是這樣的:由業(yè)務(wù)輸入需求,系統(tǒng)半自動(dòng)化完成部分工作,由少量的專(zhuān)業(yè)人員進(jìn)行監(jiān)督的模式。

拉齊需求水平,降低研發(fā)成本,提高采集的數(shù)據(jù)利用率,減少基礎(chǔ)物理成本,提高數(shù)據(jù)采集服務(wù)是未來(lái)的組織建設(shè)方向。

六、寫(xiě)在最后

數(shù)據(jù)采集是每個(gè)公司都必然會(huì)做的事情。不同的發(fā)展時(shí)期有不同的投入和組織建設(shè),往往公司不會(huì)在一開(kāi)始就會(huì)對(duì)此做頂層設(shè)計(jì),包括工具、技術(shù)、組織,都是隨著業(yè)務(wù)的發(fā)展,對(duì)數(shù)據(jù)的訴求變大或變復(fù)雜逐步調(diào)整的。所以每個(gè)階段的演變都會(huì)留下些許歷史痕跡。

在流程中參與的角色,叫疼的人會(huì)改變工具和組織的形態(tài),流程和組織都在逐步的變化。但變化都是往成熟、高效的方向去變,變化的過(guò)程中也會(huì)冒出很多創(chuàng)新或者失敗。

數(shù)據(jù)采集是數(shù)據(jù)體系建設(shè)的最源頭,它的干凈與否決定著數(shù)據(jù)的信賴(lài)程度。很多時(shí)候我們輕視它,是因?yàn)樗?jiǎn)單;很多時(shí)候它很復(fù)雜很頭疼,是因?yàn)樗鼌⑴c的角色太多,下游鏈條太長(zhǎng),增加了溝通協(xié)作成本;有一種現(xiàn)象是,我檢查了沒(méi)有問(wèn)題,但它就是有問(wèn)題。

隨著ChatGPT的出現(xiàn),輸入需求進(jìn)行AI埋點(diǎn)、自動(dòng)化測(cè)試、采集數(shù)據(jù)將變得可能。半自動(dòng)化監(jiān)督的方式可能是未來(lái)采集的方向。

人工智能減少角色的參與,人來(lái)把控需求,效率和質(zhì)量交給AI。把采集這個(gè)看起來(lái)簡(jiǎn)單的事情,變得真正簡(jiǎn)單。

作者:勍爺小箴,微信公眾賬號(hào):數(shù)據(jù)產(chǎn)品設(shè)計(jì) datadesign

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

題圖來(lái)自Unsplash,基于CC0協(xié)議

該文觀(guān)點(diǎn)僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)。

更多精彩內(nèi)容,請(qǐng)關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號(hào)或下載App
評(píng)論
評(píng)論請(qǐng)登錄
  1. 軟件還沒(méi)上線(xiàn),老板就想做中臺(tái),數(shù)倉(cāng),BI這些了,我一個(gè)小小產(chǎn)品經(jīng)理,實(shí)在設(shè)計(jì)不出來(lái)整個(gè)系統(tǒng)。頭大啊。

    來(lái)自浙江 回復(fù)