中国农业银行移动应用数据采集分析平台项目技术需求说明书.docx

1、中国农业银行移动应用数据采集分析平台项目技术需求说明书中国农业银行移动应用数据采集分析平台采购项目技术与服务资源技术需求说明书编制单位：软件开发中心应用开发三部、应用开发七部编制日期： 2016年6月22日 1. 总则本需求说明书是中国农业银行移动应用数据采集分析平台的主要技术要求，供各投标人编写方案建议书之用。根据本需求说明书要求，各投标人应提出技术解决方案，提供部署产品的参考方案，并提供完整的服务说明。文档所述技术及服务要求分为刚性条款和非刚性条款，“刚性条款”章节前以*标注，其它条款默认为“非刚性条款”。刚性条款为本次投标必须满足的刚性条件，任何不满足刚性条款的投标产品及服务将视为不合格

2、投标文件。2. 项目整体情况说明2.1. 项目背景随着智能手机的日益普及，移动互联网作为信息产业发展最重要的领域之一，不断推动着整个产业形态、商业模式的巨大变革。移动应用作为智能终端，将互联网与人们的连接变得更加紧密。移动应用正成为一个人们与互联网进行双向互动的媒介。用户在使用App时，应用是否运行稳定？做了哪些操作？哪个功能用户使用率最高？产品人员和开发人员都无从得知。在这种情况下，监测移动App的性能，抓取移动App上用户的行为变得至关重要。只有得到App的相关数据，产品经理和开发人员才能不断提升产品性能，优化用户体验。可以断言，采集移动App相关数据，对服务现有用户，拓展新增客户能够起到

3、巨大的推动作用。目前，充分利用App运行产生的相关数据已成为各行业领域的核心竞争力之一。基于移动App的用户行为数据采集与应用性能监测成为一个不可或缺的基础系统。用户正常使用应用产生的相关数据，经过分析与处理，会为产品自身的不断改进与完善提供更好的数据支撑。因此，建设App用户行为数据采集与应用性能监测系统，可以帮助我行不断改进客户体验，在更加全面，更加细致的收集，分析客户数据的基础上细分客户，增加产品与客户需求的契合度，全面提升我行移动金融产品的竞争力。2.2. 项目目标通过将我行各类移动金融产品如手机银行等应用，接入到App用户行为数据采集分析与应用性能监测系统，通过采集、分析移动端用户行

4、为数据, 为移动产品的开发人员以及业务人员提供如下能力：（1）应用趋势分析，展现应用的新增用户，启动次数，活跃用户，版本分布等指标数据，从整体掌握应用的运营情况及增长动态。（2）行为分析，了解用户使用细节，帮助寻找产品改进突破点，评估产品优化效果。（3）渠道分析，通过对渠道新增用户，活跃用户等指标数据，评估不同渠道的用户质量与活跃程度，从而达到衡量推广效果的目的。（4）留存分析，通过日/周/月留存用户分析，了解产品和用户质量的好坏。（5）用户属性分析，通过用户基本属性特征，比如设备型号，网络等，全面了解用户。（6）转化率，通过对核心业务流程中的关键步骤进行统计，可以了解用户在某个步骤的流失情况

5、。（7）错误分析，收集归类错误日志，帮助移动产品开发人员更好的发现解决问题，从而提高应用的稳定性，提升应用质量。（8）应用对比分析，可以对不同应用或者同一个应用不同系统的数据进行全面的对比分析。（9）应用性能监测，收集App应用ANR、闪退等性能相关数据，帮助开发人员提升应用稳定性。2.3. 项目采购内容序号资源项模块名数量备注1移动APP数据采集分析平台采集插件1套支持主流IOS和android平台，采集用户行为和APP运行数据，农行内不限装机量数据收集服务20000TPS，支持对采集数据进行定制。数据分析数据总量达300T，日新增数量达到1T的情况下系统正常稳定运行，相关分析任务不超过12

6、小时公共管理提供公共管理和报表展现2客户化开发18人月平台的客户化改造，和我行相关系统对接，按照实现目标交付3维保服务3年包括平台的技术培训、技术支持、平台软件的缺陷修复和客户端插件升级3. 服务商资质要求3.1. *基本资质1. 服务商应为在中华人民共和国境内合法注册的独立法人。2. 服务商服务信誉良好，近五年内未与农行系统发生过诉讼争议。3. 服务商需为原厂商。4. 应标产品具备独立的软件著作权。5. 服务商应标产品需具备成熟案例，需提供正式证明文件。3.2. 增强要求1. 服务商注册资金为人民币5000万元（含以上）。2. 应标产品具备四大行实施案例，需提供正式证明文件。3. 应标产品通

7、过国家级第三方权威机构评测，并提供测试报告。4. 软件产品需求说明近年，移动App应用蓬勃发展，我行移动端客户亦迅速增长。通过对移动App数据进行采集，分析能够为我行移动应用产品运营提供数据支撑。本采购工作主要包含用户行为采集插件、性能监测采集插件、采集服务模块、用户行为分析模块、性能监测分析模块、农行定制化服务、后续维保服务构成。相关插件及模块需要支持IPhone、Andriod等常见版本终端。此外，结合我行大数据平台建设情况，App用户行为采集分析与应用性能监测系统采购工作要求，采购的相关模块及功能兼容我行现有大数据平台，业内主流技术及标准。4.1. *采集插件需求客户端数据采集组件通过静

8、态库方式集成到移动应用中，使得应用具备移动端设备指纹捕获、运行状况监测、用户行为记录、异常错误报告等能力，并能够将采集到的数据以合理的方式上传到服务器。整体过程对用户透明，不牺牲用户体验。产品还需具备对移动APP进行运行性能监测、数据采集、上传、统计、分析诊断的能力。具体包括APP运行异常（如无法安装、无法启动、假死、黑屏、卡顿、闪退等）、慢交互（如启动时间过长、某界面加载时间过长等）、网络异常（如网络拥堵、大面积断网等）、流量消耗、电量消耗等。4.1.1. 多平台部署需求客户端数据采集组件需要支持IOS、Android（含定制版）平台，供应商应提供基于这些平台的软件开发包（SDK）。4.1.

9、2. 数据采集需求客户度组件必须具备采集所有可访问数据的能力，包括但不限于以下类型： 移动设备信息：包括设备型号、设备序列号、操作系统、屏幕分辨率、移动运营商、联网方式、IP地址、MAC地址等。 用户使用习惯：包括启动时间、使用时长、启动频率、分时段趋势、页面访问路径、页面驻留时间等。 自定义事件：包括触发时间、触发次数、触发频率、触发路径、事件转化率等。 运行错误报告：包括发生错误时的App版本信息、App运行环境、驻留页面、用户行为路径等。 应用运行状况：包括版本分布、新增用户、活跃用户、累计用户、用户留存率、用户活跃度等。 APP运行异常：当集成了该产品的APP在出现运行异常（如无法安装

10、、无法启动、假死、闪退等）时，须记录下发生该问题时的相关辅助信息，包括但不限于设备硬件信息（手机品牌、型号、操作系统版本）、网络状态、设备上已安装的其它应用的状况、APP自身的相关信息（版本号、发生异常时的上下文信息（如堆栈、出问题的代码类和行数）等有助于分析诊断问题的所有参数。 APP慢交互：产品需具备识别出慢交互页面的能力，当APP出现慢交互的现象时，产品需记录下请求的平均响应时间，并将采集的数据上传至后台，分析并展现。 网络异常：产品应能够识别大规模断网、网络大面积拥堵、或用户网络被劫持等异常情况，并能够通过人工或者后台自动预警的方式通知给行方，以便启动相关应急预案。 流量消耗监测：产品

11、应能记录并上传APP在前后台运行时所消耗掉的用户网络流量情况，以及手机上安装的其它应用的流量消耗情况。 电量消耗监测：产品应能记录并上传APP在前后台运行时所消耗掉的用户手机电量情况及关联因素如CPU、内存等管理情况。4.1.3. 数据存储需求客户端组件能够将采集到的数据加密并存储在移动设备本地，并能够及时清理已上传数据、过期数据以释放应用存储空间。4.1.4. 数据上传需求在不牺牲用户体验的情况下，客户端组件能够根据可及时调整的策略将数据压缩上传到服务端，上传策略包括但不限于： 实时上传 定时上传 闲时上传 压缩上传4.1.5. 采集插件性能需求客户端数据采集组件的运作不能影响移动应用的用户

12、体验，运行情况必须对用户不可见，尽量以子线程后台运行的方式采集、存储、上传数据。4.1.6. 数据采集兼容性需求客户端数据采集组件须兼容主流的移动设备：包括手机、平板、手表等。客户端数据采集组件需兼容移动APP相关辅助工具：如android加固软件。客户端数据采集组件在各个移动平台必须兼容的系统版本分别是： IOS 6.0 及以上 Android 2.3 及以上4.2. *数据收集服务模块4.2.1. 定制数据采集指标支持系统使用者，自定义数据指标，完成数据采集工作。4.2.2. 采集数据管理支持“0”动埋点和可视化埋点配置管理；针对采集到的数据，进行管理，包括具体数据指标的增删改查。4.2.

13、3. 采集数据治理针对采集到的数据，对异常数据进行治理，以保证数据质量；对采集到的数据最终需转换成jason格式。4.3. *数据分析模块需求4.3.1. 数据扩展系统需具备成熟的数据扩展能力，可以快速响应业务数据的变化和扩展。4.3.2. 算法支持支持主流的数据分析算法，如聚类、分类、回归等。4.3.3. 分析引擎系统需具备成熟的非结构化数据的分析引擎，可以快速响应规则的变化，分析引擎可根据甲方需求进行灵活的配置。4.3.4. 行为分析功能4.3.4.1. 用户行为趋势统计功能应用趋势分析，支持主要包含但不限于展现应用的新增用户、启动次数、活跃用户、版本分布等指标数据，从整体掌握应用的运营情

14、况及增长动态。主要包含新增用户、启动次数、活跃用户、累计用户、平均使用时长的趋势分析，以及相关指标在不同版本，不同渠道的趋势。4.3.4.2. 用户行为统计功能用户行为分析，支持主要包含但不限于用户的使用频率、使用时长、分时段趋势、页面访问与路径、地域分析、用户数据查询、日登录用户数、日交易用户数。可支持通过多维度（不同的业务维度和时间维度）的留存分析统计功能。4.3.4.3. 对比分析功能应用对比分析，可以对不同应用或者同一个应用不同系统的数据进行全面的对比分析，可针对不同应用的设备型号，操作系统，分辨率，运营商，联网方式，在新增用户与启动次数两个维度进行对比分析。4.3.4.4. 转化率分

15、析功能可配置基于事件的转化率对比分析，可针对自定义事件进行转化率分析，可建立完善的漏洞模型。4.3.5. APP性能分析功能4.3.5.1. APP运行异常分析能够按照运行异常的分类（如无法安装、无法启动、假死、闪退），分别展示出现问题的用户、设备、应用全面的属性信息，收集并展现问题出现时的上下文信息（如堆栈），并定位出可能导致问题的代码段及位置。需统计出某一时刻出现运行异常的用户情况、设备情况、应用情况，并按照年月日等时间维度、地域、设备、应用版本等进行趋势分析和对比。错误分析（版本）展示了时间段内不同应用版本错误数量，以及分类显示错误详细，以及错误数与启动次数的对比。针对某类错误，展示错误

16、详细与所有明细数据，以及在不同设备与操作系统中的分布情况。错误分析（OS）展示了时间段内不同设备系统版本错误数量，以及分类显示错误详细，以及错误数与启动次数的对比。针对某类错误，展示错误详细与所有明细数据，以及在不同设备与操作系统中的分布情况。错误分析（设备）展示了时间段内不同设备错误数量，以及分类显示错误详细，以及错误数与启动次数的对比。针对某类错误，展示错误详细与所有明细数据，以及在不同设备与操作系统中的分布情况。4.3.5.2. 慢交互展现与分析当检测到用户手机APP出现慢交互现象时，产品需识别并定位出导致慢交互的具体页面，并进行展现分析。4.3.5.3. 网络异常分析需根据采集插件的运

17、行状况，识别出网络异常（如区域断网、用户网络被劫持等），并在后台进行实时展现、统计，大面积断网或网络拥堵时，需给运营管理人员预警提示。4.3.5.4. 流量消耗统计分析需按照年、月、日、小时，累计、平均等维度在管理端以可视化的方式展现用户手机上应用自身的流量消耗情况，并提供流量消耗较多的网络请求的页面、交互地址等信息。4.3.5.5. 电量消耗统计分析需按照年、月、日、小时，累计、平均等维度在管理端以可视化的方式展现用户手机上应用自身的电量消耗情况，如CPU、内存、网络等，并提供电量消耗较多的操作、页面、网络请求、后台服务等技术信息。4.4. 公共管理模块需求4.4.1. 图形化展现与查询前端

18、采集上传的性能相关数据，在服务端需能够按类别、设备、用户、时间、地域等要素分别进行图形化展现，并提供给运营管理者查询、筛选等功能。4.4.2. 系统管理系统管理模块主要完成基本信息的管理与配置，包含应用管理，渠道管理，用户管理，角色管理，运行监控，数据报警几部分。4.4.2.1. 应用管理应用管理是系统的基础，主要完成应用的新建，修改，删除。用户在集成一个APP前，第一步首先要在系统中新建一个APP应用，系统会针对每个应用的不同渠道分配一个AppKey作为此应用在此渠道的唯一标识。4.4.2.2. *业务监控运行监控主要是针对系统运行的分析任务进行监控，可以让管理员清晰的了解任务的运行状况。4

19、.4.3. 角色管理角色管理主要包含系统角色的创建，删除以及角色所对应的权限的分配。通过角色权限的分配，可以为不同用户分配不同的功能权限。4.4.3.1. 用户管理用户管理负责维护系统内的用户，包括新建系统用户，编辑用户信息，修改用户角色，以及为某个用户指定产品访问权限。通过对用户指定产品的访问权限，可以控制不同产品的运营人员的访问权限。4.4.4. *系统监控可提供独立的系统监控模块，对各系统模块的运行情况进行监控，对于预警情况可进行邮件、短信等相关报警4.5. *软件产品非功能要求4.5.1. 兼容性要求采集插件需支持IOS 6.0、Android 2.3及以上版本（含定制化版本）。采集插

20、件兼容主流移动app软件。4.5.2. 性能要求数据收集服务需满足不低于4000万日活跃用户的数据上报，日接收数据能力不低于5亿条，采集服务最大并发处理能力不低于20000TPS。分析模块，应满足数据总量不低于200T，日新增数量达到1T的情况下系统正常稳定运行，相关分析任务不超过12小时。4.5.3. 可靠性要求系统支持7*24小时稳定运行。系统支持集群部署，当单节点出现故障时不会造成数据丢失和业务中断。系统各模块可独立升级维护。4.5.4. 数据采集安全性需求客户端组件必须提供源码。客户端数据采集组件不得篡改被集成应用的数据、不得采集其他应用的数据、不得与行外服务器通信、不得执行除数据采集

21、、存储、上传以外的任何任务，不得执行侵犯用户权益、农行权益的任何任务。4.6. *软件产品许可权要求甲方所购软件产品在农行范围内不限安装部署地点，不限使用时间和使用期限。软件产品如使用到的第三方工具和数据，相关授权及使用费用由乙方负责，并随软件产品一并提供。软件产品需对甲方提供全部源代码，包括IOS、Android的客户端SDK组件、服务端管理模块、定制化等。甲方拥有对源码的查看审计权、修改维护权、行内相关项目使用权。5. *客户化开发需求说明客户化开发服务以实际发生的工作量计算，若实际工作量少于计划工作量，甲方按照实际使用的合作开发服务工作量支付相应的服务费用。若为了完成5.1节列出的已明确

22、功能需求使得实际工作量多于计划工作量，则超出部分由乙方免费提供，甲方不予支付。供应商需在甲方明确需求后3个月内完成客户化改造工作。5.1. 客户化开发开发功能要求1、客户端插件客户化改造：包括IOS和Android客户端插件的改造和农行相关APP适配。2、数据收集服务客户化改造：针对农行可采集数据和清洗规则进行适应性改造。3、数据分析客户化改造：支持农行业务数据及相关分析规则指标改造。4、公共管理客户化改造：针对农行管理要求进行管理功能适应性改造。5、基础平台客户化改造：支持农行提供的基础运行平台。支持并兼容主流hadoop平台架构；支持oracle、mysql等主流数据库；可支持农行应用操作

23、系统，如：SUSE LINUX 、windows server。5.2. 工作量及交付时间要求工作内容工作量/人月交付时间客户端插件客户化改造4T+1月数据收集服务客户化改造2T+1月数据分析客户化改造4T+3月公共管理客户化改造4T+3月基础平台客户化改造4T+3月5.3. 开发工具及开发语言要求平台开发工具开发语言IOSXCodeObjective-CAndroidEclipseJava5.4. 对交付件的要求1. 客户化代码需提交源码及目标码，代码规范简介，需经过完整的测试。2. 提交客户化相关的各类设计、测试、手册等文档，文档需格式规范、简介、易读。6. 维保服务要求6.1. 维保时间

24、要求：供应商提供本系统三年期维保服务，维保服务自乙方完成客户化改造，双方签署到货验收报告和安装运行验收报告(客户化阶段)之日起计算。6.2. 维保服务组织要求成立针对农行项目运营维护的技术支持团队、确定固定联系人，制定明确、清晰的运营维护流程，及时解决系统运行过程出现的问题，保证平台的平稳运行6.3. 维保服务人员资质要求乙方应成立针对农行的运营维护队伍，熟悉移动应用软件使用及常见故障处理技术，如由于原因确需调整的乙方需向甲方提出变更申请，经甲方确认后调换。6.3.1. 维保服务内容6.3.1.1. 远程技术服务要求远程技术支持服务需求：在维保期内，厂商或供应商须提供无事件限制的7*24电话和

25、Email技术支持服务，对远程无法解决的问题须提供必要的现场技术支持，直至问题解决；6.3.1.2. 现场技术服务要求紧急现场技术支持服务需求：现场服务地点包括北京，紧急现场技术支持服务内容包括但不限于系统性能分析优化、系统故障诊断分析排除、遗留问题解决等，其中响应方式及时间按照故障级别要求如下：故障级别定义要求响应方式非常严重1. 全部业务或关键业务受到灾难性影响；2. 由于软件原因可能会对农行声誉造成重大影响的故障；1. 运维人员10分钟内响应，并着手分析问题；2. 运维人员在2小时内到达指定服务地点；3. 提交应急恢复方案，确保在4小时内恢复业务正常开展；4. 按724持续努力，至问题解

26、决；5. 进行问题根源性分析；严重1. 部分业务受严重影响；2. 服务严重受损或严重降级；1. 运维人员10分钟内响应，并着手分析问题；2. 运维人员在4小时内到达指定服务地点；3. 提交应急恢复方案，确保在6小时内恢复业务正常开展；4. 按724 持续努力，至问题解决。5. 进行问题根源性分析；一般1. 服务中度受损或中度降级，在受影响的情况下工作仍能合理继续2. 只对极小部分客户/用户产生影响的故障1. 运维人员20分钟内响应，并着手分析问题2. 提交恢复方案，6小时内提交紧急生产变更，恢复业务正常开展；3. 进行问题根源性分析；较小1. 业务受最小程度的影响 2. 实质上正常进行，对服务

27、仅造成微小障碍或无障碍1. 运维人员20分钟内响应，并着手分析问题2. 提交恢复方案，24小时内恢复业务正常开展6.3.1.3. 缺陷修复及 升级服务要求服务商提供本次采购软件产品的补丁和版本升级服务，及时将已知产品存在的缺陷和升级要求等信息通知甲方，对于关键的补丁及升级版本，厂商或供应商应在其发布一周内制定相应的升级计划并提供现场实施支持，包括但不限于： 客户端采集插件升级，以适应最新的手机机型 系统bug修正； 供应商提起的软件版本升级； 甲方系统的功能调整，但新交易与现有交易差别较小的适应性改造。6.3.1.4. 定期巡检服务要求巡检服务要求：乙方需提供每季度一次的巡检服务，对系统运行环

28、境进行健康检查，提出潜在问题解决方案，解决遗留的技术问题。6.3.1.5. 培训服务要求乙方需提供产品的技术和业务知识相关培训服务；6.3.1.6. 特殊时点服务要求乙方提供春节、国庆以及其他重要节假日或重要活动期间的支持或系统职守服务，保障系统的稳定运行。7. 知识转移要求7.1.1. 软件产品文档转移要求软件产品技术文档要求：开发方法、设计文档、应用规范、术语说明、命名规范、信息安全规范、软件设计文档、软件开发方法、软件质量管理标准、数据库设计规范、编程规范、应用接口规范等相关技术文档；7.1.2. 技术服务文档转移要求供应商须向甲方转移的技术服务文档包含但不限于下列内容：业务需求以及业务

29、流程说明文档、整体实施架构设计文档、概要设计文档资料、标准版本程序设计文档、特色客户化程序设计文档、单元测试报告、集成测试报告、用户使用手册、系统安装手册、系统维护手册、系统应急操作手册等。7.1.3. 源码转移要求要求供应商的所有开发代码需纳入我行版本库统一管理，测试和投产环境的所有目标码需通过版本库统一生成并测试，经验收测试完成后的源码版本再执行上线流程，验收源码作为付款条件。7.1.4. 业务、技术技能转移要求要求供应商通过培训等方式实现业务及技术技能的转移，转移内容包含但不限于：软件开发生命周期方法、软件工程方法、开发语言及工具的使用、相关中间件的使用等、客户化开发等；7.1.5. 系

30、统维护技能转移要求供应商通过培训以及其他供应商认为合适的方式实现项目集成、实施、应用维护等方面的技能转移。技能转移内容包含但不限于：项目管理、整体实施架构设计、质量控制、集成测试、用户验收测试、产品投产流程、日常运行维护、出错的处理及解决、数据备份与恢复等；7.1.6. 技术转移计划要求要求供应商按照项目实施计划分阶段说明技术转移内容和方式。8. 服务质量考核和验收为保证项目顺利开展，严格控制项目进度，及时发现解决潜在实施风险，需按照项目研发进度，合理划分项目研发阶段，对各阶段验收内容和服务提交物进行明确，分阶段对服务商服务质量进行考核和验收。8.1.1. 验收阶段及考核内容验收阶段验收内容交付物考核内容软件产品到货阶段对采购的软件产品功能、性能、介质、许可证等相关材料进行验收介质许可证文件其他材料详见到货验收报告客户化开发阶段对阶段性研发目标进行考核验收服务人员工作周报项目需求分析说明书概要设计报告详细设计报告项目源码详见安装运行验收报告(客户化阶段)服务质量考核验收评价打分表（研发阶段）试运行阶段对项目试运行情况进行验收服务人员工作周报单元测试报告集成测试报告试运行情况报告应用系统配置说明书、应用系统开发总结用户手册操作手册维护手册详见供应商监督考核评价打分表（安装运行/稳定运行 个月阶段）；供应商监督考核评价报告维保服务阶段对阶段性维保服务质量进行验收技术支持服务登记表