数据服务管理产品设计思路【产品设计篇】.docxVIP

数据服务管理产品设计思路 摘要：做好数据服务管理，有助于数据价值的有效输出，提升业务效率，并助推决策的产生。这就要求数据产品经理想办法解决数据服务管理平台当下存在的一些问题，比如管理困难、权责不明等。本篇文章里，作者就数据服务的痛点、如何搭建好数据服务管理平台等方面做了总结，不妨来看一下。 数据的价值一个是数据驱动决策，主要通过数据可视化平台、自助BI分析工具提升决策分析效率。另一个是数据在业务端的创新应用，主要是API接口服务的方式，即DAAS（dataAPI as aservice）。 数据化运营时代，对API接口的需求与日俱增。例如APP首页的千人千面的个性化推荐接口，根据用户历史消费订单数实时弹屏新客大礼包，根据访问用户所处的生命周期，制定差异化的用户激励运营策略等。 你们公司，目前是如何构建和管理数据API服务的呢？ 一、数据服务的痛点 1. 接口开发流程长 通常一个普通API接口的开发，需要数据开发工程师将数据按照业务逻辑进行清洗加工，再由Java开发人员进行接口变现，即可以让业务端通过接口调用数据，例如实时查询当前访问用户的历史累计订单数，以判断用户是新客，进而派发新客大礼包。 对于个性化推荐接口，算法人员基于数仓模型进行特征数据分析处理，模型开发、训练调优，然后将模型提供给接口开发人员进行实时的推理服务。 不管是哪种形式的接口，都会涉及多个工种，经过N个环节，一个接口的上线周期至少以周为单位，这个时效对于业务端创新应用的支撑是远远不够的。 2. 开发人员稳定性差 对于普通的API接口，Java开发可能只需要按照接口文档约定的出入参格式进行SQL查询语句的封装再做一些性能调优就可以了，考虑接口性能问题多数逻辑都会在数据模型层处理好。 这种需求对于开发人员来说个人成就感是比较低的，看似每天都在忙，忙碌但缺少成功的输出。有更追求的开发不会愿意长期做接口变现，接口开发团队的人员稳定性是个问题。 3. 数据服务管理困难 对外输出的API接口太多，随着人员的离职更替，历史接口的逻辑、业务端的应用情况管理成了老大难的问题，因为找不到接口调用方，难以判断接口的应用场景，接口数量只增不减。 长期以来，需要维护的接口数量越来越多，服务器成本、运维成本都居高不下。 4. 接口问题权责不明 “不知道接口有谁在用”，这是经常听到接口开发讲的一句话，他们也很委屈，因为接口是四五年前开发的，前任并没有交接的那么详细。 即使通过接口可用性监控发现了服务异常，也没办法逐一地找到并通知应用方。只能被动地等着业务来反馈。甚至连监控都没有，时不时收到业务反馈说，这个接口是不是你们负责的，出了XX问题，你们排查一下。 因为服务以接口输出，接口出问题一般会直接找接口开发，接口开发通过翻代码发现是数据问题，又找到数据开发进行逻辑确认，“数据问题，我没法排查”，会出现相互推诿的情况。 二、数据服务管理平台的解决思路 数据中台的核心思想是能力复用和数据应用效率的提升，资产是数据中台的核心，没有资产的数据中台只能叫数据平台或工具。 因此，数据服务管理必须建立在数据资产层之上。数据资产层以OneData为方法论基础进行模型、指标的建设，构建分级分类清晰的数据资产管理与治理体系。 数据服务层作为数据中台价值输出的最后一公里，数据服务管理效率的高低，直接影响数据中台价值的体现，它提供的核心解决思路是复用资产层的数据能力，通过平台化、配置化的方式，快速生成API服务，减少定制化开发对不同工种的依赖。数据服务管理平台需要具备以下核心的能力： 1. 接口服务配置化 1）指标类接口 一般输出给定制化开发的可视化报表平台或业务端后台进行数据效果分析，指标类基本都可以抽象出来指标+维度+限定条件的方式，即：指标和数据模型绑定，从哪个表中取哪个字段，字段的聚合逻辑是什么，指标支持的分析维度有哪些？ 前端页面调用时，传入指标ID、限制条件参数，即可返回数值。指标管理平台处理管理统一指标外，还需要支持指标接口的服务化输出，这样针对定制化程度高、BI工具无法配置的可视化需求，如大屏可视化，只需要数据开发人员清洗好指标数据后，进行配置即可输出，无需接口开发介入。 2）用户或商品维度的接口 归根到底也可以归为指标类接口，但是由于数据的维度聚焦于单个用户或者商品，应用场景主要是精细化运营或产品智能，因此在场景配置方面需要一定的差异化。 承接的载体主要是CDP（客户数据平台）、画像平台等。在资产建设部分，讲用户画像、商品画像体系标签化，通过丰富的标签构建用户、商品的精细化分层能力。 例如北京环球度假区开业业务想借热点拉新（首次消费），于是通过用户标签和商品资源标签，找到了需要找到近期有旅游计划，目的是北京，曾经购买过迪士尼乐园等主题的景点的年轻用户，当符合条件的用户进入APP首页，进行促销红包弹