惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

I
InfoQ
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Apple Machine Learning Research
Apple Machine Learning Research
月光博客
月光博客
B
Blog
罗磊的独立博客
GbyAI
GbyAI
博客园 - 三生石上(FineUI控件)
雷峰网
雷峰网
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
Microsoft Security Blog
Microsoft Security Blog
宝玉的分享
宝玉的分享
The GitHub Blog
The GitHub Blog
人人都是产品经理
人人都是产品经理
博客园 - Franky
有赞技术团队
有赞技术团队
WordPress大学
WordPress大学
博客园 - 聂微东
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
V
Visual Studio Blog
MyScale Blog
MyScale Blog
Google DeepMind News
Google DeepMind News
G
Google Developers Blog
aimingoo的专栏
aimingoo的专栏

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
复盘 | APP监测管理平台该怎么做?
SerenaL · 2022-06-08 · via 人人都是产品经理

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