app監測(監控app)

編輯導語：數據監測管理平臺會根據不同業務的流程和需求做出改變，然而萬變不離其宗的原理。本文作者根據工作中的項目實踐，并結合經驗主要分享從0-1平臺產品規劃設計中的APP管理、數據監測和權限管理功能設計經驗，供大家參考和學習。

一、 項目背景

2021年4月中旬，J銀行為加強對行內幾十個移動應用的集中監測管理，搭建APP監測管理平臺，實現移動應用集中管理，建立數據指標體系實現數據可視化，通過開展運營數據監測和數據分析，為移動應用運營提供數據支持。甲方領導十分重視該項目，把該項目列為最高優先級別，并給予大力支持。

二、需求分析

J銀行為了對行內和旗下多個APP進行監測管理而搭建APP監測管理平臺，主要包括APP管理，審核管理、運營監測和用戶權限管理等功能。該平臺作為銀行內部后臺，注重業務功能操作實用性，便利性，個性化要求不高。目標用戶是銀行內部平臺使用人員，主要包括高管、業務經理和業務員。

項目采用敏捷模式進行，我們和甲方項目負責人一起集中辦公，方便溝通和了解項目進展。我們解讀需求文檔、業務規則，對整體需求業務流程進行梳理，并組織小組討論。

需求分析過程中，我們對不明確的需求進行小組討論并和跨地區業務部門(使用小魚易連)遠程視頻會議；定期對成果物采用視頻會議跨地區跨部門評審。

人力資源有限，需求范圍較大（七大模塊、24個二級菜單功能），我經過評估，及時向上級申請支援，增派了2名產品經理。在有限的人力資源(團隊共6名產品經理)、有限的專業水平（2名初級、3名中級和1高級）和有限的時間經過需求分析、跨部門協同溝通、確認范圍、產品設計和部門內部評審等眾多環節，完成項目范圍全部需求的高清原型設計有些不切實際。

我及時向甲方項目負責人反饋，并建議項目實施范圍分兩個階段，現階段先把項目主要功能模塊進行設計實施，第二階段再增加次要的功能。甲方項目負責人聽取了我的建議，并及時向甲方領導匯報，通過縮小第一階段實施范圍的建議，為后繼項目任務圓滿結束打下堅實的基礎。

三、產品設計

統籌：我帶領團隊（共6人）進行監測平臺需求分析并統籌使用Axure進行高清原型設計及團隊協作原型的版本管理。我們統一字體色調排版，使用元件庫制作高清原型。這樣我們設計出來的高清度原型，在視覺風格、樣式規范(包括字體、按鈕、表單和表格等)都得到統一。

培訓：我根據以往產品設計經驗，首先讓團隊成員了解需求、熟悉業務流程、搞懂業務邏輯，把業務流程梳理出來，再進行原型設計，并對初級產品經理進行速成Axure技能培訓。

經過統籌和培訓后，我們開始產品設計，這里主要敘述APP監測管理平臺的APP管理、數據監控和權限管理的功能設計和經驗。

1. APP管理

APP管理是對銀行多個APP進行集中管理，主要包括上市申請、退市備案和版本管理。

1）上市申請

APP上市申請是APP在應用市場上架前的上市申請，需要的資料包括但不限于前期市場調研、可行性分析、產品策劃方案、APP版本計劃、業務說明、APP體驗包及APP法務合規報告等，由相關部門 (例如：網絡金融部、金融科技部、法律事務部和公共關系部）進行聯合審核，最終輸出決策結論。

業務流程如下圖：

APP上市申請提交后，可以在審核管理里查看申請記錄。點擊該記錄【詳情】可查看記錄的APP基本信息、上市申請信息和審核流程等內容；點擊該記錄【修改】可對申請記錄進行修改，修改后提交，還需進行審核。

2）退市備案

APP退市的原因有多種，包括公司因經營等情況主動選擇下架，或者因為應用市場審查等原因被動下架。

主動下架，則按照應用市場相關流程執行即可。需要注意的是，當APP主動下架時，運營團隊需準備好退出策略、客戶解釋、投訴處理、輿情應對預案和業務遷移方案等資料，避免造成客戶投訴和法律糾紛。被動下架，則要明確下架原因，解決問題修改完成，重新申請在應用市場上架。移動APP退出應用市場后，需在平臺進行報備。

業務流程如下圖：

退市備案提交后，可以在審核管理里查看申請記錄。點擊該記錄【詳情】可查看記錄的APP基本信息、上市申請信息和審核流程等內容；僅申請失敗時，該記錄才顯示【修改】按鈕，點擊【修改】可對申請退市信息進行修改，修改后提交，還需進行審核。

3）版本管理

APP在應用市場上更新版本后，需在平臺上備案。版本管理提供增加APP版本記錄功能，展示各APP版本信息(包括開發者、發布日期、更新日期、Bundel ID版本和APP ID等)、上架狀態（包括各應用市場）、版本記錄（包括各應用市場，主要信息有應用名稱、版本號、更新日期、更新日志、截圖和應用描述）、版本對比(對比類型包括更新日志和應用描述)和版本統計等信息數據，展現APP的版本變化情況。版本記錄如下圖：

2. 數據監測

數據監測是建立在APP指標體系上，使用數據看板（駕駛艙）可視化圖表的展現形式將APP運營等數據呈現出來，并根據指標對APP數據的變化情況進行監督和測量。數據監測主要分為數據采集和數據呈現兩部分。

1）數據采集

APP的數據采集包括外部數據采集和內部數據采集。

1.1 外部數據采集

外部數據指APP上架或更新版本后在應用市場和專業數據平臺的表現。

應用市場主要包括App Store和安卓（主要有華為、小米、VIVO、OPPO、魅族、應用寶、百度、360）?？梢酝ㄟ^各個應用市場采集APP的下載量和安裝量。

專業數據平臺，如易觀數據、百度指數。可以通過專業的數據平臺采集數據，觀測APP熱度。

1.2 內部數據采集

內部數據指APP內的用戶行為數據，例如用戶的點擊數據、行為路徑、流量等，可通過在APP內的埋點來實現。尤其對于新版本中的功能，在設計和開發時，必須要加入對應的埋點，以觀測功能上線后的數據變化，進而進行數據采集驗證和分析，對下一版本的功能規劃將有重要的指導作用。

我們通過把采集到的數據信息(如：華為應用市場下載量)錄入并上傳到后臺數據庫或者調用第三方提供的數據接口。數據報送業務流程如下圖：

2）數據呈現

采集到的APP數據一般可以通過數據看板可視化呈現。數據看板由多個數據圖表組成，通過合理的頁面布局、視覺效果設計來將數據可視化更好的展現。數據看板常用的四類圖表：柱狀圖（或堆積柱狀圖）、折線圖（或曲線）、面積圖和餅圖（或環圖）。數據報表有十幾種報表，幾十個數據指標，但并不是都需要呈現出來的。

用戶可以通過數據看板的數據統計掌握情況，解決問題并匯報工作。不同崗位職責的用戶有不同的需求，我們對內部人員用戶角色進行分析：

業務員：對個人相關的業務負責，關注自身，關注業務細節；業務經理: 對具體業務負責，關注業務看板，關注業務變化趨勢；高管：對公司發展負責，關注核心指標，關注戰略看板，做戰略決策。

數據看板根據展現的位置不同，主要分兩種：大屏幕和非大屏幕，其內容的側重點也不同。

“大屏幕”通常指展示在指揮大廳的大屏幕上的頁面，也是一個系統的核心頁面。一是為了保證第一時間掌握業務現狀；二是中高層對業務數據非常敏感，只用看到數字就能看出業務異常。

數據展現形式以數字內容為主，簡潔明了突出結果。一般設置6個左右的數據指標，有利于專注于分析最重要的指標。

數據時效性上更偏重于實時數據，一般能夠在第一時間預警。視覺效果在動態效果上花費較多的精力，需要對圖表取舍。

我們通過和業務團隊溝通確定了用哪些數據指標和衡量方式等內容。例如：按什么時間段去展示各APP的交易額排名。大屏幕展示如下圖：

“非大屏幕”通常指的是業務模塊中的統計頁面，主要針對系統日常使用中的某一部分的業務指標進行分析。從數據的時效性上展示比較多的是趨勢數據，通過趨勢發現問題、解決問題。非大屏幕展示如下圖：

2.1 數據看板設計步驟

確定需要展示哪幾個區塊，一般設置6個左右，有利于專注于分析最重要的指標；羅列好區塊里需要展示的數據指標、衡量的方式、優先級，哪些歸為一類后；展示在大屏幕的可以由UED/UI設計師完成設計排版布局；非大屏幕的可以使用Axure+echars或Axure圖表元件進行可視化圖表設計。

由于后臺系統不對外開放，僅供內部人員使用，數據看板的設計可較為簡潔。當然像大屏幕的數據看板有UI設計師設計加持，更能突顯大屏幕的重要性，在演示時更能獲得領導的認可。

2.2 數據看板設計要點主要有以下幾點：

簡潔高效，優先滿足圖表展現效率，而不是酷炫的交互；信息需具有強關聯性，例如：用環比、同比來體現變化；數據圖表的刷新頻次和統計頻次需要符合業務的需求，最好能做到實時更新；選用的數據能夠體現出趨勢和規律，對于無趨勢特性的數據，直接展示數字比較好；對于不同的數據指標(例如：下載量、點擊率和活躍人數)，不同的數據特性(例如：波動、對比和排序)，不同的衡量方式(例如：客戶滿意度)選擇合適的圖表類型。

3）權限管理

權限管理是保證監測管理平臺正常運轉的基礎，通過管理各組織機構的層級、各級機構的用戶數量、用戶崗位及對應崗位的角色及責任，實現操作合理分配和管理。

權限管理設計選用基于角色訪問控制(RBAC)模型。RBAC（Role-Bad Access Control）模型主要由Ur用戶、Role角色和Permission權限3個基礎組成部分，遵從三大安全原則：最小權限原則、責任分離原則和數據抽象原則。

最小權限原則：將角色配置成其完成任務所需的最小權限集合。例如：操作查詢崗是APP相關工作申請的發起者及權限范圍內各項數據視圖的查詢者，負責準備各項材料、填寫各項信息并發起工作申請，以及查詢經辦業務或權限范圍內的數據視圖信息。責任分離原則：可以通過調用相互獨立互斥的角色來共同完成敏感的任務。例如：要求金融科技部、法律事務部、公共關系和銀行業務中心四個部門審核崗人員共同參與審查操作。數據抽象原則：可以通過權限的抽象來體現，例如操作查詢崗可用APP上市申請、查詢等抽象權限。

RBAC模型簡化了用戶、角色和權限的關系，便得三者易擴展易維護，雖然沒有提供操作順序的控制機制，但是已滿足現有業務需求。

RBAC模型的權限管理主要包括用戶管理、角色管理和權限管理。根據平臺業務需求，主要給不同部門不同類別的用戶分配不同的角色，不同的角色分配不同的權限。權限配置包括APP權限配置和功能菜單權限配置。因此平臺的權限管理有兩種方案：

自定義角色，對角色分配功能菜單操作權限，對用戶分配APP操作權限。角色分為四種，對角色分配功能菜單操作權限，對用戶分配APP操作權限。

由于業務需求和時間緊迫，我們選擇了方案二，這樣進展比較快，并且后續可以做自定義角色功能拓展。

四、開發測試上線

在開發前，我們對原型進行可用性測試并對原型進行修改。通過可用性測試評審后，申請開發排期，我們采取的是開發一個模塊、測試一個模塊的方式。由于時間緊迫且開發工程師有限，在開發完成一個模塊后，馬上安排測試人員進行相關測試。測試發現Bug后，相關開發工程師立馬修改。

測試通過后，項目于2021年11月底正式上線，第一階段上線APP管理、指標監測和權限管理三大功能模塊，其他四大功能模塊陸續進行開發。

五、后話

APP監測管理平臺項目雖然時間緊任務重，經過團隊成員通力合作按時按質按量完成了任務，并得到甲方的好評并給予團隊獎勵。

現在距離該項目產品設計已經過去一年，復盤時回想當時的情景重新閱讀需求，邊整理邊查資料，發現對過往工作的經歷重新審視也是一種新的學習方式。筆者認為無論做項目多忙，還是要及時復盤，盡快讓經驗知識得以沉淀并系統化積累起來。

2021年10月初，我參與微信小程序監測管理平臺項目，參照該項目并根據產品需求完成產品設計任務。

本文由 @櫻子 原創發布于人人都是產品經理。未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。