- 產品
- 產品解決方案
- 行業解決方案
- 案例
- 數據資產入表
- 賦能中心
- 伙伴
- 關于
時間:2021-12-30來源:討厭被模仿瀏覽數:411次

李嬌老師:Hello,各位同學大家好。今天所分享的題目是主辦方給到我的,我一開始沒有去細想,感覺這對我應該沒有什么大問題。然而但我真的在做的時候發現,這個標題還挺大的,所以后面我可能揀選一個產品來去細聊,關于這款產品的建設過程。

這次分享我會分四個板塊來講。第一塊是產品設計方法;第二塊是隱私審批的設計,大家應該有所了解,從今年的上半年開始,國家對個人隱私相關信息的管控相較以往會更加嚴格;第三個是關于權限管理的創新;第四個是我們內部一些產品使用的案例。

1 產品設計方法
目前內部的產品非常多,會分很多的系列,有 ToB 商業化的,也有一些 TO G (政務)等等。今天我們說說的僅僅針對我們對內的產品。
首先第一個是要確定的是產品定位,關于產品可能面向的用戶群,那這些群體用戶有什么樣的數據問題。
第二,是用戶調研,需要對已經確定好用戶群進行一些調研,然后了解他們的特征。
第三,往往內部產品都會已經有歷史產品了,所以也需要去了解歷史產品的優點和缺點,在此基礎之上設計一個新產品。第四,基于前面的定位調研,還有一些歷史文件,充分了解之后,去做一些相關的一個產品架構,做完架構之后的話,就會跟研發一塊確認相應的技術點和研發的難點,而后再進行詳細的產品設計,后面可能會做內部的產品的運營。

1.1 產品定位
關于360數據中臺的產品定位,先是整個數據中臺一個大的定位,說我們有過分析,關于數據類的產品主要是給哪些人用的,發現基本上是給公司內部的各個業務線的領導、產品、運營、市場、商務、數據分析師、研發,還有會有一部分的數據科學家。他們重點想要了解的東西是關于新增、活躍、留存、流失這類的主題數據,還有一些關于轉化的,比如付費,還有一些崩潰相關的,比如錯誤分析事件,還有 LTV、AB 測試、畫像等等。

1.2 用戶調研
我們針對這些要服務的對象做一個用戶的調研。基本結論是,公司內部有 75% 的人的,需要使用數據類的平臺去做相關的一些分析或者可視化。用戶構成中,女生會占75%,非研發人員能占到88%。
我們大概分析了一下他們的工作場景,發現基本都業務人員,類似于產品、運營、分析師,只有極少數的會使用一些腳本命令的同學。那如果是這樣話,說明我們的產品其實要盡可能的簡單化,偏向于做又簡單又方便又好用的一個高效的分析平臺。

1.3 了解歷史問題
調研之后,我們就開始去了解歷史的問題。第一個歷史問題是,歷史系統非常多,操作麻煩。我們之前的系統,我這邊只列了 10 個,以前的老系統基本上有將近 20 來個,這樣用戶在使用的時候會有選擇困難癥,他們根本就不知道在做相應分析的時候應該使用哪一款產品,這就成為了一個痛點。
第二個歷史相關的問題是,不穩定因素導致系統存在很多的 bug。對于搭建新的中臺,我可能需要稍微解釋一下背景情況,在我接手中臺建設的時候,相關的中臺已經有 20 來個歷史的產品了。但是這些歷史產品因為各種各樣的原因,使用困難也好,BUG多也好,導致業務線的吐槽會非常的多,所以我才接手這個項目。我們基本上了解各種各樣問題之后,我們就能夠很清晰的知道我們要干什么。因此,經過重新的評估和分析,我們決定從 0 到 1 來搭建一個新的平臺。
1.4 產品架構

我們做了一個新平臺叫雷達分析,這個平臺本質上是要解決用戶對數據從采集到清洗再到分析的可視化。看起來問題只有四個,挺簡單,但是歷史上居然能做那么多系統,真的是挺難為他們的。我們重點是要幫助業務線的人員能夠快速的提升數據的獲取效率,然后可視化分析他們自己的數據,發現他們的問題,讓業務層面可以增加留存和營收,這個是我們解決的問題。

基于這四點:采集、清洗、分析、可視化,我們對流程進行了層級化的拆解。
·采集層:我們支持安卓、iOS、WEB、小程序等,以及服務端會支持到 hive mysql、druid等;
·清洗層:我們會基于具體的數據類型,形成 UE 模型和數倉模型。
·分析層:基于UE模型,我們會再做一個上層的分析,比如事件分析、留存漏斗等等。今天我也只是舉一點案例。基于數據模型倉,往上層就是自主查詢,多維分析,進一步會再做一些可視化層。我們會基于標準化的模型,生成相應的標準化報表,同時會支持用戶做一些個性化的自定義看板。
我們目前是使用 UE 模型和數倉模型合并的方式,這種方式不僅適合互聯網業務,同時也會適合物聯網業務以及各種各樣的通用的一些分析。那很多人可能聽到這里就會有疑問,現在已經聽你講完分層結構之后,我是不是就已經懂了之后如何做好一款數據產品了呢?不是這么簡單,我們還需要非常的清楚地了解這里面的數據的具體運轉的邏輯。大家可以看一下這個圖。

我們前面講到數據分成了來自客戶端的數據和來自服務端的數據。
圖中“客戶端的數據”流轉是用藍色的線表示,最終會變成標準化的報表,同時會支持事件分析和留存分析,也同時做成相應單獨的可配置的看板。
“服務端的數據”是可以支持自助查詢和ETL相關的操作,同時也支持多維分析(現在很多地方也稱之為OLAP ),可以配置更多的報表、看板,這樣用戶可以做一些業務的核心分析。我們正在設計中的,也是我們未來可能會支持的,是從服務端的數據可以自定義的轉化成客戶端的事件模型。
然后第二個數據流轉是我們未來會支持的內容,包含自助查詢和 ETL ,同時支持客戶端- SDK 的一些事件相關的內容。這個是我們設計的數據流的運轉邏輯。

? ? ? ?基于這個設計,我們已經上線了產品,因為這是我們公司內部的產品,我們也就并沒有去做對外的推廣,所以具體的產品形態相關的內容,我今天沒有辦法展示太多的截圖。去年 10 月份,我們完成了這個內部的產品的上線,上線時我們在內部開了一場發布會,我們對公司內部的一些重點的業務線做孵化,同時會創建“用戶群”。
? ? ? ?說完產品設計方法,那么產品在實現上線以后,我們的流程也就來到了最后一步,就是對上線的產品做相關運營的,只不過是對于內部人員使用的產品,相對而言,可能真的是只有用戶運營。我們對上線的產品分析發現,每周的活躍使用人數長不多是1000 多人,目前覆蓋了360內部幾乎所有的業務線,從大到小,從安全衛士、360搜索,到360瀏覽器、手機助手、手機衛士等等。