聊聊我們在業務鏈路升級中做的資料洞察

2025-05-04 09:10 阿里技術

一  概述

關於資料相關的詞條很多，雖然有不同的定義，但是本質上是相輔相成，通常結合使用才能拿到結果。
類比詞條諸如 資料分析，資料探勘， 資料洞察。
以下為wiki上的定義
  • 資料分析：是一種統計學常用方法，其主要特點是多維性和描述性。有些幾何方法有助於揭示不同的資料之間存在的關係，並繪製出統計資訊圖，以更簡潔的解釋這些資料中包含的主要資訊；
  • 資料探勘：是一個跨學科的計算機科學分支。它是用人工智慧、機器學習、統計學和資料庫的交叉方法在相對較大型的資料集中發現模式的計算過程；
  • 資料洞察：這一專案前沒有wiki詞條，基於普遍認知，是基於資料分析和資料探勘，結合業務場景後，圍繞業務鏈路定義統一口徑，進而更好的分析問題，並且能夠進一步做策略改進。
三者分析手段本質上都是對資料進行加工獲取資訊，但是目標不盡相同，以下是我個人的理解。
  • 資料分析更側重，基於人的理解動線，結合人對業務和資料的理解，產出分析結果。這裡更加強調人的分析；
  • 資料探勘同理資料分析，只不過角色從人變為了機器；
  • 資料洞察是在資料分析和挖掘的基礎上，引入了業務場景的概念，梳理出圍繞業務場景結果的影響因素和鏈路，目標是對抽象問題進行歸因、拆分以及更好更快的形成改進方向。這個也是我們業務開發同學最有優勢的地方。

二  核心要素

我們發現，資料洞察的理解，實際上是可以分為幾個核心要素。
這裡我們逐一來簡要說明。

1  資料

乾淨有效的資料才是我們要的資料，否則會誤導後續的結論。e.g. 登入鏈路因為是業務安全水位保證的第一環節，經常有來刷的流量，如何避免因為灰黑產的流量，影響後續的判斷，這個也是重中之重；

2  業務場景

業務場景是區分資料洞察和其他資料分析方式的核心區別，也可能是業務同學區分bi分析的最大的價值點。任何分析策略都脫離不開對業務場景的理解，而不是單純的理解資料。
定義“一次完整業務鏈路行為”是核心，圍繞著一次行為鏈路，才能就鏈路分析有用的策略。

3  口徑

口徑是什麼？我理解口徑是在合理的資料維度和好的目標的基礎上對業務場景的理解，口徑上也會結合對業務場景的理解和對業務目標的理解。資料維度可能是多種多種的。
還是以登入舉例，正常的理解，一個使用者在一個裝置上登入是正常情況，但是手淘會出現多賬號登入同裝置，這個也是常態資料特徵，那究竟在定義登入成功率的時候，是使用裝置維度（認為同一個裝置只要有一個使用者登入成功即算裝置成功）還是使用使用者維度（只看使用者維度資料，不結合裝置定義指標），也是需要考量的。

三  資料建設

1  資料的清洗是保證資料有效的手段

我們獲得的各種打點框架和不同的資料來源，可能維度和資訊量都是不統一的，比如有的資料來源有裝置資訊但是沒有使用者資訊，有的資料來源有使用者資訊，但是裝置資訊不完整；甚至同一個時間欄位，格式也是不統一的。
這個時候就需要先對資料進行加工了，剔除髒資料，補充遺漏點位，加工出乾淨的單維度資訊，並且保證各資料來源資料加工出的資料維度和格式統一，比如標準的裝置id或者使用者id及時間等。

2  資料建設是補充也是演進

資料質量問題，不止要從資料的清晰看，也資料產生的點來看。如果資料有缺失或者不統一，資料清洗又搞不定，就需要進行開發了，比如資料庫增加欄位，打點框架增加打點邏輯。
資料建設是一個長期的過程，不止是為了補充現在要分析的內容，也是要形成一套標準的交付產物。更進一步，日常做需求和專案的時候，打點資料質量也是要考慮的，畢竟做需求上線不是結果，拿到業務目標才是結果。

四  業務場景

1  業務場景的定義

業務場景是在整個業務洞察中最特殊的一個環節。這個環節定義的好壞，直接影響了問題拆分結果的有效性。
不同的業務場景具備各自的特殊性，需要結合業務特性來分析。
按照目前我的經驗來看，業務場景的定義也是有一些核心方法的。
  • 業務場景中，最終產物是誰？
還是以登入舉例，登入的最終目標肯定是為了下發登入態，否則也沒有人回來“玩一玩”登入，那圍繞下發登入態的鏈路，就是我們想要的業務鏈路；
其他的業務也同理，比如訂單的話，是圍繞庫存來跑；
  • 業務場景中，你需要分析的維度是多深；
這個也比較好理解，以上述例子繼續說，要看登入的業務鏈路的話，需要拆分多種登入方式不同的鏈路來看？還是說看一個總的登入鏈路就夠了。
這個維度就只能看分析問題的層次了，一般在洞察初期，當然是維度越細越好，但是越分析往後，維度會逐漸上升，因為隨著對業務的洞察，會發現有些維度雖然深了更完整，但是是分析不出問題的，也就是“過度分析”了。
  • 業務場景中，你要定義“一次完整業務行為”。
資料洞察區分於其他分析方式，最大的優勢是在於結合了業務來分析業務本身，那直擊業務結果的，一定是完整的業務鏈路。
這個點不舉例不太好說明，舉個例子，登入過程。
大家有想過打點會是什麼樣麼，和一次完整業務行為會有啥差異麼。
正常打點是下面這種樣子的。
rpcId
loginType
result
time
deviceId
traceid1
password
NEED_IV_CHECK
2021-12-1 11:20:54
123
traceid2
mloginToken
SUCCESS
2021-12-1 11:21:20
123
表1
這兩條離散的打點就是一次完整登入行為，但是是基於rpc請求維度的表達。

2  結合業務場景定義的資料結構演進

打點資料描述了一個階段性的結果。上面例子描述的，就是使用者在2021-12-1 11:20:54發起了一次賬密登入請求，但是因為環境不安全，安全挑戰要求核實身份（比如發簡訊核實），使用者操作了核身操作，在2021-12-1 11:21:20發起了免登，下發了登入態。
這個就是一次登入行為。業務洞察的核心也是圍繞這個點進行。
假如我們的分析維度，是總的登入維度或者分登入方式的登入維度分析，這個兩條資料的打點其實就不適合我們，我們僅需要登入方式，最終結果，時間以及裝置id就夠了。
rpcId
loginType
final_result
time
deviceId
traceid1
password
SUCCESS
2021-12-1 11:21:20
123
表2
或核身沒有透過
rpcId
loginType
final_result
time
deviceId
traceid1
password
NEED_IV_CHECK
2021-12-1 11:21:20
123
表3
但是我們也會發現，這個資料描述的行為並不完整，比如表2並不能描述登入過程經過了核身這個特性。
這個時候，我們就需要資料結構進行下一個階段的演進。
我們引入了statustag來描述路徑。
statustag格式：0^0^12|0^1^abcde.
前後經過|分割為兩種格式，第一個格式為bitmap，表示0版本；第二個格式為字串，表示1版本格式，字串為經過的未加到bitmap的節點（埋點畢竟不是強要求，總有需求上線後，沒有加bitmap）。
這個tag描述經過的路徑為，經過bx1100結果，經過了一版本的4和8的節點，和二版本的abcde節點。
有了這個tag，就可以描述更多的資訊。

3  業務場景資料的視覺化表達

單純的資料並不容易洞察，也不是長期運營治理的合理方式。這個時候我們就需要視覺化來搞事情。
視覺化的內容包含我們想要表達的內容，比如漏斗，比如曲線。
目前視覺化表達常見的是漏斗和報表。
  • 漏斗舉例
圖1
做漏斗很麻煩，需要一個點一個點手動定義。但是漏斗對初期理解鏈路，分析問題益處非常大。
這個時候我們需要的，是可以透過結構化的資料來源，來快速生成視覺化漏斗。
我們可以透過生成資料的時候就指定約定來快速生成結構化資料。
  • 基於狀態機+約定打點
1. 引入狀態機變化記錄打點日誌；
2. 結合結構化的畫圖能力，定向輸出約定日誌，動態畫圖
  • 狀態機的核心要素
1.statusTag記錄路徑資訊；
2.status和old_status記錄節點上下游資訊；
3.depth記錄節點深度；
最終產出的一次登入行為登入資料

五  口徑

口徑是基於資料和業務場景的產出結果。口徑也是最重要的點，口徑代表了我們基於資料和業務場景對業務結果的理解，比如登入的口徑，在財年初定義，登入成功率從9x%提升到9y%，這個提升空間，也是根據資料來計算的。

1  口徑不要經常變動

口徑一旦定義下來，就不要經常變動。因為一般定義口徑是最難也是最耗時的，定義口徑的時候，一般我們已經完成了對目標的拆解，機會的洞察和最終的測算。

2  口徑並不一定是單一口徑

除了上述特性外，口徑也會有單口徑和多口徑，一般都會同時存在，比如登入過程，在一個總的口徑基礎上，哪怕是一次登入行為，我們也會拆分多個業務階段。
還是以登入舉例，我們把使用者從進入頁面開始，到發起登入行為，定義為意願口徑，從登入行為開始到登入結果，定義為成功率口徑。這兩塊要解決的問題是不同的，揉到一起，會導致問題變得複雜，不利於分析。
多口徑也有一個好處，我們可以做階段性的工作，在不同的階段，處理多口徑中其中一部分的鏈路升級。

3  口徑維度定義

口徑維度定義需要結合場和業務的特性，哪怕是同一個業務鏈路，可能在不同場中，不同人群定義，也是不同的。
這塊不好說明，舉個例子。
我們C埠徑定義上，是裝置維度，因為C端使用者，天然存在薅羊毛行為，我們會認為一個裝置的登入成功，對於C端就是有益處的。
但是同樣是登入鏈路，B端定義上，就是使用者維度的，因為B端商家的個體價值都很大，而且不太存在類似C端薅羊毛的行為，使用者維度能讓我們更好的看到使用者行為，以便做體驗上的最佳化。

六  小結

在資料洞察方面，我們也還在學習和實踐的路上，並在這條路上已經取到了一定的結果，但是未來空間還是很大。這條路對於業務開發是一個有優勢的路，而且業務平臺作為業務場景的豐富度上，也是獨具優勢，我們可以在資料洞察做的事情上，更加自由。歡迎大家來一起討論，也歡迎大家來一起探索。
資料洞察是業務中臺賦能業務的有力工具，對業務產出資料洞察能力，也是我們一個非常大的命題。
商業跑得快，業務中臺可信賴。

彈性計算基礎知識

彈性計算是把計算力變成普惠的公共資源，讓不同體量的使用者任何時候都能用親民的價格享受到高可用、高效能、高效率的基礎IT計算服務，所以可以說彈性是雲計算的核心能力。本課程對彈性的重要性、彈性的定義、阿里雲如何做彈性等。點選閱讀原文檢視詳情。

相關文章