標籤:

架構師手記 17 如何設計一個實時大數據分析系統(二)

4. 關於用戶行為數據採集

要做用戶行為數據分析,第一件事就是先要拿到用戶行為數據。

如果你認為用戶行為數據只包含行為數據,你就太天真了。

這裡所說的「用戶行為數據」要比「行為數據」多得多,包含:

  • 用戶信息,比如姓名、年齡、職業、是否婚配、是否有車、信用是否良好等等

  • 賬戶信息,比如遊戲賬戶名稱、賬戶裡面的餘額、賬戶等級、賬戶持有的遊戲道具等等

  • 用戶行為信息,比如下訂單買買買、關注某個明星、加某人為好友等等

  • 物的信息,比如各種遊戲道具、各種商品、各種理財產品等等

有了這些數據,分析些什麼東西呢?

企業分析用戶行為數據,是為了了解用戶的愛好,預測用戶的意圖,從而促進自身業務增長,比如調整自己的產品功能使得用戶更加喜愛、根據用戶的偏好推薦對應的商品、預測一下明年啥東西能夠大賣等等。

舉個例子。

某款應用的產品經理髮現自從發布了新版本之後,新用戶的註冊數量在下降,他想尋找原因。用戶的註冊流程分成兩步,第一步是填寫基本信息,第二步是驗證所填的手機。他通過分析後台的用戶訪問日誌發現,很多用戶在第二步就離開了,沒有繼續進行。這說明用戶不喜歡這一步。這位產品經理調整了註冊流程,去掉了第二步。一個星期後,註冊用戶數量大幅度上升。

多麼美好的故事!反正哥剛入門的時候,被這個故事感動了!

雖然我的敘述風格像講一個童話,但分析用戶如何使用產品是一件十分嚴肅的事情。在現實生活中,這件嚴肅的事情比上面的例子要複雜很多很多。就像我剛看到這個故事的時候,驚喜加詫異:「這麼屌這麼容易!」但後續的實踐證明我的想法太天真。

用戶行為分析是一門十分複雜的科學。

還有一大波企業分析用戶行為數據是為了廣告變現,比如很多免費的新聞資訊類應用。

再舉個例子。

用戶在一個資訊類的應用裡面收藏了一篇養育嬰兒的文字,又查看了二手車的信息。

就是這麼一個簡單的例子裡面,我們可以推測出這個用戶家裡面可能有嬰兒,而且近期內可能有購車的意圖,進而可以推測出來這個用戶是男性的概率比較大,年齡層次約為25~35歲,進而可以推測出來該用戶可能會有嬰兒用品的購買需求,可能有一筆購車資金或者可能會有貸款的意圖。

以上都是推測,但這些推測已經很有價值。

這個應用在此用戶下次訪問的時候,可以展示幾個嬰兒尿布的廣告,或者展示幾個二手車網站的廣告,或者展示幾個貸款的廣告。一旦用戶點擊了這些廣告,廣告主就要付錢給該應用的開發者,作為廣告費。

賺錢是不是很容易?

說實話,現實並沒有這麼理想。很多情況都推測不準,就比如下圖是昨天哥的朋友圈裡面的廣告,很明顯,它投錯人了,哥最近並沒有裝修的意圖。

【試圖上傳此圖10次,都失敗了】

但是,互聯網的廣告業就是這麼掙錢的。

「我就是喜歡你拿我沒辦法還必須送錢給我的日子!」

廣告是用戶行為數據分析變現的一個途徑。

想要分析用戶行為數據,首先的一個問題就是需要能夠識別用戶,否則分析是無法進行的。我們需要有一個唯一Id來區分不同的用戶,比如用戶的身份證號、社保號都可以唯一代表用戶的身份。

BUT,需要注意的是,這裡有一個用戶隱私問題,使得MixPanel或TalkingData等公司不能用身份證、社保號來作為唯一用戶標識。

採集用戶行為數據時,不能泄露用戶隱私。那麼,哪些數據是屬於隱私?哪些不屬於呢?

在這麼多年的道德和輿論的批判下,業界有了一個比較清晰的邊界——PII(Personally identifiable information)。PII信息是不能採集的。

下面是wikipedia上對於PII的解釋。

Personally identifiable information (PII), orsensitive personal information (SPI), as used in US privacy law and informationsecurity, is information that can be used on its own or with other informationto identify, contact, or locate a single person, or to identify an individual incontext.

原則上來說,凡是可以用於識別某個特定人的信息都屬於PII,比如姓名、身份證號、手機號、社保號、各種社交賬號、郵箱等,還有生物識別數據,比如指紋、DNA、虹膜,還有你的臉,記得某寶的刷臉登錄嗎?

企業想要採集這些PII,則需要得到用戶的同意,同時會保證這些信息會用於提升用戶服務,不會把這些信息用於其它方面。你是不是想到了各種「用戶協議」界面?哥問你,你上次仔細看用戶協議是幾十年前了?

而在目前行業公認非PII信息有:IMEI、MAC、IFA、IFV、Android Id、COOKIE等等。

對於MixPanel和TalkingData這樣的企業,在用戶隱私的保護方面更加註意,它們都聲明不會採集PII信息。

但是想要分析用戶的行為,還是必須要能夠定位到某個用戶的,如果連誰做了什麼事情都不知道,是無法對這個人的愛好、意圖進行分析的。

MixPanel和TalkingData提供自己定義的演算法來生成唯一的用戶Id。MixPanel使用distinct_id作為用戶Id,TalkingData使用tdid作為用戶Id。

無論distinct_id還是tdid,都是一串無意義的無法定位到個人的字元串。

下面是distinct_id的生成演算法:

  • 當用戶通過Web Brower訪問應用時,MixPanel會生成一個cookie存放distinct_id,這個id是一個隨機的、長度為50~60的HASH,比如:13bbf7943e584-0885c2531-5c793977-3e8000-13bbf7943e64cf

  • 如果是IOS用戶,MixPanel會先判斷它的設備是否用了AdSupport.framework,如果是,它就是用IFA作為distinct_id;如果沒有,則使用IFV

  • 如果是Android用戶,MixPanel創建一個UUID作為distinct_id

TalkingData的tdid也是類似的演算法。

我們可以看到,MixPanel和TalkingData是無法定位到具體的人,它們只能根據distinct_id或tdid定位到某台特定的手機設備或者某個特定的瀏覽器。它們並不知道這個使用手機或瀏覽器的人是誰。

從本質來說,MixPanel和TalkingData是定位到手機或瀏覽器。

上圖是TalkingData的系統界面,注意紅色圈出的指標。

【試圖上傳此圖5次,都失敗了】

這裡的新增用戶和活躍用戶都是指手機設備。

定位到設備而不是定位到人,雖然規避了隱私問題,但是帶來了新的問題:

  • 多個用戶使用同一個手機(或瀏覽器),這些用戶會有相同distinct_id或tdid,這會造成不同人的用戶行為被認成是一個人的用戶行為

  • 一個用戶使用多個手機(或瀏覽器),這個用戶會有多個不同的distinct_id或tdid,這會造成一個人的用戶行為被認成多個人的用戶行為

如何解決上述問題呢?哥可以很牛逼地告訴你們,目前世界上有兩種解決方案。

第一種是靠演算法,原理是不同的人的行為特徵是不同的,比如有人喜歡看汽車的網頁、有人喜歡購物、有人喜歡問約不約,通過演算法可以區分出來這些不同的行為特徵,這樣可以解決多個用戶使用同一個手機的問題;同理,一個人的行為特徵是有特點的,即時使用不同手機(瀏覽器),他的行為數據都會體現相同的行為特徵,通過演算法,可以發現某些手機(瀏覽器)的行為特徵是相同的,故可以判斷是同一個人在使用他們。

在業界,確實有好幾家公司是使用演算法來解決上述問題的。我曾經看過他們的PPT,寫得那個夢幻啊,演算法真牛逼啊。其實呢,十分不靠譜。經過我的親身驗證和對行業的觀察,演算法的準確率是相當低的。

Google的演算法能力牛逼吧,連它都不靠演算法來解決這個問題。Google App Analytics產品靠的是第二種解決方案。

第二種解決方案是要求租戶的開發人員在程序裡面主動標識用戶賬戶,用於識別賬戶。

MixPanel提供下面的API來標識當前的用戶賬戶。identify介面的輸入值就是用戶賬戶。

mixpanel.identify("13487");

你可能會想,剛才說不能收集用戶PII,這裡不就在收集嗎?

為了避免真實的用戶賬戶信息流出,一般MixPanel和TalkingData都建議開發人員不要把真實的用戶賬戶填入到idetify介面中,而把真實賬戶映射成唯一的數字或字元串,如下表所示:

原賬戶 映射後的賬戶

mary 13487

tom 23567

這層映射關係只有租戶自己知道,MixPanel或TalkingData都不知道。

這樣可以唯一定位到某個用戶賬戶,也避免了真實的用戶賬戶信息外流。

當然,有的租戶是不強制要求用戶註冊的,它沒有強用戶賬戶體系,比如墨跡天氣,下載了就可以用,這就無法區分多用戶使用一個手機,或者單用戶使用多個手機情況。

剛才啰啰嗦嗦說了一大堆,都是在說用戶唯一Id的事情。下面說說採集數據的事情。

MixPanel和TalkingData都提供了支持各種平台的SDK,供開發人員使用,用於採集用戶行為數據。我們下次再講。
推薦閱讀:

React應用架構設計
基於函數計算處理數據並分發的實踐操作
Android開發轉型公司技術負責人是一種怎樣的體驗
厲害了,螞蟻金服!創造了中國自己的資料庫OceanBase(上)

TAG:架構 |