编辑导语：数据监测管理平台会根据不同业务的流程和需求做出改变，然而万变不离其宗的原理。本文作者根据工作中的项目实践，并结合经验主要分享从0-1平台产品规划设计中的APP管理、数据监测和权限管理功能设计经验，供大家参考和学习。

2021年4月中旬，J银行为加强对行内几十个移动应用的集中监测管理，搭建APP监测管理平台，实现移动应用集中管理，建立数据指标体系实现数据可视化，通过开展运营数据监测和数据分析，为移动应用运营提供数据支持。甲方领导十分重视该项目，把该项目列为最高优先级别，并给予大力支持。

J银行为了对行内和旗下多个APP进行监测管理而搭建APP监测管理平台，主要包括APP管理，审核管理、运营监测和用户权限管理等功能。该平台作为银行内部后台，注重业务功能操作实用性，便利性，个性化要求不高。目标用户是银行内部平台使用人员，主要包括高管、业务经理和业务员。

项目采用敏捷模式进行，我们和甲方项目负责人一起集中办公，方便沟通和了解项目进展。我们解读需求文档、业务规则，对整体需求业务流程进行梳理，并组织小组讨论。

需求分析过程中，我们对不明确的需求进行小组讨论并和跨地区业务部门(使用小鱼易连)远程视频会议；定期对成果物采用视频会议跨地区跨部门评审。

人力资源有限，需求范围较大（七大模块、24个二级菜单功能），我经过评估，及时向上级申请支援，增派了2名产品经理。在有限的人力资源(团队共6名产品经理)、有限的专业水平（2名初级、3名中级和1高级）和有限的时间经过需求分析、跨部门协同沟通、确认范围、产品设计和部门内部评审等众多环节，完成项目范围全部需求的高清原型设计有些不切实际。

我及时向甲方项目负责人反馈，并建议项目实施范围分两个阶段，现阶段先把项目主要功能模块进行设计实施，第二阶段再增加次要的功能。甲方项目负责人听取了我的建议，并及时向甲方领导汇报，通过缩小第一阶段实施范围的建议，为后继项目任务圆满结束打下坚实的基础。

统筹：我带领团队（共6人）进行监测平台需求分析并统筹使用Axure进行高清原型设计及团队协作原型的版本管理。我们统一字体色调排版，使用元件库制作高清原型。这样我们设计出来的高清度原型，在视觉风格、样式规范(包括字体、按钮、表单和表格等)都得到统一。

培训：我根据以往产品设计经验，首先让团队成员了解需求、熟悉业务流程、搞懂业务逻辑，把业务流程梳理出来，再进行原型设计，并对初级产品经理进行速成Axure技能培训。

经过统筹和培训后，我们开始产品设计，这里主要叙述APP监测管理平台的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的版本变化情况。版本记录如下图：

数据监测是建立在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 数据看板设计步骤

1. 确定需要展示哪几个区块，一般设置6个左右，有利于专注于分析最重要的指标；
2. 罗列好区块里需要展示的数据指标、衡量的方式、优先级，哪些归为一类后；
3. 展示在大屏幕的可以由UED/UI设计师完成设计排版布局；非大屏幕的可以使用Axure+echars或Axure图表元件进行可视化图表设计。

由于后台系统不对外开放，仅供内部人员使用，数据看板的设计可较为简洁。当然像大屏幕的数据看板有UI设计师设计加持，更能突显大屏幕的重要性，在演示时更能获得领导的认可。

2.2 数据看板设计要点主要有以下几点：

1. 简洁高效，优先满足图表展现效率，而不是酷炫的交互；
2. 信息需具有强关联性，例如：用环比、同比来体现变化；
3. 数据图表的刷新频次和统计频次需要符合业务的需求，最好能做到实时更新；
4. 选用的数据能够体现出趋势和规律，对于无趋势特性的数据，直接展示数字比较好；
5. 对于不同的数据指标(例如：下载量、点击率和活跃人数)，不同的数据特性(例如：波动、对比和排序)，不同的衡量方式(例如：客户满意度)选择合适的图表类型。

3）权限管理

权限管理是保证监测管理平台正常运转的基础，通过管理各组织机构的层级、各级机构的用户数量、用户岗位及对应岗位的角色及责任，实现操作合理分配和管理。

权限管理设计选用基于角色访问控制(RBAC)模型。RBAC（Role-Based Access Control）模型主要由User用户、Role角色和Permission权限3个基础组成部分，遵从三大安全原则：最小权限原则、责任分离原则和数据抽象原则。

1. 最小权限原则：将角色配置成其完成任务所需的最小权限集合。例如：操作查询岗是APP相关工作申请的发起者及权限范围内各项数据视图的查询者，负责准备各项材料、填写各项信息并发起工作申请，以及查询经办业务或权限范围内的数据视图信息。
2. 责任分离原则：可以通过调用相互独立互斥的角色来共同完成敏感的任务。例如：要求金融科技部、法律事务部、公共关系和银行业务中心四个部门审核岗人员共同参与审查操作。
3. 数据抽象原则：可以通过权限的抽象来体现，例如操作查询岗可用APP上市申请、查询等抽象权限。

RBAC模型简化了用户、角色和权限的关系，便得三者易扩展易维护，虽然没有提供操作顺序的控制机制，但是已满足现有业务需求。

RBAC模型的权限管理主要包括用户管理、角色管理和权限管理。根据平台业务需求，主要给不同部门不同类别的用户分配不同的角色，不同的角色分配不同的权限。权限配置包括APP权限配置和功能菜单权限配置。因此平台的权限管理有两种方案：

1. 自定义角色，对角色分配功能菜单操作权限，对用户分配APP操作权限。
2. 角色分为四种，对角色分配功能菜单操作权限，对用户分配APP操作权限。

由于业务需求和时间紧迫，我们选择了方案二，这样进展比较快，并且后续可以做自定义角色功能拓展。

在开发前，我们对原型进行可用性测试并对原型进行修改。通过可用性测试评审后，申请开发排期，我们采取的是开发一个模块、测试一个模块的方式。由于时间紧迫且开发工程师有限，在开发完成一个模块后，马上安排测试人员进行相关测试。测试发现Bug后，相关开发工程师立马修改。

测试通过后，项目于2021年11月底正式上线，第一阶段上线APP管理、指标监测和权限管理三大功能模块，其他四大功能模块陆续进行开发。

APP监测管理平台项目虽然时间紧任务重，经过团队成员通力合作按时按质按量完成了任务，并得到甲方的好评并给予团队奖励。

现在距离该项目产品设计已经过去一年，复盘时回想当时的情景重新阅读需求，边整理边查资料，发现对过往工作的经历重新审视也是一种新的学习方式。笔者认为无论做项目多忙，还是要及时复盘，尽快让经验知识得以沉淀并系统化积累起来。

2021年10月初，我参与微信小程序监测管理平台项目，参照该项目并根据产品需求完成产品设计任务。

本文由 @樱子 原创发布于人人都是产品经理。未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。