作者 | 秦路

來源 | tracykanc

談到數(shù)據(jù)驅(qū)動業(yè)務(wù)，離不開數(shù)據(jù)是怎么來的，數(shù)據(jù)收集是整個數(shù)據(jù)生命周期的初始環(huán)節(jié)。

數(shù)據(jù)生命周期的大體介紹，在過去的一篇文章中有提到。雖然文章的部分內(nèi)容我準(zhǔn)備重新構(gòu)造，但是對于這部分的基礎(chǔ)環(huán)節(jié)，并沒有太多的變換。

文章會涉及到不少技術(shù)相關(guān)的知識，我會盡量減少這部分的細(xì)節(jié)。相信經(jīng)過一系列的講解，你會明白埋點(diǎn)數(shù)據(jù)怎么成為驅(qū)動業(yè)務(wù)的指標(biāo)，文章也會提供網(wǎng)上的公開數(shù)據(jù)，幫助你實際上手操作。

需要收集的數(shù)據(jù)主要能劃分成四個主要類型：行為數(shù)據(jù)、網(wǎng)站日志數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、外部數(shù)據(jù)。

Web日志數(shù)據(jù)

網(wǎng)日志數(shù)據(jù)是Web時代的概念。

用戶瀏覽的每一個網(wǎng)頁，都會向服務(wù)器發(fā)送請求，具體的技術(shù)細(xì)節(jié)不用關(guān)注。只要知道，當(dāng)服務(wù)器和用戶產(chǎn)生數(shù)據(jù)交互，服務(wù)器就會把這次交互記錄下來，我們稱之為日志。

127.0.0.1 - - [20/Jul/2017:22:04:08 +0800] "GET /news/index HTTP/1.1" 200 22262 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.66 Safari/537.36"

上圖就是一條服務(wù)器日志，它告訴了我們，什么樣的用戶who在什么時間段when進(jìn)行了什么操作what。

127.0.0.1是用戶IP，即什么樣的用戶。不同用戶的IP并不一致，通過它能基本的區(qū)分并定位到人。 [20/Jul/2017:22:04:08 +0800] 是產(chǎn)生這條記錄的時間，可以理解為用戶訪問的時間戳。

"GET /news/index HTTP/1.1"是服務(wù)器處理請求的動作，在這里，姑且認(rèn)為是用戶請求訪問了某個網(wǎng)站路徑，/news/index。這里省略了域名，如果域名是www.aaa.com，那么用戶訪問的完整地址就是www.aaa.com/news/index，從字面意思理解，是用戶瀏覽了新聞頁。也就是what。

who、when、what構(gòu)成了用戶行為分析的基礎(chǔ)。Mozilla/5.0這個字段是用戶瀏覽時用的瀏覽器，它的分析意義不如前三者。

如果我們基于who分析，可以得知網(wǎng)站每天的PVUV；基于when分析，可以得知平均瀏覽時長，每日訪問高峰；what則能得知什么內(nèi)容更吸引人、用戶訪問的頁面深度、轉(zhuǎn)化率等屬性。

上面的示例中，我們用IP數(shù)據(jù)指代用戶，但用戶的IP并不固定，這對數(shù)據(jù)口徑的統(tǒng)一和準(zhǔn)確率不利。實際應(yīng)用中還需要研發(fā)們通過cookie或token獲取到用戶ID，并且將用戶ID傳遞到日志中。它的形式就會變成：

127.0.0.1 - 123456 [20/Jul/2017:22:04:08 +0800]…

123456就是用戶ID，通過它就能和后臺的用戶標(biāo)簽數(shù)據(jù)關(guān)聯(lián)，進(jìn)行更豐富維度的分析。

案例的服務(wù)器日志，記錄了用戶的瀏覽數(shù)據(jù)，是標(biāo)準(zhǔn)的流量分析要素。但是網(wǎng)站上還會有其他功，即更豐富的what，譬如評論、收藏、點(diǎn)贊、下單等，要統(tǒng)計這些行為靠日志就力有未逮了。所以業(yè)內(nèi)除了服務(wù)器日志，還會配合使用JS嵌入或者后臺采集的方式，針對各類業(yè)務(wù)場景收集數(shù)據(jù)。

在這里我提供一份網(wǎng)上公開的數(shù)據(jù)集，年代比較古老，是學(xué)生在校園網(wǎng)站的瀏覽行為數(shù)據(jù)集。數(shù)據(jù)原始格式是log，可以txt打開。需要的同學(xué)可以在后臺發(fā)送「日志下載」。

它是標(biāo)準(zhǔn)的服務(wù)器日志文件，對分析師來說，IP，時間、瀏覽了哪些網(wǎng)頁，這三個字段足夠做出一份完整的分析報告。后續(xù)的章節(jié)我將圍繞它進(jìn)行演練，為了照顧新手，會同時用Excel和Python演示。

首先進(jìn)行簡單的清洗。如果是Excel，直接將內(nèi)容復(fù)制，文件開頭的內(nèi)容只需要保留第四。

按空格進(jìn)行分列，初步的數(shù)據(jù)格式就出來了。

我們仔細(xì)觀察cs-uri-stem，會發(fā)現(xiàn)有很多無用數(shù)據(jù)。比如/images/index_r2_c1.jpg，它是向服務(wù)器請求了圖片數(shù)據(jù)，對我們分析其實沒有多大幫助。用戶訪問的具體網(wǎng)頁，是/index.asp這類以.asp為結(jié)尾的。

利用過濾功能，將含有.asp字符串的內(nèi)容提取出來，并且只保留date、time、c-ip、cs-uri-stem、cs-uri-stem。按c-ip和time按從小到大排序，這樣用戶在什么時間做了什么的行為序列就很清晰了。

像172.16.100.11這位游客，在凌晨30分的時候訪問了網(wǎng)站首頁，然后瀏覽了校園新聞和一周安排相關(guān)的內(nèi)容，整個會話持續(xù)了半小時左右的時間

Python相關(guān)的清洗留待下一篇文章，這里就不多花時間講解了。感興趣，大家可以先自行練習(xí)一下。

APP行為數(shù)據(jù)

數(shù)據(jù)埋點(diǎn)，抽象理解便是記錄用戶在客戶端的關(guān)鍵操作行為，一行數(shù)據(jù)便等于一條行為操作記錄。點(diǎn)擊「立即搶購」是，在文章頁面停留5min是，發(fā)表文章評論是，進(jìn)行退出登錄操作是，視頻網(wǎng)站首頁看到了10條新視頻的內(nèi)容曝光也是...反必要的，我們都采集。

APP行為數(shù)據(jù)是在日志數(shù)據(jù)的基礎(chǔ)上發(fā)展和完善的。雖然數(shù)據(jù)的載體是在APP端，但它同樣可以抽象出幾個要素：who、when、where、what、how。

who即唯一標(biāo)識用戶，在移動端，我們可以很方便地采集到user_id，一旦用戶注冊，就會生成新的user_id。

這里有一個問題，如果用戶處于未登錄狀態(tài)呢？如果用戶有多個賬號呢？為了更好地統(tǒng)一和識別唯一用戶，移動端還會采集device_id，通過手機(jī)設(shè)備自帶的唯一標(biāo)識碼進(jìn)行區(qū)分。

實際的生成邏輯要復(fù)雜的多，安卓和iOS不一樣，device_id只能趨近于唯一、用戶更換設(shè)備后怎么讓數(shù)據(jù)繼承，未登錄狀態(tài)的匿名賬戶怎么繼承到注冊賬戶，這些都會影響到分析的口徑，不同公司的判斷邏輯不一致，此處注意踩坑。

回到用戶行為：

when依舊是行為發(fā)生的時間。

where即行為發(fā)生的地點(diǎn)，手機(jī)上，通過GPS定位權(quán)限，獲取用戶比IP更詳細(xì)的經(jīng)緯度數(shù)據(jù)并不難。

what是具體的行為，瀏覽、點(diǎn)贊、評論、分享、關(guān)注、下單、舉報、打賞，均是行為，如何統(tǒng)計取決于分析的維度。

如果我們想知道用戶的點(diǎn)贊行為，那么在用戶點(diǎn)贊的時候要求客戶端上報一條like信息即可。

如果只是到這里，還稱不上埋點(diǎn)，因為點(diǎn)贊本身也會寫入到數(shù)據(jù)庫中，并不需要客戶端額外采集和上報，這里就引入了全新的維度：how。

如何點(diǎn)贊，拿微信朋友圈舉例。絕大部分的點(diǎn)贊都是在朋友圈timeline中發(fā)送，但是小部分場景，是允許用戶進(jìn)入到好友的個人頁面，對發(fā)布內(nèi)容單獨(dú)點(diǎn)贊的。服務(wù)端/后臺并不知道這個點(diǎn)贊在哪里發(fā)生，得iOS或安卓的客戶端告訴它，這便是how這個維度的用處。

換一種思考角度，如果很多點(diǎn)贊或留言的發(fā)生場景不在朋友圈，而是在好友個人頁。這是不是能討論一下某些產(chǎn)品需求？畢竟朋友圈信息流內(nèi)的內(nèi)容越來越多，很容易錯過好友的生活百態(tài)，所以就會有那么一批用戶，有需要去好友頁看內(nèi)容的需求。這里無意深入展開產(chǎn)品問題，只是想說明，哪怕同樣是點(diǎn)贊，場景發(fā)生的不同，數(shù)據(jù)描述的角度就不同了：朋友圈的點(diǎn)贊之交/好友頁的點(diǎn)贊至交。

除了場景，交互行為方式也是需要客戶端完成的。例如點(diǎn)擊內(nèi)容放大圖片、雙擊點(diǎn)贊、視頻自動播放、觸屏右滑回退頁面...產(chǎn)品量級小，這些細(xì)節(jié)無足輕重，產(chǎn)品變大了以后，產(chǎn)品們多少會有這些細(xì)節(jié)型需求。

行為埋點(diǎn)，通常用json格式描述和存儲，按點(diǎn)贊舉例：

params是嵌套的json，是描述行為的how，業(yè)內(nèi)通常稱為行為參數(shù)，event則是事件。action_type指的是怎么觸發(fā)點(diǎn)贊，page是點(diǎn)贊發(fā)生的頁面，page_type是頁面的類型，現(xiàn)在產(chǎn)品設(shè)計，在推薦為主的信息流中，除了首頁，還會在頂欄劃分子頻道，所以page=feed，page_type=game，可以理解成是首頁的游戲子頻道。item_id指對哪篇具體的內(nèi)容點(diǎn)贊，item_type是內(nèi)容類型為視頻。

上述幾個字段，就構(gòu)成了APP端行為采集的how和what了。如果我們再考慮的齊全一些，who、when及其他輔助字段都能加上。

埋點(diǎn)怎么設(shè)計，不是本篇文章的重點(diǎn)（實際上也復(fù)雜的多，它需要很多討論和文檔and so on，有機(jī)會再講），因為各家公司都有自己的設(shè)計思路和方法，有些更是按控件統(tǒng)計的無痕埋點(diǎn)。如果大家感興趣，可以網(wǎng)絡(luò)上搜索文章，不少賣用戶分析平臺的SaaS公司都有文章詳細(xì)介紹。

除了行為「點(diǎn)」，埋點(diǎn)統(tǒng)計中還包含「段」的邏輯，即用戶在頁面上停留了多久，這塊也是客戶端處理的優(yōu)勢所在，就不多做介紹了。

這里提供一份來源于網(wǎng)上的我也不知道是啥內(nèi)容產(chǎn)品的行為數(shù)據(jù)源，雖然它的本意是用作推薦模型的算法競賽，不過用作用戶行為分析也是可以的。

這幾個字段便是用戶行為的基礎(chǔ)字段，像deep_view，雖然沒有明確說明是什么含義，但也猜測是描述了用戶瀏覽的深度，比如看了50%+的文章內(nèi)容，它只能以客戶端的形式統(tǒng)計，實際業(yè)務(wù)場景往往都需要這種有更深刻含義的數(shù)據(jù)。

具體的分析實操留待下一篇文章講解，感興趣的同學(xué)可以自行下載，和網(wǎng)頁日志放一起了。

行為數(shù)據(jù)不是百分百準(zhǔn)確的，采集用戶行為，也會有丟失和缺漏的情況發(fā)生。這里不建議重要的統(tǒng)計口徑走埋點(diǎn)邏輯，比如支付，口徑缺失問題會讓人很抓狂的，相關(guān)統(tǒng)計還是依賴支付接口計算。支付相關(guān)的埋點(diǎn)僅做分析就行。

APP行為數(shù)據(jù)往往涉及到大數(shù)據(jù)架構(gòu)，哪怕10萬DAU的一款產(chǎn)品，用戶在產(chǎn)品上的操作，也會包含數(shù)十個乃至上百的操作行為，這些行為都需要準(zhǔn)確上報并落到報表，對技術(shù)架構(gòu)是一個較大的挑戰(zhàn)。而行為數(shù)據(jù)的加工處理，也并不是mysql就能應(yīng)付，往往需要分布式計算。

對數(shù)據(jù)源的使用方，產(chǎn)品運(yùn)營及分析師，會帶來一個取舍問題。如果我只想知道點(diǎn)贊和分享數(shù)，那么通過api或者生產(chǎn)庫也能知道，是否需要細(xì)致到行為層面？這便是一個收益的考量。

當(dāng)然啦，我個人還是挺建議對分析有興趣的同學(xué)，去能接觸到用戶行為數(shù)據(jù)的公司去學(xué)習(xí)。

業(yè)務(wù)數(shù)據(jù)

業(yè)務(wù)數(shù)據(jù)是生產(chǎn)環(huán)境提供的，我們在APP端獲得了用戶user_id，文章或商品的item_id，乃至支付order_id，但它們只和用戶的行為有關(guān)。換句話說，我并不知道user_id是什么樣的用戶。

是男是女，芳齡幾何？出生籍貫，從哪里來？這些人口統(tǒng)計學(xué)的信息必然不會在行為埋點(diǎn)中包含。商品內(nèi)容訂單也是同理。

單依靠埋點(diǎn)的行為數(shù)據(jù)，我們并不能準(zhǔn)確描述什么樣的用戶做了事情，也不知道對什么樣的內(nèi)容做了行為。描述性質(zhì)的數(shù)據(jù)/維度是分析的價值所在。男女的行為差異，不同城市的用戶群體購買習(xí)慣，這才構(gòu)成了分析和精細(xì)化的基礎(chǔ)。

業(yè)務(wù)數(shù)據(jù)和行為數(shù)據(jù)的結(jié)合，在數(shù)據(jù)層面上可以簡單理解為join。比如把用戶行為數(shù)據(jù)的user_id和存放用戶信息的user_id進(jìn)行關(guān)聯(lián)起來。形成如下：

上圖是簡化后的字段。user_name和sex就是取自業(yè)務(wù)數(shù)據(jù)的用戶信息，item_tag也是取自內(nèi)容信息表中的字段，而event則來源于行為埋點(diǎn)。三者共同構(gòu)成了，什么樣的用戶who在什么時候when對什么樣的內(nèi)容做了什么事what。

簡單說，很多用戶行為的建模，就是拿各種數(shù)據(jù)組合在一起計算。用user_id的粒度聚合，你算得是這些用戶喜歡哪些文章，用item_id的粒度聚合，你算得是這篇文章被哪類用戶喜歡。它們都是你看待/分析事物的角度。

從更深的層面上說，行為數(shù)據(jù)也是可以再加工和利用的，它是構(gòu)成用戶標(biāo)簽的基礎(chǔ)。拿瀏覽行為數(shù)據(jù)說，我們設(shè)計了埋點(diǎn)，知道王二狗看了哪些類型的文章，

item_tag是文章類型，游戲、娛樂、科技這類。有些用戶可能各種各樣的類型都喜歡，有些用戶的口味偏好則比較集中，產(chǎn)品上可以拿用戶偏好來代稱，這里專指興趣的集中度。

現(xiàn)在取所有用戶的瀏覽數(shù)據(jù)，算它們在不同類型tag下的瀏覽分布（上文提供的行為數(shù)據(jù)就可以計算，cate_id便是內(nèi)容類型）。比如王二狗可能90%的瀏覽都是游戲，10%是其他，那么就可以認(rèn)為王二狗的興趣集中度高。

這里有一個很簡易的公式，1-sum(p^2)，將所有內(nèi)容類別的瀏覽占比平方后相加，最終拿1減去，就算出了用戶興趣的集中程度了。我們拿案例簡單看下。

上圖的李二狗，他的興趣90%集中在游戲，所以興趣集中度= 1 - (0.9*0.9+0.1*0.1)=0.18,李三妞的興趣稍微平均點(diǎn)，所以1-(0.5*0.5+0.5*0.5)=0.5，興趣集中度比王二狗高。趙四有三個興趣點(diǎn)，所以比李三妞稍微高一些，王五是均衡的，所以是四人中最高的。可能有同學(xué)疑問，興趣程度為什么不用標(biāo)準(zhǔn)差算呢？它也是算波動偏離的呀，這是一個思考題，大家可以新加一個tag類別再算一下。

1-sum(p^2)是趨近于1的，有四個類別，一位均衡的用戶（四個都是0.25）是0.75的集中度，當(dāng)有十個類型，一位均衡的用戶（四個都是0.1）是0.9的集中度。這種公式的好處就是興趣類別越多，集中度的上限越接近1，這是標(biāo)準(zhǔn)差比不了的。

這里并沒有涉及太高深的數(shù)學(xué)模型，只是用了加減乘除，就能快速的計算出興趣的集中程度了。通過行為數(shù)據(jù)算出用戶興趣集中度，便能在分析場景中發(fā)揮自己的用武之地了，它是用戶畫像的基礎(chǔ)，以后有機(jī)會再深入講解。

外部數(shù)據(jù)可以分為兩個部分，一個是行業(yè)市場調(diào)研類的，一個是爬蟲抓取的，它們也能作為數(shù)據(jù)源分析，比如站外熱點(diǎn)內(nèi)容和站內(nèi)熱點(diǎn)內(nèi)容、競品對手商家表現(xiàn)和自己產(chǎn)品的商家，大家有機(jī)會應(yīng)用的不多，就不多講了，我也不怎么熟。

到這里為止，文章主要講了用戶行為層面的數(shù)據(jù)是怎么來的，更多是基礎(chǔ)概念的講解，下一篇文章會通過具體的數(shù)據(jù)教大家用戶行為分析的技巧。不過，因為數(shù)據(jù)來源于網(wǎng)上，數(shù)據(jù)的豐富程度還是欠缺了不少，說白了，業(yè)務(wù)場景比較弱，希望大家自己在工作中多思考。