創業公司錢、開發資源有限,考究更少的工做產生更大的價值,更快的迭代mvp。
data -> info -> knowledge -> wisdomgit
儘可能減小拍腦殼的決策。
決策要從過往經驗到數據驅動;當沒有經驗的時候,參考外部、常識、少許測試驗證。github
數據驅動,不單單是採集數據,取數的效率,數據的質量,對數據的驗證都是很是關鍵的。sql
系統架構複雜度決定採用的方式vim
單體應用,單個應用DB:直接從應用的DB的副本集讀取,爲防止報表數據的讀寫影響主系統。
副本集根據線上應用DB壓力、報表DB壓力狀況選擇:api
跨系統/微服務應用:網絡
因爲負責報表的開發的通常是熟悉 SQL/R/Python,因此考慮直接SQL類的數據直接查到時最合適的(投入時間少、熟悉度高)。[!img]圖
BI 報表咱們能夠選擇相似Redash/SuperSet 這類工具,來快速定製業務的報表。架構
stage 1: 有效利用第三方統計平臺
baidu/google
umeng
漏斗、留存、熱點、bug、網絡、用戶的畫像(本身也要分析)app
例如經過推廣活動熱點數據,能夠發現有些用戶體驗(UX)上,設計與實際有用戶逾期有誤。dom
stage 2:
熱點、漏斗、行爲
fullstory/appsee/mouseflow
GrowingIO/諸葛IO微服務
stage 3:
創建本身的數據分析平臺
基本漏斗:訪問、註冊、下載、交易、復投
常見的業務指標:
獲客、留存率
生命週期:流失型、成長型、新用戶
金融的指標:標籤,欺詐分數(自定義),價值分數(自定義)
幾個須要關注的維度
Grafana 報表
維度:
容器的性能
異常報警
物理部署給報表DB到業務方
小量: excel/csv 導出,方便分析
BI自助:提供模板BI自取
大量:API SDK 調用方式,方便Python/R分析
excel ,本身lookup
界面自定義查詢
提供必定的sql,開發、業務方自主到查詢
提供必定的data sdk ,開發、業務方自主到查詢
金融公司,模型指標,不要猜想,去證明。
工具:
- ab test(https://github.com/xavimb/ab-testing)[!img]圖
- apphoc
全公司的事:
防止錯誤數據進入prod
業務方與數據開發的同理配合
讀懂業務的指標 :
普通(DRU、DAU)
專業(ROC、AUC、GINI)
數據全棧工程師
需求避免拍腦殼。
理想的狀況下,除了有各類的報表維度,對數據能夠導出or在線熱查詢,以便業務人員本身解決本身的需求。
ROI!!!