自新冠疫情以来，各行各业都发生了深刻的变化，而在这些变化中，发展数字经济已成为推动产业转型升级、业务增长，实现经济高质量发展的关键动力。就在2020年04月10日，《中共中央国务院关于构建更加完善的要素市场化配置体制机制的意见》（简称《意见》）正式公布。这是中央第一份关于要素市场化配置的文件。《意见》分类提出了土地、劳动力、资本、技术、数据五个要素领域改革的方向，明确了完善要素市场化配置的具体举措。数据作为一种新型生产要素写入文件，《意见》强调要加快培育数据要素市场。
数据如何驱动业务增长，是我们需要思考和实践的一个重要课题，接下来我从个人的角度，来阐述下数据驱动业务增长的一些思考与建设。
咱们先看整体框架，我们给这个框架定位为“3+2”数据模式
3 ：数据内容为核心，数据应用为价值，数据治理为保障
2 ：数据平台为基础，数据运营为引导
数据内容
数据内容为什么是核心，因为这是一个内容为王的时代，只有拥有丰富的数据内容，才能做出让人意向不到的的增长奇迹。如果用一句话来描述的话，数据就是物理世界的镜像，物理世界的万罗包象在数据世界里更加繁华多样。如何将繁华多样的数据世界，释放出潜能巨大的数据生产力，我们需要一套方法论来管理，这套方法论就是“数据仓库”
好的数据内容，一定是有好的数据仓库作为支撑，那如何做出好的数据仓库，是我们接下来思考的，它的难点在于，物理世界一直变化多样，导致数据世界一直在无限扩充，一边是数据的无序扩张，导致熵增变快，而好的数据内容，需要一个有序的数据组织来支撑，降低熵增，这样就形成了冰火两重天的情景，这也是为什么好的数据仓库不容易建设的原因所在。
建设思路
如何搭建数仓，在业界一直存在着两种思路
从顶到下
从顶到下，即从点到面，到面面俱到
从低到上
从低到上，即面面俱到，到各个击破
数仓分层
不管是哪一种，都逃脱不了以下的常用分层架构
- ODS:操作型数据(Operational Data Store)，指结构与源系统基本保持一致的增量或者全量数据。作为DW数据的一个数据准备区，同时又承担基础数据记录历史变化，之所以保留原始数据和线上原始数据保持一致，方便后期数据核对需要。
- CDM：通用数据模型，又称为数据中间层(Common Data Model)，包含DWD、DWS、DIM层。
- DWD：数据仓库明细层数据(Data Warehouse Detail)。对ODS层数据进行清洗转化，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，基于维度建模思想，将明细事实表的某些重要属性字段做适当冗余，也即宽表化处理，构建明细宽表。
- DWS：数据仓库汇总层数据(Data Warehouse Summary)，基于指标需求，构建初步汇总事实表，一般是宽表。基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标。
- DIM：建立一致数据分析维表，可以降低数据计算口径不统一的风险，同时可以方便进行交叉探查。以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。
- DM/ADS：面向应用的数据服务层(Application Data Service)。整合汇总成分析某一个主题域的服务数据，面向应用逻辑的数据加工。该层主要存放数据产品个性化的统计指标数据，这一层的数据直接对接数据的消费者，是产品、运营等角色可以直接感知理解的一层，大多数这一层的表都可以直接在BI上通过图表的形式直接透出。
建设过程
在建设过程中，我们总结出了三段论， 分别为
还原论
整体论
系统论
我们来依次来解释下，三论的定义
还原论
还原论的定义:是一种哲学思想，认为复杂的系统、事务、现象可以通过将其化解为各部分之组合的方法，加以理解和描述。
把还原论映射到数据仓库，ODS层操作型数据(Operational Data Store)与DWD明细层数据(Data Warehouse Detail)，是还原论的的载体
通过数据还原物理世界的过程中，包含数据还原与数据重组
数据还原要做到知其然，也要知其所以然，所以我们要从数据产生的源头开始参与，一个好的架构师，一定是在源头思考与设计
数据侧从产品功能、用户路径、技术实现、数据流向渗透式参与产品全链路研发，对产品设计和技术实现提出数据视角的诉求，从而保证数据的完整性和一致性，同时也能对业务更加深入的理解。
有了上述渗透式参与产品全链路研发的过程，接下来就是数据内容建设的万里长征第一步
明细级的数据模式一般有以下数据组成
谁，在哪，什么时间，用什么方式，在做什么事情
在DWD这一层主要提炼出业务核心业务过程，识别每一业务过程的实体及实体与实体这件的关系，基于每个具体的业务过程特点，构建最细粒度的明细事实表。
随着软件行业微服务架构成为一种常用架构，微服务有松耦合与去中心化的特点，这样的架构模式更加符合大规模复杂系统协作，提高整体研发效能，但如果站在数据视角去看，数据是分散的，割裂的，不一致的，这就对数据建设提出了更好的要求，可以结合公司的数据使用特点，基于维度建模思想，将明细事实表进行数据重组，把微服务架构引起的数据特点，进行同一业务过程不同事实表进行融合，把同一业务过程的关键属性字段做适当冗余，即宽表化处理，构建明细宽表。
在还原业务过程过程中，需要对具体表进行如下数据剖析，对数据内容要了然于胸
1、业务场景【产品随时间串行的流程，例如授信、支用、还款、催收等等】
2、数据表粒度【实体主键、如何判断唯一一条记录】
3、数据生产方式【场景下增删改查】
4、关键字段状态【status，type】
5、注意事项
整体论
整体论:这种哲学认为，将系统打碎成为它的组成部分的做法是受限制的，对于高度复杂的系统，这种做法就行不通，因此我们应该以整体的系统论观点来考察事物
把整体论映射到数据仓库，包含数据汇聚与全局数据
DWS：数据仓库汇总层数据(Data Warehouse Summary)
在DWS这一层主要汇聚串联业务核心业务过程，站在业务全链路的视角构建不同粒度的汇总事实表，以满足不同场景下的主题分析场景，用少量的汇总表支撑常见的分析场景，理想情况是用20%的表，支撑80%的分析场景。
DIM：数据仓库为表层（Dimension）
在DIM这一层主要保证数据仓库一致性维度，保证数据一致性。
系统论
系统论的定义:主要任务就是以系统为对象，从整体出发来研究系统整体和组成系统整体各要素的相互关系，从本质上说明其结构、功能、行为和动态，以把握系统整体，达到最优的目标
把系统论映射到数据仓库，包含决策数据与系统最优
DM/ADS：面向应用的数据服务层(Application Data Service)
系统最优:耗散结构式数仓，即数据自治
数据应用
数据应用是产生业务价值的最直接的体现，只有数据被应用，才能产生价值。数据应用我们可以大致几类
常规式
一个业务发展是否健康，需要一整套报表/指标体系，这套体系类似于中医里的把脉，诊断，下药三步走。
报表体系
按照职能部门来拆分报表体系，我们大致可以总结为管、产、运三大方向，在搭建报表体系时，我们应该会用到OSM模型、AAARR模型、UJM模型、MECE模型这几个模型
OSM模型是指标体系建设的指导思想，理解业务KPI是OSM模型的核心；制定行动策略是实现业务KPI的手段，而AARRR和UJM模型是实现策略制定的方法论；制定细分指标是评估业务策略优劣的方法，而MECE模型制定细分指标的方法论。
1、根据OSM模型构建整体框架，明确业务目标。
构建指标体系的第一步，需要明确当下业务的目标是什么，找到核心指标作为我们的一级指标。例如我们当下的业务目标是增加营收，对应的核心指标就应该是总营收GMV。
2、根据AARRR或UJM模型拆解用户达成GMV的路径。
明确了核心指标或者一级指标是GMV，接下来就要对业务过程进行拆解，影响到GMV的各个环节是哪些？我们知道，用户到最终付费贡献营收一般需要经历以下完整过程：注册产品→登录产品→商品曝光给用户→点击商品浏览详情→收藏加购→成交转化。这样一来我们就把核心指标对应的中间过程梳理出来了，同时，针对每个中间过程，我们也有对应的策略，比如在注册环节，我们可以通过广告投放和优惠激励的形式进行拉新，提高注册量等。
3、根据MECE模型对GMV达成路径的每一个指标进行拆解，实现指标分级治理。
前面两个步骤，首先我们明确了业务目标和核心指标；然后，我们将业务目标的中间过程进行了拆解，并给出对应的策略；接下来我们需要对这些中间过程建立指标，并向下进行逐层的拆解，这个过程我们称为指标体系分级治理，用到的模型是MECE模型。MECE模型的指导思想是完全独立，相互穷尽，根据这个原则拆分可以逐层细化，暴露业务最本质的问题，帮助我们快速地定位业务问题
指标体系
指标体系是报表体系搭建完之后，如何实现具体落地的一套方法论，如图所示
（1）业务板块：即面向业务的大的模块，就是公司的产品线，不会经常变。比如一个公司有三个产品线分别是产品线A、产品线B、产品线C，那么这三个产品线分别属于不同的业务板块。
（2）数据域：数据所属的领域。如电商产品中的用户、商品、交易等大的功能模块都属于数据域。
（2）业务过程：完成某个业务所涉及的全部过程。如电商业务中的下单、支付、退款等环节都属于业务过程。
（3）时间周期：就是统计的时间范围，如“近30天”“自然周”“截止到当天”等。
（4）修饰类型：对修饰词的描述。如电商中支付方式、终端类型等。
（5）修饰词：除了维度以外的限定词，如电商支付中的微信支付、支付宝支付、网银支付等。
（6）原子指标：即不可再拆分的指标，比如支付金额、支付件数等指标
（7）维度：是指度量单位，用来反映业务的一类属性。常见的维度有地理维度（国家、地区等）、时间维度（年、月、周、日等）、订单的维度等。
（8）属性：隶属于维度。如地理维度中的国家名称、省份名称等都属于维度属。
（9）派生指标：一组对应的原子指标、修饰词、时间周期就组成了一个派生指标，如图所示。
例如网约车的指标拆解
自助式
多维分析
OLAP即联机分析，又可以称为多维分析，是关系型数据库之父Edgar Frank于1993年提出的概念。
OLAP的多维分析操作包括：
钻取（Drill-down）、上卷（Roll-up）、切片（Slice）、切块（Dice）、旋转（Pivot）
★钻取：维的层次变化，从粗粒度到细粒度，汇总数据下钻到明细数据。eg：通过季度销售数据钻取每个月的销售数据
★上卷：钻取的逆，向上钻取。从细粒度到粗粒度，细粒度数据到不同维层级的汇总。eg：通过每个月的销售数据汇总季度、年销售数据
★切片：特定维数据（剩余维两个）。eg：只选电子产品销售数据
★切块：维区间数据（剩余维三个）。eg：第一季度到第二季度销售数据
★旋转：维位置互换（数据行列互换）。eg：通过旋转可以得到不同视角的数据
多维分析的目标是抽离出通用分析框架，便于用户能够自定义时间/自定义维度/自定义指标的便捷分析场景，提高用户自主性，提高效能。同时也是离线报表体系的补充，打破固定的维度和指标的方式，让用户自主性增强。现在行业内多维分析一般采用Rolap的方式，选用的技术架构为MPP架构的CK、StarRocks，Doris。在实践过程过程中，我们进行了多维度的技术架构选型，如图所示，我们从业务场景及挑战，引擎选型，数据架构多方面考虑，最终选择了StarRocks计算引擎
A/B实验
AB测试也叫对照实验或分桶实验，简单来讲就是为同一个目标设计多个方案，在同一时间让一部分用户使用A方案，一部分用户使用B方案。记录分析用户的使用情况，根据分析结果比较得出哪个方案更加优秀。
A/B测试的基本步骤
AB测试通常是一个反复迭代的过程，它的基本步骤包括：
- 设定AB测试的目标
- 设计多个优化方案
- 确定参与实验的方案与分流比例
- 进行线上测试
- 收集用户数据进行数据分析和效果判断
- 根据测试结果发布新版本或添加新方案继续测试
A/B实验步骤及案例分享
典型A/B实验的步骤包含确认实验目标、设计A/B实验方案、上线实验与过程监控、结果复盘。接下来就以运营团队常做的沉默召回作为案例，串联整个A/B实验的全流程。
1. 确认实验目标
业务团队目前正在做沉默用户召回，想验证不同的召回发券策略的效率，并在接下来的召回运营中推广使用效率最高的策略。此时的实验目标：找到召回沉默用户效率最高的策略。
2. 设计实验
设计实验时需要明确目标用户、实验周期、最小样本量、用户分组、分流比例、分组策略等信息。
-
目标用户：过去30天-180天未下单老客
-
实验周期：测试1周，周期内不进行打散
-
最小样本量确定：输入原始的召回率、策略优化后的召回率以及显著性水平，网上有很多类似的工具，下面是来自https://www.eyeofcloud.com/124.html计算的结果，最少需要5300的样本量
- 实验分组及策略：
| 分组 | 分流比例 | 沉默召回策略 |
|---|---|---|
| 实验组1 | 30% | 发放满20-5的优惠券，并通过精准营销短信触达 |
| 实验组2 | 30% | 发放满30-6的优惠券，并通过精准营销短信触达 |
| 实验组3 | 30% | 发放满40-10的优惠券，并通过精准营销短信触达 |
| 对照组 | 10% | 不进行任何策略 |
3. 上线实验与过程监控
实验上线后，需要检测实验是否按照预期设定正常运行，在A/B实验中常出现的需要检查的问题有如下：
- 空白组是否真的空白的，有无空白组用户领取到实验组1、实验组2、实验组3发的券，如果发现有领券的，那需要排查分流系统问题（一般需要产研根据log信息找到当时为什么判定给该用户发券）
- 1个用户是否仅属于某一个组，有无存在多个组的情况
- 分流是否和预先设定的分流比例一致，误差1%也要寻找原因
- 实验样本是否是预先设定的目标实验样本，判断实验是否进行了用户筛选过滤，比如本实验是对沉默用户进行召回，有无近30天有交易的活跃用户也被发券，如果有那说明目标用户的圈选出问题，需要排查上下游看看是哪个环节出现问题
4. 结果复盘之ROI评估
通过试验组1、实验组2、实验组3分别和对照进行对比，能得出3组策略的效率。ROI的分子是投入的总资源成本，产出可以是用户的原价交易额、单量、利润等信息，此处用原价交易额作为产出，来评估不同策略的召回效率，最终结果如下所示。可以看到：
-
3种召回策略ROI均置信，且ROI由高到底是实验组2（满30-6）>实验组3（满40-10）>实验组1（满20-5）
-
虽然单量最高的实验组1，但是由于实验组1发券的门槛低只有20元，导致最后的交易额增量不如实验组2和实验组3
-
虽然实验组2的交易额增量不如实验组3，但是实验组的2的成本低于实验组3，因此最后ROI比实验组3高
所以，通过该实验可以看出，在发放针对沉默用户发券的时候，需要同时考虑到门槛和面额，一方面低门槛会让用券的用户增加，但低门槛下客单较低，总原价交易额也就越低；另一方面面额影响用户转化的同时也影响投入成本。具体设置多少的门槛和面额最佳，还需要通过更多的A/B实验来判定。
在A/B实验中，有以下3点需要注意的。
1. 注意保证单一变量
A/B实验需要保证实验组样本和对照组样本是同样属性的，通过控制单一变量判断最终效果。但是在实际的过程中，有团队会在不同应用市场、不同渠道进行测试，比如测试2个投放策略，一个在快手测试，一个在抖音策略，这两个渠道的用户群里天然的就有差异，得出的数据是不可信的。正确的做法是在快手和抖音都用同一个策略，验证统一策略在不同渠道的效果， 或者只在快手渠道进行不同策略的测试。
2. 注意效率和规模
很多时候做A/B实验是对用户进行了筛选的，这个时候得出的ROI较高。但是这个策略一旦扩量到全部用户，ROI有可能就会降低。因此在说某个策略的ROI时，需要注意是否是小规模用户的效率，而不是整体用户的ROI。
3. 注意新奇效应
在出某个新功能、新策略的时候，用户可能会比较感兴趣，这个时候效果较好，但是过一段时间用户新奇感觉消失。为了避免这种情况，需要在单一变量下，重复、长时地进行实验，得到长期稳定的结果。
回流式
用户画像
交互设计之父Alan Cooper最早提出了用户画像（persona）的概念，认为“用户画像是真实用户的虚拟代表,是建立在一系列真实数据之上的目标用户模型”。通过对客户多方面的信息的了解，将多种信息集合在一起并形成在一定类型上的独特的特征与气质，这就形成了用户的独特的”画像”。
如下图所示
用户画像建模其实就是对用户“打标签”，从对用户打标签的方式来看，一般分为3种类型：
①统计类标签；
②规则类标签；
③机器学习挖掘类标签。
下面我们介绍这3种类型的标签的区别：
① 统计类标签
这类标签是最为基础也最为常见的标签类型，例如，对于某个用户来说，其性别、年龄、城市、星座、近7日活跃时长、近7日活跃天数、近7日活跃次数等字段可以从用户注册数据、用户访问、消费数据中统计得出。该类标签构成了用户画像的基础。
② 规则类标签
该类标签基于用户行为及确定的规则产生。例如，对平台上“消费活跃”用户这一口径的定义为“近30天交易次数≥2”。在实际开发画像的过程中，由于运营人员对业务更为熟悉，而数据人员对数据的结构、分布、特征更为熟悉，因此规则类标签的规则由运营人员和数据人员共同协商确定；
③ 机器学习挖掘类标签
该类标签通过机器学习挖掘产生，用于对用户的某些属性或某些行为进行预测判断。例如，根据一个用户的行为习惯判断该用户是男性还是女性、根据一个用户的消费习惯判断其对某商品的偏好程度。该类标签需要通过算法挖掘产生。
应用场景
用户画像作为平台级的应用，很多运营策略及工具，都是在其基础上构建的 我们大致可以分成三类：广告系统、推荐系统、营销系统
商业分析
商业分析 (Business Analytics)，简称BA，是以商业知识为基础，数理编程为手段，从数据分析出发，以决策优化来创造商业价值。
数据治理
DAMA和DCMM对数据治理的定义都是：数据治理（Data Governance，DG）是指对数据资产管理行使权力和控制的活动集合（规划、监督和执行）。传统的数据治理内容通常包含：数据标准管理、元数据管理、数据质量管理、数据安全管理、数据生命周期管理等内容。
我们参考了DAMA和DCMM的数据治理指定的治理项，又结合了业务现状和发展阶段，我们抽象出了符合我司的数据治理项，我们暂定称之为数据治理五力图
如下图所示
1、数据标准
根据信通院发布的《数据标准管理实践白皮书》定义：数据标准（Data Standards）是指保障数据的内外部使用和交换的一致性和准确性的规范性约束。和咱们俗话说的俗话说“无规矩不成方圆”是一个意思
我们可以从整个数据生命周期来定义数据标准的不同侧重点
数据采集，数据加工，数据销毁
数据采集
数据加工
1、数据模型
标准化
2、加工处理
代码层级化
代码/注释不分家
数据销毁
影响评估及通知
（1）列明下线目标任务&表的影响范围，做出评估；
（2）如存在下游使用方，则需提前2周(LV1&LV2级别任务&表)，1周(除LV1&LV2级别外的其它任务&表)进行下线影响群体性通知（使用数据平台-变更通知工具），说明下线原因，标明下线日期，如有新替代任务&表，变更通知中需提供具体切换方案
下线流程操作
2、数据质量
数据质量我们重点关注准确性和及时性，我们从面向源头，面向过程，面向结果进行全链路的质量保障，如下图所示
3、数据模型
数据模型我们从数仓整体视角出发，从数仓层级的下、中、上进行治理，根据不同层级指定不同的模型治理策略，最终达到下冷、中温、上热的数仓热力图，形成数据迭代闭环。具体操作如下
4、数据成本
数据成本治理，我们解构了成本的构成要素为计算成本和存储成本，我们根据计算和存储的特性，制定了一序列的优化措施，最终达到成本的有效控制，具体措施如下图所示
5、数据安全
数据安全我们从数据分类分级、存储脱敏、传输加密进行安全基础保障，同时我们在数据使用中由审计流程来防止数据安全泄密，在流程制度上来确保数据的安全性。
数据平台
数据平台是数据驱动业务增长的基础保障，是降本增效的关键所在，我们大致把数据平台分为两大类，工具型产品和大数据生态组件，这两者相互配合，大数据生态组件是点，工具型产品是面，两者合起来是体，发挥出数据平台的核心价值，让数据驱动更加便捷高效。
以下是列举的的数据平台中的核心构成要素，由于数据平台构成要素比较丰富，就不在这里一一介绍，把核心要素在下图中展示
数据运营
数据运营是数据驱动的宣传队，是数据团队中服务与体验的先锋队，相当于外交部，承载着数据团队门面担当。数据运营和数据消费方形成嵌入式的合作关系，把数据团队中的数据资产透传给数据消费方，降低数据消费门槛，让用户更加便捷的查、找、用数据。为了让数据发挥更大的价值，数据运营需要做数据定期宣讲、数据座谈会【对外】、数据复盘会【对内】，从而沉淀数据知识库，并将这些知识库以智能问答的方式服务于数据消费方，持续将数据生产力赋能到数据消费方。 下图为数据运用的重点构成要素，其目标是让公司没有难用的数据
数据驱动业务增长是一个体系化的工程，上述的3+2模式
3 ：数据内容为核心，数据应用为价值，数据治理为保障
2 ：数据平台为基础，数据运营为引导。
是在术上的策略，讲的是如何落地。
我们还需要道的支撑，道是组织上的保障，意识形态上的转变，让大家知道数据驱动不仅仅是数据部门的事，而是从业务整体链路上大家共同协作的结果，从产品、运营、研发、数据、算法等业务方向通力协作，让数据驱动成为业务增长的引擎，让数据要素，成为生产力。
以道御术，以术辅道，是我们数据驱动业务增长的不二法门，让我们一起探索符合时代发展、行业形态、企业不同阶段的数据驱动的方法和模式。