這一篇介紹的來介紹一下我在工作中接觸到的使用者行為分析系統。在這個系統中主要負責功能開發，計算邏輯開發，日誌檢測告警等，資料處理，資料準清洗備也有涉及。
使用者行為分析在現在這個時期已經是乙個比較常見，使用很廣的乙個詞，在網際網路公司，有大資料團隊的基本上都會提供這樣一套分析系統，以及近年來也出現了很多專門提供這類服務的公司，提供使用者分析，分群分析，使用者畫像，智慧型運營等。在運營產品中也經常會聽到這一類的概念，術語，指標等。下面主要介紹我所接觸到的內容。
使用者行為分析採用的資料模型是比較常見或者業內的乙個通用的概念，事件行為+使用者基礎資訊。用事件event表示使用者的乙個行為操作，用事件中的眾多屬性表示使用者乙個行為的細節描述。
簡單概括，何人(who) 何時(when) 在何處(where) 用何種方式(how)做何事(what)
what何事可以用事件event表示，何人who就是使用者標識id可以進一步關聯使用者基礎資訊，何時就是事情發生的時間，何處where發生的地點可以用屬性表示，何種方式how也可以用屬性表示，類推。
所以資料模型可理解為：使用者行為 = 事件 + 屬性(眾多) + 使用者id。只要擁有最全量的事件資料便可做到你想要的分析。多維度，多條件，多模型的分析。
埋點一般分為視覺化/全埋點/無埋點，和**埋點。這兩種各有優缺點，這裡只做乙個簡單的介紹，第一種下面就統稱為全埋點。
全埋點是前端的一種埋點方式， 在產品中嵌入sdk，最統一的埋點，通過介面配置的方式對關鍵的行為進行定義，完成埋點採集，這種是前端埋點方式之一。
優勢：劣勢：
作為前端埋點會存在一些天然的劣勢
**埋點，這個也是目前我們使用的埋點方式，**埋點分為前端**埋點和後端**埋點，前端埋點類似於全埋點，也需要嵌入sdk，不同的是對於每個事件行為都需要呼叫sdk**，傳入必要的事件名，屬性引數等等，然後發到後台資料伺服器。後端埋點則將事件、屬性通過後端模組呼叫sdk介面方式傳送到後台伺服器。
我們採用的是**埋點，分為前後端。埋點是乙個特別重要的過程，它是資料的源頭，如果資料源頭出現問題，那麼資料本身就存在問題，分析結果也就喪失了意義。
由於我負責日誌檢測，也就是埋點後的事件日誌的檢測告警，並通知對應的埋點開發人員，運營方，產品方，所以也就遇到了過其中存在的很多坑，大部分是流程方面的。
事件屬性是有一套元資料管理系統，業內的一些服務也是這種結構。一般是先定義事件、屬性，後埋點的方式，原因是事件日誌資料是需要經過檢查的，需要檢查事件是否存在，屬性是否缺失，資料是否正常等等。
遇到的坑：
資料不對，這種情況很難檢測出來，需要運營產品在分析中發現，這也是就難受的一點
事件資料是儲存在機器上的日誌，這裡的採集是指將機器日誌檔案存放到hdfs系統中的過程。業內有很多這種採集功能，filebeat，flume，python指令碼等都可採集。當前前面說的事件埋點也可以算是資料採集中的一部分
etl，將事件日誌，一般都是json格式的日誌進行解析，寫入hive庫中，事件表中，這裡就不做過多說明了
這部分屬於分析功能，也是我主要負責的部分。業內常見的分析模型有事件分析，漏斗分析，留存分析，路徑分析，渠道分析、分布分析等等。目前實現了前面四種、事件、漏斗、留存、路徑
有時間再做記錄
使用者行為分析
使用者行為軌跡 熟悉 瀏覽 搜尋 平均停留時長 跳出率 頁面偏好 搜尋訪問次數佔比 試用 使用者註冊 註冊使用者數 註冊轉化率 使用 使用者登入 使用者訂購 登入使用者數 人均登入 訪問登入比 訂購量 訂購頻次 內容 轉化率 忠誠 使用者粘度 使用者流失 回訪者比率 訪問深度 使用者流失數 流失率 ...
使用者行為分析（摘）
訪問量分時段分析 通過分析不同時段的訪問量 使用者情況 找出幾個業務訪問高峰時段，再對它們進行重點分析。時段可以為分不同的顆粒 小時 一周各天，一月中各個階段，一年中的各個階段。通過它們可以找出線上營 銷的時間點，也可以借助其它的分析手段，分析這些時段的共性，找出哪些使用者群體在些時段為重要消費群。...
使用者行為分析框架
前言 這個名字起的太大，其實我只是想說明乙個設計。這個設計是用於收集並分析使用者行為的。一般我們分析使用者行為離不開資料，這些資料可以來自於資料庫也可以來自於使用者操作日誌。這裡我介紹的就是基於使用者操作日誌的行為分析方法。這個方法也可以說是乙個設計，該設計包含三個部分。第一部分是使用者行為資料收集...