掌握數據生命週期：初識數據埋點

做者 | 秦路
來源 | tracykanc

談到數據驅動業務，離不開數據是怎麼來的，數據收集是整個數據生命週期的初始環節。

文章會涉及到很多技術相關的知識，我會盡可能減小這部分的細節。相信通過一系列的講解，你會明白埋點數據怎麼成爲驅動業務的指標，文章也會提供網上的公開數據，幫助你實際上手操做。

須要收集的數據主要能劃分紅四個主要類型：行爲數據、網站日誌數據、業務數據、外部數據。

Web日誌數據

網日誌數據是Web時代的概念。

用戶瀏覽的每個網頁，都會向服務器發送請求，具體的技術細節不用關注。只要知道，當服務器和用戶產生數據交互，服務器就會把此次交互記錄下來，咱們稱之爲日誌。

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"

上圖就是一條服務器日誌，它告訴了咱們，什麼樣的用戶who在什麼時間段when進行了什麼操做what。

127.0.0.1是用戶IP，即什麼樣的用戶。不一樣用戶的IP並不一致，經過它能基本的區分並定位到人。 [20/Jul/2017:22:04:08 +0800] 是產生這條記錄的時間，能夠理解爲用戶訪問的時間戳。

"GET /news/index HTTP/1.1"是服務器處理請求的動做，在這裏，姑且認爲是用戶請求訪問了某個網站路徑，/news/index。這裏省略了域名，若是域名是http://www.aaa.com，那麼用戶訪問的完整地址就是http://www.aaa.com/news/index，從字面意思理解，是用戶瀏覽了新聞頁。也就是what。

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

若是咱們基於who分析，能夠得知網站天天的PVUV；基於when分析，能夠得知平均瀏覽時長，每日訪問高峯；what則能得知什麼內容更吸引人、用戶訪問的頁面深度、轉化率等屬性。

上面的示例中，咱們用IP數據指代用戶，但用戶的IP並不固定，這對數據口徑的統一和準確率不利。實際應用中還須要研發們經過cookie或token獲取到用戶ID，而且將用戶ID傳遞到日誌中。它的形式就會變成：

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

123456就是用戶ID，經過它就能和後臺的用戶標籤數據關聯，進行更豐富維度的分析。

案例的服務器日誌，記錄了用戶的瀏覽數據，是標準的流量分析要素。可是網站上還會有其餘功，即更豐富的what，譬如評論、收藏、點贊、下單等，要統計這些行爲靠日誌就力有未逮了。因此業內除了服務器日誌，還會配合使用JS嵌入或者後臺採集的方式，針對各種業務場景收集數據。

在這裏我提供一份網上公開的數據集，年代比較古老，是學生在校園網站的瀏覽行爲數據集。數據原始格式是log，能夠txt打開。須要的同窗能夠在後臺發送「日誌下載」。

它是標準的服務器日誌文件，對分析師來講，IP，時間、瀏覽了哪些網頁，這三個字段足夠作出一份完整的分析報告。後續的章節我將圍繞它進行演練，爲了照顧新手，會同時用Excel和Python演示。

首先進行簡單的清洗。若是是Excel，直接將內容複製，文件開頭的內容只須要保留第四。

按空格進行分列，初步的數據格式就出來了。

咱們仔細觀察cs-uri-stem，會發現有不少無用數據。好比/images/index_r2_c1.jpg，它是向服務器請求了圖片數據，對咱們分析其實沒有多大幫助。用戶訪問的具體網頁，是/index.asp這類以.asp爲結尾的。

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

像172.16.100.11這位遊客，在凌晨30分的時候訪問了網站首頁，而後瀏覽了校園新聞和一週安排相關的內容，整個會話持續了半小時左右的時間

Python相關的清洗留待下一篇文章，這裏就很少花時間講解了。感興趣，你們能夠先自行練習一下。

APP行爲數據

數據埋點，抽象理解即是記錄用戶在客戶端的關鍵操做行爲，一行數據便等於一條行爲操做記錄。點擊「當即搶購」是，在文章頁面停留5min是，發表文章評論是，進行退出登陸操做是，視頻網站首頁看到了10條新視頻的內容曝光也是...反必要的，咱們都採集。

APP行爲數據是在日誌數據的基礎上發展和完善的。雖然數據的載體是在APP端，但它一樣能夠抽象出幾個要素：who、when、where、what、how。

who即惟一標識用戶，在移動端，咱們能夠很方便地採集到user_id，一旦用戶註冊，就會生成新的user_id。

這裏有一個問題，若是用戶處於未登陸狀態呢？若是用戶有多個帳號呢？爲了更好地統一和識別惟一用戶，移動端還會採集device_id，經過手機設備自帶的惟一標識碼進行區分。

實際的生成邏輯要複雜的多，安卓和iOS不同，device_id只能趨近於惟1、用戶更換設備後怎麼讓數據繼承，未登陸狀態的匿名帳戶怎麼繼承到註冊帳戶，這些都會影響到分析的口徑，不一樣公司的判斷邏輯不一致，此處注意踩坑。

回到用戶行爲：

when依舊是行爲發生的時間。

where即行爲發生的地點，手機上，經過GPS定位權限，獲取用戶比IP更詳細的經緯度數據並不難。

what是具體的行爲，瀏覽、點贊、評論、分享、關注、下單、舉報、打賞，均是行爲，如何統計取決於分析的維度。

若是咱們想知道用戶的點贊行爲，那麼在用戶點讚的時候要求客戶端上報一條like信息便可。

若是隻是到這裏，還稱不上埋點，由於點讚自己也會寫入到數據庫中，並不須要客戶端額外採集和上報，這裏就引入了全新的維度：how。

如何點贊，拿微信朋友圈舉例。絕大部分的點贊都是在朋友圈timeline中發送，可是小部分場景，是容許用戶進入到好友的我的頁面，對發佈內容單獨點讚的。服務端/後臺並不知道這個點贊在哪裏發生，得iOS或安卓的客戶端告訴它，這即是how這個維度的用處。

換一種思考角度，若是不少點贊或留言的發生場景不在朋友圈，而是在好友我的頁。這是否是能討論一下某些產品需求？畢竟朋友圈信息流內的內容愈來愈多，很容易錯過好友的生活百態，因此就會有那麼一批用戶，有須要去好友頁看內容的需求。這裏無心深刻展開產品問題，只是想說明，哪怕一樣是點贊，場景發生的不一樣，數據描述的角度就不一樣了：朋友圈的點贊之交/好友頁的點贊至交。

除了場景，交互行爲方式也是須要客戶端完成的。例如點擊內容放大圖片、雙擊點贊、視頻自動播放、觸屏右滑回退頁面...產品量級小，這些細節無足輕重，產品變大了之後，產品們多少會有這些細節型需求。

行爲埋點，一般用json格式描述和存儲，按點贊舉例：

params是嵌套的json，是描述行爲的how，業內一般稱爲行爲參數，event則是事件。action_type指的是怎麼觸發點贊，page是點贊發生的頁面，page_type是頁面的類型，如今產品設計，在推薦爲主的信息流中，除了首頁，還會在頂欄劃分子頻道，因此page=feed，page_type=game，能夠理解成是首頁的遊戲子頻道。item_id指對哪篇具體的內容點贊，item_type是內容類型爲視頻。

上述幾個字段，就構成了APP端行爲採集的how和what了。若是咱們再考慮的齊全一些，who、when及其餘輔助字段都能加上。

埋點怎麼設計，不是本篇文章的重點（實際上也複雜的多，它須要不少討論和文檔and so on，有機會再講），由於各家公司都有本身的設計思路和方法，有些更是按控件統計的無痕埋點。若是你們感興趣，能夠網絡上搜索文章，很多賣用戶分析平臺的SaaS公司都有文章詳細介紹。

除了行爲「點」，埋點統計中還包含「段」的邏輯，即用戶在頁面上停留了多久，這塊也是客戶端處理的優點所在，就很少作介紹了。

這裏提供一份來源於網上的我也不知道是啥內容產品的行爲數據源，雖然它的本意是用做推薦模型的算法競賽，不過用做用戶行爲分析也是能夠的。

這幾個字段即是用戶行爲的基礎字段，像deep_view，雖然沒有明確說明是什麼含義，但也猜想是描述了用戶瀏覽的深度，好比看了50%+的文章內容，它只能以客戶端的形式統計，實際業務場景每每都須要這種有更深入含義的數據。

具體的分析實操留待下一篇文章講解，感興趣的同窗能夠自行下載，和網頁日誌放一塊兒了。

行爲數據不是百分百準確的，採集用戶行爲，也會有丟失和缺漏的狀況發生。這裏不建議重要的統計口徑走埋點邏輯，好比支付，口徑缺失問題會讓人很抓狂的，相關統計仍是依賴支付接口計算。支付相關的埋點僅作分析就行。

APP行爲數據每每涉及到大數據架構，哪怕10萬DAU的一款產品，用戶在產品上的操做，也會包含數十個乃至上百的操做行爲，這些行爲都須要準確上報並落到報表，對技術架構是一個較大的挑戰。而行爲數據的加工處理，也並非mysql就能應付，每每須要分佈式計算。

對數據源的使用方，產品運營及分析師，會帶來一個取捨問題。若是我只想知道點贊和分享數，那麼經過api或者生產庫也能知道，是否須要細緻到行爲層面？這即是一個收益的考量。

固然啦，我我的仍是挺建議對分析有興趣的同窗，去能接觸到用戶行爲數據的公司去學習。

業務數據

業務數據是生產環境提供的，咱們在APP端得到了用戶user_id，文章或商品的item_id，乃至支付order_id，但它們只和用戶的行爲有關。換句話說，我並不知道user_id是什麼樣的用戶。

是男是女，芳齡幾何？出生籍貫，從哪裏來？這些人口統計學的信息必然不會在行爲埋點中包含。商品內容訂單也是同理。

單依靠埋點的行爲數據，咱們並不能準確描述什麼樣的用戶作了事情，也不知道對什麼樣的內容作了行爲。描述性質的數據/維度是分析的價值所在。男女的行爲差別，不一樣城市的用戶羣體購買習慣，這才構成了分析和精細化的基礎。

業務數據和行爲數據的結合，在數據層面上能夠簡單理解爲join。好比把用戶行爲數據的user_id和存放用戶信息的user_id進行關聯起來。造成以下：

上圖是簡化後的字段。user_name和sex就是取自業務數據的用戶信息，item_tag也是取自內容信息表中的字段，而event則來源於行爲埋點。三者共同構成了，什麼樣的用戶who在何時when對什麼樣的內容作了什麼事what。

簡單說，不少用戶行爲的建模，就是拿各類數據組合在一塊兒計算。用user_id的粒度聚合，你算得是這些用戶喜歡哪些文章，用item_id的粒度聚合，你算得是這篇文章被哪類用戶喜歡。它們都是你看待/分析事物的角度。

從更深的層面上說，行爲數據也是能夠再加工和利用的，它是構成用戶標籤的基礎。拿瀏覽行爲數聽說，咱們設計了埋點，知道王二狗看了哪些類型的文章，

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

如今取全部用戶的瀏覽數據，算它們在不一樣類型tag下的瀏覽分佈（上文提供的行爲數據就能夠計算，cate_id即是內容類型）。好比王二狗可能90%的瀏覽都是遊戲，10%是其餘，那麼就能夠認爲王二狗的興趣集中度高。

這裏有一個很簡易的公式，1-sum(p^2)，將全部內容類別的瀏覽佔比平方後相加，最終拿1減去，就算出了用戶興趣的集中程度了。咱們拿案例簡單看下。

上圖的李二狗，他的興趣90%集中在遊戲，因此興趣集中度= 1 - (0.90.9+0.10.1)=0.18,李三妞的興趣稍微平均點，因此1-(0.50.5+0.50.5)=0.5，興趣集中度比王二狗高。趙四有三個興趣點，因此比李三妞稍微高一些，王五是均衡的，因此是四人中最高的。可能有同窗疑問，興趣程度爲何不用標準差算呢？它也是算波動偏離的呀，這是一個思考題，你們能夠新加一個tag類別再算一下。

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

這裏並無涉及過高深的數學模型，只是用了加減乘除，就能快速的計算出興趣的集中程度了。經過行爲數據算出用戶興趣集中度，便能在分析場景中發揮本身的用武之地了，它是用戶畫像的基礎，之後有機會再深刻講解。

外部數據能夠分爲兩個部分，一個是行業市場調研類的，一個是爬蟲抓取的，它們也能做爲數據源分析，好比站外熱點內容和站內熱點內容、競品對手商家表現和本身產品的商家，你們有機會應用的很少，就很少講了，我也不怎麼熟。

到這裏爲止，文章主要講了用戶行爲層面的數據是怎麼來的，更可能是基礎概念的講解，下一篇文章會經過具體的數據教你們用戶行爲分析的技巧。不過，由於數據來源於網上，數據的豐富程度仍是欠缺了很多，說白了，業務場景比較弱，但願你們本身在工做中多思考。