复盘 | APP监测管理平台该怎么做?

2 评论 4406 浏览 19 收藏 18 分钟

编辑导语:数据监测管理平台会根据不同业务的流程和需求做出改变,然而万变不离其宗的原理。本文作者根据工作中的项目实践,并结合经验主要分享从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 数据看板设计步骤

  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协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我很想了解下这个项目,不知道是否方便联系下,电话13857142284.

    来自浙江 回复
  2. 数据展现就要做到形式以数字内容为主,简洁明了突出结果

    回复