01业务与数据的闭环业务与数据，可以理解为一种映射关系，数据是数字世界中业务的另一部分.例如：衣服鞋子的尺码，喜欢吃什么食物，喜欢看什么文章，什么时候起床睡觉等等，这些个人数据都记录在云端，这是你在数字世界中的映射。网上流行一句话很有意思：手机可能比你自己更了解你。那是因为你在里面存了一段数据。相信大家都知道，手机使用频率越高，记录的个人数据越多越好，使用频率也会越高。业务和数据是这样一种闭环促进关系：业务上线越全面、越深入，就会有更多的数据反过来赋能业务。业务数据化业务在线，存储业务产生的数据，记录业务；数据业务化对收集到的业务数据进行分析，评估业务状态，指导业务发展，提高效率；▲图1业务与数据闭环02认知：数据、信息和知识接下来说说数据分析环节。在此之前，我们先来宏观的了解一下从数据到决策的过程。我们无时无刻不在被数据记录着：年龄、身高、体重、消费金额、运动步数等等，单纯看这些数字是没有意义的，我们必须仔细思考数字背后生动的因果报应（灵性业力））服务（灵魂）。生意是有灵魂的！当我们从这些数字中发现业务背??后的信息，然后将这些数据和信息转化为一套规则来辅助我们进行决策（知识）时，数据就会变得非常有价值。这个过程是：从数据到信息再到决策（知识）。举个生活中的例子：体温39度是一个简单的数字，背后的信息就是你发烧了，你做出的决定（知识）就是你需要去医院看病治疗。对于上面总结的从数据到决策的过程，我们常说我们根据数据分析的结果来做决策。这种说法虽然可以，但是不够直接。事实上，我们的决策是基于对业务的理解，而数据是帮助我们加深对业务理解的工具。数据赋能业务一般要经过四个环节：数据表征、商业理性、商业战略和行动模式。一开始，我们通过数据评估业务状态，发现异常的业务表现，然后综合分析数据并结合一线调研反馈，反复进行猜测和数据验证，找出数据表现背后的业务原因，以及然后想好了解决问题的策略，然后落地执行，监控后续效果并不断迭代，直到问题解决，业务发展走上正轨。下面以刚才生病发烧的例子来详细解释数据赋能业务的过程：体温39度是一种数据表现，背后的物理原因是发烧（业务原因）。你躺在病床上，护士过来给你输液（行动方式）。这些程序完成后，您将被要求持续测量体温（监测着陆效果）。如果发烧不退，可能需要继续输液和吃药（不断迭代经营策略），直到最后体温恢复正常（问题解决），身体进入健康状态（业务发展中）正轨）。03业务策略闭环分析数据定位业务问题，基于业务理解，确定解决策略，最终对业务产生正向影响。在整个过程中，业务战略有两个闭环：逻辑闭环和业务闭环。逻辑闭环的数据分析过程必须是逻辑闭环的，论据必须能够支持结论的成立；闭环业务战略在业务上的实施必须闭环，迭代调整；两个闭环相互影响，首先要做的是对逻辑闭环进行论证，确保结论成立。真正落地的时候，业务可能不行，所以需要在新的业务理解的基础上，不断迭代论证逻辑，形成新的逻辑闭环，然后再落地，直到业务能够顺利运行。所以在数据分析的过程中经常会出现两类问题：一是相关的逻辑闭环没有落地，也就是说策略的逻辑论证没有问题，但是在业务上离顺利运行还差得很远；业务闭环相关策略未落地或已落地反馈周期过长，导致业务理解仅停留在当时分析数据的点上，没有验证反馈；那么我们如何判断业务战略是否扎根于我们的工作呢？主要分为两步：深入思考战略制定的业务假设是什么？确定业务假设是否有效的研究？比如：你为B端商户设计了一套完整的权益方案，希望吸引商户往平台方向做生意。假设权益方案在逻辑上是正确的，但如果真的有效，则涉及到一些商业假设，需要建立：平台能很好的触达商家，商家也能看懂权益方案；权益方案的细节，商家真的很关心；……那么就要考察一下，这些商家的假设是否真的成立？如果成立，那么该策略有效的概率就会很高；如果商户无法理解复杂的权益方案，或者商户根本不关心权益，则说明经营策略不接地气，需要及时调整。当然，对策略是否有效进行预研验证是非常有必要的，但有时研究结果并不能直接推断出策略是否有效，因此需要设计一个设计良好的实施方案并快速迭代验证。最后以类比的方式判断一个人是否懂业务：如果这个人整篇都在讲数理逻辑而没有进行业务判断，或者某些业务判断明显站不住脚，那么这个人大概率是不懂业务。要做出正确的决定，首先要在逻辑上成立，在商业上也要有可行性。04数据分析与指标体系如今，无论是企业还是个人发展，整体都在向数据化方向转型，数据也越来越重要。企业需要数据资产来保持行业竞争力，产品需要根据数据分析的结果进行迭代，运营需要用数据来评估活动的效果等，随着时间的推移，数据思维和分析能力将逐渐成为横向能力并被所有人掌握。大家都知道数据分析绝对是未来的趋势。所以我觉得大家在这个窗口期选择数据字段是非常明智的。建立指标体系是数据分析的第一步。数据指标中心是规范指标开发和管理维护的系统。对指标的组成部分进行解耦和分离，在逻辑表中进行规范定义。在此基础上，后续可以遵循一定的规则。自由组装实现自定义指标功能。在我们日常的数据工作中，指标的重要性毋庸置疑。指标来源于业务的场景呈现，业务也通过指标看透问题。但是，由于它们如此重要且使用如此频繁，因此指标也以各种方式出现。困惑、难用、难找等。因此，我们必须有一套合理、合规的指标治理方法，并将这套方法转化为工具，通过固定的流程来约束原本不可控的行为。接下来我们来看看，指标治理的方法论有哪些？而这些方法是如何设计到系统中去的，也就是我们所说的——数据指标中心。05如何建立指标体系1、首先，明确指标，归纳到相应的学科领域。指标的本质是一个量化的目标，比如一个常见的例子：①我们想把用户的盘子做大，对应的量化指标是注册用户数；②我们要统计今天的销售额，对应的量化指标是支付总额；③我们要衡量一个活动的效果，对应的量化指标就是下单率。从上面的例子我们可以看出，我们常用的几类指标有存量指标（注册用户数）、成交指标（支付金额）、转化指标（下单率）、其他比例、统计、排名等。不常用，这里就不多说了。这些不同类型的指标分散在我们产品的不同功能模块中，为了更好的对其进行规范和管理，我们需要按照主题域对这些指标进行归集。主题域是在“仓库模型中心”中创建和定义的，这里只需要将相应的指标分配给相应的主题域即可。2.然后拆分原子指标和派生指标。首先我们来看一下原子指标和派生指标这两个概念是什么。①原子索引：是事实表中某个字段的统计值（sum、count、max、min、avg），如订单用户数、订单金额等；②衍生指标：基于原子指标，结合维度后生成的指标，比如过去一天商城下单的用户数，本周金牌会员在商城的下单量等。原子指标没有商业意义，它们只是预定义的代码片段。业务中使用的指标基本上都是派生指标。3.然后定义原子指标和派生指标的生产逻辑。本章开头有一句话：“对指标的组件进行解耦和分离，并在逻辑表中进行规范的定义”，这个解耦和定义的过程就是将一个派生指标拆解成原子指标的过程、时间段、限定维度、聚合粒度，然后重新组装生成新的衍生指标：在上面的例子中，可以这样理解：①统计周期是这个原子指标统计计算的时间范围，即本星期;②聚合粒度是指标的主体，即按照哪个维度进行聚合，这里是黄金会员；③限定维度是限制原子指标的计算范围，这里限定为商城，即只计算与商城相关的数据；④原子索引是针对某个字段预定义的计算规则。这里是订单金额的累计。4.最后通过指标管理平台规范指标的制作（1）规范的指标命名和命名规范对于后期大量指标的管理非常重要，因为当指标很多的时候，往往需要使用搜索功能查找指标，检索的前提是您对该指标有一定的预认知。这就需要我们规范指标的命名。索引命名规范有以下三个要点：①简洁、明了、通俗易懂：最好在不看注释的情况下看到索引名称就知道其含义、归属地等；②统一格式：每个索引的格式相同，通过不同模块的名称拼凑而成；③生成统一性：原子指标的规范与其继承的派生指标的规范一致。以商城相关指标为例：①所有业务订单和支付指标，默认以主订单为统计口径，不带“主订单”字样，如商城下单数；当统计口径为“子订单”时，需要在名称中注明，如：商城下单数量；②所有与人相关的指标默认以“注册用户”为统计主体，无需包含访问次数等“用户”相关词；当统计主体为“游客”时，需在名称中注明，如：游客到访次数；③未明确业务范围的指标默认为平台指标，无需包含“平台”相关词，比如过去30天支付过的人数。如果有限定业务范围，需要加上业务名称，如：mall——最近30天支付过的人数；④没有指定时间段的指标默认为“近1天”（但需要保存小时的粒度，方便后续下钻），不需要填写与“时间”相关的词，如注册人数。如果有限定时间范围，需要加上时间段：如：最近7天的注册人数。完整的命名规范为：商城（业务板块）+用户（实体）+最近7天（统计周期）+新（业务动作）+子订单（类型）+单日（区间周期）+平均（统计计算规则）)+支付金额（原子指标），如：商城-近7天用户新增子订单日均支付金额（不存在的部分可留空，如：商城-累计支付）数量）。（二）标准化统计口径当指标主体为实体（名词）：旅游者、用户、商品等时，只需将单位定义为“人/人”。如：游客数、用户数、产品数。当指标为业务动作（动词）时：如点击、支付、下单等，除了定义单位为“次数”外，还需要考虑与该动作关联的实体的单位，比如“商品”，需要多定义一个单位“交易次数”；当是“用户”时，需要多定义一个“人数”等；因此，一个订单的指标action会有多个不同的统计口径：下单数、下单人数、下单数、下单数、下单金额...定义指标名称时，需要⑶标准化指标层级我们都知道，随着公司的发展，产品不断迭代，功能的增减和业务的变化必然影响指标的发展。一些旧的指标不断更新或丢弃，同时新的指标也在不断增加。这时候，指标的管理也成了一个问题。谁制定哪些指标？以后谁来维护……更好的方案是把指标分为两级：①一级指标：原子指标和一小部分整个平台的核心指标，收集了各业务部门的需求后，由数据中心统一制作，有完整规范的开发流程：需求-评审-排期-开发-测试-验收-上线。所有维护管理工作由中台负责；②二级指标：即派生指标，由各业务部门通过指标中心生成。没有严格的开发过程。各业务部门根据需要自行创建，但需遵守命名规范。所有维护和管理工作都在内部进行。06业务合作与职责边界指标中心完成后，需要明确整个数据分析过程中各个角色的职责边界。公司在追求商业价值最大化的过程中，会涉及多个部门的协作。业务产品经理：负责协调研发、测试、设计等部门，根据实际业务需求推出产品；数据开发工程师：根据数据产品经理的需求，按模型、按主题处理业务数据；数据分析师：建立系统的分析框架，评估业务状态，定位业务问题，指导业务发展；数据产品经理：负责协调数据开发同学对业务数据进行模块化、系统化，同时将业务分析框架商业化，提高数据赋能效率；运营：根据业务方向，通过短期激励活动，引导用户实现产品的长期价值；在实际工作中，会涉及到更多的部门，比如算法部、研发部、用户研究部等，这里就不一一展开了。具体合作流程：一是业务产研团队根据实际需求推出产品。业务数据采集完成后，会同步到数据仓库。数据开发工程师根据数据产品经理的需求对数据进行处理，数据分析师将对业务进行全面、逻辑的拆解和分析，配合数据产品经理将分析框架沉淀在数据产品上。数据分析师、数据产品经理、数据开发工程师一起构建整个业务的数据体系，然后对外输出：评估业务状态、用数据支撑运营活动、分析产品迭代效果等等。
