流量紅利之後，營收創造何去何從？——拍拍貸借出用戶CRM演進史告訴你
【導語】 王興口中的互聯網下半場，依靠人口紅利、流量增益來創造營收的時代已經過去，企業需要對用戶進行深耕細作才能實現收入和利潤的持續增長。過去的幾年裡，拍拍貸將運營體系中的大數據應用從紙上談兵到落地，幾經波折終有小成。現以借出用戶CRM為例，讓我們一起走進拍拍貸用戶CRM的演進歷史。
- 【背景】 -
借出用戶CRM是基於真實的業務場景對用戶進行畫像，最大的目標自然是解決實際的業務問題，不外乎獲取新用戶、提升用戶體驗、挽迴流失用戶等等與用戶息息相關的領域。而根據用戶畫像的信息做產品設計，必須要清楚知道用戶長什麼樣子，有什麼行為特徵和屬性，只有準確的畫像才能帶來最好的業務成效。
慣性思維中，用戶畫像維度越多、畫像數據越豐富越好，直到費了很大力氣進行畫像，卻發現數據與業務需求相差甚遠，能夠使用的標籤寥寥無幾，對業務運營的支持也收效甚微。因此，拍拍貸借出用戶CRM最初的設計思路就是緊跟業務需求，以業務指導產品，設計最合理、最高效的用戶畫像。
- 【借出用戶畫像架構演進】 -
拍拍貸用戶劃分
我們手中掌握哪些數據? --維度信息
目前人民公園借出用戶體系數據包括的信息如下:
? 借出用戶畫像數據倉庫表 19張
? 借出用戶標籤信息 200+
? UBT數據(APP、PC、H5等)
? 第三方渠道數據
? 每日增量數據
- 【借出用戶1.0的產品結構&工程架構】 -
基於現有的數據，為了最大限度的滿足業務方的需求，我們設計了借出 CRM的基礎數據鏈路。
工程架構設計
按照離線統計類標籤設計，實現借出CRM的基礎需求，完成從0-1的過程。
Hive -- 計算
Impala -- 查詢
ElasticSearch -- 介面服務
先後梳理完成統計類標籤 、規則標籤、模型標籤等4大類，覆蓋借出運營的核心環節
產品1.0
1.0主要解決0-1的問題，但是隨著業務夥伴的深入使用，更多的問題也浮現出來。主要暴露出的問題有以下三塊：
數據量與精準度問題
如何更好的服務於模型
業務使用的穩定性問題
- 【借出用戶2.0的產品結構&工程架構】 -
為了解決1.0產品的問題，全面梳理過問題的癥結所在，結合開發的實際情況形成了如下計劃表
2.0架構
注.圖中紅色模塊為後續計劃
新架構基本解決1.0的大部分問題，同時將線上獲取數據的 Pull 模式也變成 Push 模型，提高的數據的使用度及響應度。Spark作為新的大數據組件也開始在畫像服務中嶄露頭角。
產品2.0
自動化營銷平台：可自主創建營銷活動，定時對觸達營銷條件的客戶自動發放offer，省去了繁瑣的人工篩選和名單導入，提高運營效率，提升用戶體驗。
活動統計後台：協助業務端收口線上、線下運營活動數據，可以T+1的查看用戶參加活動的相關數據。已經完成2017年後大部分歷史活動數據的追溯，可對用戶行為進行廣泛追蹤。
人工銷售CRM後台：連接Drools，實現智能化名單的多渠道發送
- 【小結】 -
本文大致介紹了借出用戶產品的演進歷程。在這個實踐過程中，深刻體會到大數據的本質是消除不確定性，我們可以結合大數據更加精準的分析了解用戶特徵、用戶行為，以便更好更多地服務於大多數用戶。同時，產品的設計應以業務為中心做展開，要以業務數據支撐產品迭代。
當然，雖然借出用戶CRM已經在業務在取得了一定的成效， 但順應互聯網時代的發展和信息技術的更新，以及越來越多的用戶數據可用性得到證明，我們的產品在未來的更新迭代中依然面臨著不小的挑戰：
? 數據多樣性。用戶數據中存在大量非結構化數據，例如用戶LBS信息、瀏覽信息解析等。 需要用到NLP技術，同時結合其他數據進行分析。
? 相對於投資用戶而言，金融產品是個相對單一的SKU品類，用戶在APP的行為不足以全方位地描述用戶的基本屬性。因此需要和借出用戶在其他場景的行為數據做融合。
面臨這些挑戰，需要團隊更細緻的數據處理、融合多方數據源，同時發展出新的方法論，才能更好地支持業務發展的需要。而上述挑戰，又分別和一些互金的友商類似，經驗上存在可以相互借鑒之處。
世界盃頭像了解一下
TAG:拍黑米 |