作者介绍
一个工具人
喜欢做数据平台
喜欢和业务打交道，持续学习
数据产品价值：为解决业务问题而存在
不管什么样的产品，都是为了解决业务问题而存在，数据产品也不例外。数据产品，种类繁多，不同数据产品，所具有的数据功能组件不同。（对应的产品经理积累的技能也有差别，后面会写）
为什么说是不同的数据产品呢？数据产品不就是报表吗？
数据产品分类：面向人群、使用场景、使用方法构成数据产品
数据面向人群不同，人群对数据的诉求不同，有些是取数，有些是分析。取数需要用SQL，分析需要用excel，不同人群的数据诉求，使用方法构成了数据产品。
面向人群可以分为TOB／TOC，可分为付费人群／免费人群。人群的使用方法可分为工具类／咨询类。对于大企业来说，数据产品大多自建，对于小企业来说，大多市场购买。
以上分类过于抽象，下面就实际案例详解数据产品（本文所讲仅为个人积累，才疏学浅，还望大家见谅）
TO B：外部购买-面向运营
TOB是指面向企业经营管理者，举个例子，今天我想在京东上买牙膏，在一顿操作猛如虎后，筛到了牙膏，下单，静等快递小哥上门。牙膏厂商想知道自己最近的经营状况，TOB指商家对店铺经营信息的管理，即企业经营者的看数据诉求。
TOB数据的特点，数据量大、分散、数据关系复杂多变，业务场景决定数据关系。举例，我买LG的牙膏，我们来说说LG公司经营者看数据场景，首先我们来看看有什么样的业务数据，业务数据也可以叫事实数据，未经过任何处理及加工的原子数据。
业务数据1：SKU，例如250ML甜橙味的牙膏、500ML海盐味的牙膏…等有上千
业务数据2：订单量，例如250ML甜橙味的牙膏下单量，成交量，下单时间
业务数据3：收益金额，例如250ML甜橙味的牙膏实际收到现金，优惠券金额
业务数据4：库存数量，例如250ML甜橙味的牙膏剩余多少
……
接下来来看看数据分析场景
场景1：250ML甜橙味的牙膏在最近一个月内的成交量、下单金额、实际收入
场景2：250ML甜橙味的牙膏在最近一年内的成交量、下单金额、实际收入
场景3：一年内250ML甜橙味的牙膏毛利润是多少
场景4：根据月度库存、季度库存、年度库存，判断250ML甜橙味的牙膏是否需要仓库补货，明年预计能给公司带来多大的收入
场景5：250ML甜橙味的牙膏都适用过哪些优惠券，是组合销售比较好，还是单独售出比较好
场景6: 250ML甜橙味的牙膏适用于男士还是女士，人群年龄阶段，人群是否具有区域特征
场景7：250ML甜橙味的牙膏、与500ML甜橙味的牙膏做比较，是否具有竞争力
等等……
维度包含：
时段：月／季／年；
SKU：250ml/500ml/；
活动类型：单独销售／组合销售，
人群标签：男／女；年龄；区域
指标包含：
成交量、下单金额、实际收入、库存剩余
以上问题单以一个SKU举例说明，业务数据1-4只能满足我的部分分析场景，要分析还需要更多业务数据。此例子说明经营者需要从各个维度去看数据，找寻业务的发力点，每个业务都相互独立，且可以构成联系。
面对多变的分析诉求，庞大的数据量，分散的业务数据，老办法，运营人员会将最明细业务数据导入到excel中，透视，vlookup解决上述分析问题。随着分析的点增多，excel需要的明细数据也越多，Excel遇到数据源更新，关系改动，最终excel崩了。
以上案例是指没有能力自己搭建数据仓库数据产品，用excel进行数据分分析的企业经营者
基于这种背景产生了企业需要去外部市场购买数据产品。目前业内比较出名的有阿里的QuickBI，微软的PowerBI，tableau等，这种数据产品为不能搭建数据体系的用户提供了帮助，从ODS到DWD到APP，将数据仓的搭建交由用户自己负责（下图的数据源介入，数据关联）。下图是QuickBI的数据功能组件。
https://www.aliyun.com/product/bigdata/bi
抽象了excel的一部分能力，只要人员懂业务，就可以上手分析数据，不需要组建数据团队，再去维护数据
TO B：企业自建-面向运营/产品
以上例子是TOB˙中外部采买数据产品的例子。产品的弊端在于需要把原子态的业务数据上传到对方服务器中，虽然说平台保证数据安全，但是互联网的大企业还是不相信。在人力资源够用的情况下，公司出于数据安全的角度，还是自己玩吧。
举例说一下我现在的业务。
业务背景：58同城APP，面对市场上新增用户有限，需要去其他APP换取新用户。
业务目标：拉新、促活、直接触达用户，
业务动作：筛选非58的APP投放APP下载、APP调起、服务信息直投，
业务挑战：各业务部门预算有限，流量多种多样，花好每一份预算，即好钢用在刀刃。
内部的数据产品是围绕业务去做的，数据需要跟随业务的变动而变动，跟上业务且领先于业务是内部数据产品的衡量标准。这种数据产品形态上主要以报表为主，且分不同的业务模块；可视化为辅，定向一些指标观测数据；监控内容打野，随时保证业务健康。
此类数据产品坑多在于业务口径，业务的前瞻性，数据的前瞻性，决定了数据的稳定性。业务的抽象能力、逻辑思维能力，决定产品形态的稳定性。如果做不到，天天就会被业务吊打，掉入查数姑和大表哥的坑。
（下一节会展开讲以分析的思路去做数据产品）
刚刚用自己的业务大概介绍了面向运营或者产品的企业自建数据平台，核心逻辑是跟上业务的步伐
TO B：企业自建-面向开发
对比于quickBI是不是发现少了什么东西呢？数据清洗，数据加工功能在哪里呢？当然我们有自己的数据仓库，加工和清洗也都在我们自己的数仓中消化。
58的slogan，“人人信赖的生活服务平台”，6个业务线上千种类目，你的所有需求都能在58平台上满足，难道我们自己的数据仓库是直接对接的58这么多的类目吗？显然不是的。在58内部数据还有更细的分工。
举例：部门的业务目标ROI>1,尽可能多的促成C端用户和商家的联系。ROI等于收益除以花费。我们有媒体侧的数据曝光、点击、花费，我们有商家付出的成本，我们有C端用户感兴趣的信息，有些数据我们需要明细，有些数据我们需要汇总，这么庞大的数据，这么复杂的数据交互都是怎么实现的呢？
这就诞生了面向开发的数据工具，即大数据处理工具，为了实现数据资产共享，提高数据运算性能，减少资源消耗而诞生的数据产品。
数据资产共享：
可以理解为数据集市，每个业务上传自己的事实表（原子表），供自己及其他部门调用
数据抽取：
数据加工批处理预计算（包含对kylin的使用诉求，对hive,spark任务调度规则处理，线程并发、资源配置等，这个点我不专业就不展开讲了）
以上案例均为TOB行业的产品案例，分为TOB企业购买，TO企业自建，企业自建又可以分为面向运营（业务），面向开发。还有一类咨询类的数据产品，即可以TOB也可以TOC，例如猫眼专业版，本次暂时先不说了，等到XMind分支到他的时候再说，担心看的人迷茫。
这几种TOB的数据产品对于从业者的技能要求是不同的。对于QuickBI，对于excel的功能需要非常清楚，是否某些excel的功能可以移植到平台上（我猜的），要学习的不仅有excel使用，数据存储，数据解析，数据运行原理，每个功能背后都对应一种技能，这方面我也是小白，所以就不细讲了。
对应的TOB面运营的，主要考验产品的业务能力，逻辑思维能力，个人感觉相对简单一些。对应的TOB面向开发的，需要懂开发环境，开发的数据处理流程，开发的数据处理工具，工具的使用方法，包含调度内存占用等等。猜测和QuickBi获取数据，创建数据集是同样的从业者技能吧。
好了，今天就先写TOB的吧，TOC只能放在下次说了，待续。
发表评论 取消回复