一、場景描述
做面向C端用戶的產品,十分依賴用戶資料的收集,下面都見過這樣一張資料分析圖,通過鏈路上各個環節的資料采集,分析對比出曝光產品的交易量:

通過對商品的瀏覽-點擊-交易頁面-支付購買等,分析產品的交易場景,這里是從大的業務方面觀察資料的鏈路,實際上在分析的時候要考慮很多細節問題,
二、資料來源
用戶資料來衡量用戶或者產品的各方面緯度是最具有說服力的,所以在互聯網的產品后期開發和優化程序中,對資料的采集和管理一直都是非常重要操作,
現在產品常見的客戶端有PC端、H5端、APP端、小程式等各個場景的入口,更有一些物聯網設備或者專門做的資料采集機制,不同的場景下的資料型別都是要區分的,通過不同埠下各類資料埋點,獲取各個場景下的不同事件的資料來分析產品的優缺點,獲取具有建設性的分析結果,
例如模塊一中的案例:通過對埠的分析如果在APP端商品A的推薦和交易率最高,在小程式端推薦效果不好,那就可以考慮針對APP和小程式端采用不同的推薦機制,
三、事件型別劃分
資料需要采集,并且要區分不同埠的資料只是基本的意識層面,思考采集資料的事件型別是最基礎的操作,這里要從產品的特點去考慮,不同一概而論,下面提供一些基礎采集資料和一些常見案例,關于核心業務資料相對都是精細和完整的,基本具備讀庫直接分析的條件,
基礎資訊
| 屬性 | 欄位 | 型別 | 描述 |
|---|---|---|---|
| 操作終端 | app_client | String | Android/IOS/小程式/H5等 |
| 終端版本 | app_version | String | 版本號標識 |
| 用戶標識 | user_id | Integer | 用戶ID |
| 網路地址 | ip_address | String | 用戶IP資訊 |
這些資訊是存在任何采點資料中的,通過這些基礎資訊采集,用來分析不同埠下用戶的特點,以此可以進行差異化的管理和運營,
登錄資訊
| 屬性 | 欄位 | 型別 | 描述 |
|---|---|---|---|
| 登錄時間 | login_time | Date | 用戶登錄時間 |
| 在線時長 | online_time | Long | 在線使用系統的時間 |
通過對登錄和在線時間,以及一些使用資訊,判斷該類用戶活躍度,是否需要重點運營或者營銷激活,
業務基礎
| 屬性 | 欄位 | 型別 | 描述 |
|---|---|---|---|
| 服務型別 | service_id | Integer | 不同的業務服務 |
| 模塊劃分 | model_type | Integer | 例如訂單/支付/物流等 |
以此作為業務資料采集的基礎資訊,用來對業務資料做整體的劃分和分析,具體的細節資料需要根據具體場景設計,
商品案例
| 屬性 | 欄位 | 型別 | 描述 |
|---|---|---|---|
| 商品資訊 | product_id | Integer | 商品資訊 |
| 展現位置 | position_id | Integer | 例如:串列/推薦位/廣告位 |
| 店鋪資訊 | shop_id | Integer | 所屬店鋪資訊 |
| 搜索資訊 | key_word | String | 搜索關鍵字 |
| 當前單價 | unit_price | Double | 商品當前單價 |
| 當前銷量 | sales_num | Long | 商品當前銷量 |
這里是按照用戶瀏覽行為做的一個簡單的資料采集資訊,這種機制在實際的電商APP中很常見,產生點擊或者搜索的商品會被重點推薦,如果沒有這類動作,則根據日常瀏覽資訊做推薦機制,在實際的開發中,采集的資料遠比這里復雜,需要根據實際業務需要去考量,
營銷案例
| 屬性 | 欄位 | 型別 | 描述 |
|---|---|---|---|
| 活動位置 | location_id | Integer | 入口位/引導頁/推薦位/分享鏈接等 |
| 營銷產品 | product_id | Long | 營銷活動主打產品型別 |
| 產品詳情流量 | detail_num | Long | 活動產品瀏覽量統計 |
| 訂單確認頁 | detail_num | Long | 活動產品瀏覽量統計 |
| 活動交易統計 | trade_num | Long | 活動最終轉化統計 |
通過運營活動進行產品營銷,活動結束后對資料進行復盤統計,然后根據活動軌跡資料的分析,平衡營銷產生的價值和成本,不斷調整活動策略,優化運營思路,
四、實作方式
1、業務層面
從業務角度來看,除了一些用戶無感知的采集操作之外,還可以基于問卷調查方式,例如很多APP在使用一段時間后都會彈出用戶評價類似的評分系統,或者意見留言的入口,更加直接的搜集用戶反饋資訊,
2、技術層面
最常見的就是SDK埋點技術,針對特定用戶行為或事件進行捕獲、處理和發送給服務器的相關技術及其實施程序,這種方式用來處理一些非核心業務十分常見,如果是一些核心業務,可能需要自定義的方式采集資料,避免造成資料泄露的問題,
3、資料積累
當業務不斷發展,需要分析的場景會越來越復雜,而且采集的資料量達到一定規模之后,資料管理的和分析的難度就會變大,就會需要專業化的流程和智能工具,例如BI工具,可視化組件,資料大屏,多場景聯合分析等,
五、源代碼地址
GitHub·地址
https://github.com/cicadasmile
GitEE·地址
https://gitee.com/cicadasmile
推薦閱讀:編程體系整理
| 序號 | 專案名稱 | GitHub地址 | GitEE地址 | 推薦指數 |
|---|---|---|---|---|
| 01 | Java描述設計模式,演算法,資料結構 | GitHub·點這里 | GitEE·點這里 | ☆☆☆☆☆ |
| 02 | Java基礎、并發、面向物件、Web開發 | GitHub·點這里 | GitEE·點這里 | ☆☆☆☆ |
| 03 | SpringCloud微服務基礎組件案例詳解 | GitHub·點這里 | GitEE·點這里 | ☆☆☆ |
| 04 | SpringCloud微服務架構實戰綜合案例 | GitHub·點這里 | GitEE·點這里 | ☆☆☆☆☆ |
| 05 | SpringBoot框架基礎應用入門到進階 | GitHub·點這里 | GitEE·點這里 | ☆☆☆☆ |
| 06 | SpringBoot框架整合開發常用中間件 | GitHub·點這里 | GitEE·點這里 | ☆☆☆☆☆ |
| 07 | 資料管理、分布式、架構設計基礎案例 | GitHub·點這里 | GitEE·點這里 | ☆☆☆☆☆ |
| 08 | 大資料系列、存盤、組件、計算等框架 | GitHub·點這里 | GitEE·點這里 | ☆☆☆☆☆ |
轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/235393.html
標籤:其他
上一篇:如何減少和處理死鎖 - MySQL 8.0官方檔案筆記(四)
下一篇:抖音資料采集教程,初級版
