# 一、場景描述 做面向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·點這裡](https://github.com/cicadasmile/model-arithmetic-parent)|[GitEE·點這裡](https://gitee.com/cicadasmile/model-arithmetic-parent)|☆☆☆☆☆| |02|Java基礎、併發、面向物件、Web開發|[GitHub·點這裡](https://github.com/cicadasmile/java-base-parent)|[GitEE·點這裡](https://gitee.com/cicadasmile/java-base-parent)|☆☆☆☆| |03|SpringCloud微服務基礎元件案例詳解|[GitHub·點這裡](https://github.com/cicadasmile/spring-cloud-base)|[GitEE·點這裡](https://gitee.com/cicadasmile/spring-cloud-base)|☆☆☆| |04|SpringCloud微服務架構實戰綜合案例|[GitHub·點這裡](https://github.com/cicadasmile/husky-spring-cloud)|[GitEE·點這裡](https://gitee.com/cicadasmile/husky-spring-cloud)|☆☆☆☆☆| |05|SpringBoot框架基礎應用入門到進階|[GitHub·點這裡](https://github.com/cicadasmile/spring-boot-base)|[GitEE·點這裡](https://gitee.com/cicadasmile/spring-boot-base)|☆☆☆☆| |06|SpringBoot框架整合開發常用中介軟體|[GitHub·點這裡](https://github.com/cicadasmile/middle-ware-parent)|[GitEE·點這裡](https://gitee.com/cicadasmile/middle-ware-parent)|☆☆☆☆☆| |07|資料管理、分散式、架構設計基礎案例|[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent)|[GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent)|☆☆☆☆☆| |08|大資料系列、儲存、元件、計算等框架|[GitHub·點這裡](https://github.com/cicadasmile/big-data-parent)|[GitEE·點這裡](https://gitee.com/cicadasmile/big-data-parent)|☆☆