「数仓团队」之殇：如何更好地传递业务价值？

• 0x01 业务团队与数仓团队的矛盾

• 0x02 洞悉「业务」的本质

• 0x03 业务需要什么样的数据

• 0x04 数据价值的沉淀

0x01 业务团队与数仓团队的矛盾

大多数的数据仓库团队，都在思考一个问题：我是谁，我在做什么，我有什么价值。

数仓不是算法，通过参数调整，提升收入百分比；数仓不是数据安全，有明确的风控要求；数仓不是分析师，可以为业务提供思路…… 数仓更偏向业务支持团队，比较少的有场景，能够直接去帮助客户，或者助力业务。

虽然我们沉淀了非常多的数据，但却无法快速的使用起来，特别是当我们需要做对应场景的数据分析时，往往无处下手。

于是业务团队只能以“提数”的方式，把需求提过来，至于怎么用，往往就不是数仓团队的思考范围了。

而数仓的同学在思考如何赋能业务，除了满足提数的需求，又希望体现自己的技术能力，于是更倾向于以Cube的方式满足业务提数需求，但怎么用通常就不会介入太深。

于是，业务团队与数仓团队之间，便形成了一种结构性的矛盾。数据产品经理虽然扮演比较好的协调角色，但一来这个岗位的从业人数并不多，二来有统计学、数据开发能力的太少，无法提供实质性帮助，因此业务团队和数仓团队之间的GAP，就一直无法弥补。

结构性矛盾的存在，是数仓团队面临的最大矛盾。

那么如何去破解结构性的矛盾，就需要数仓的团队发挥主动性的精神。

为什么是数仓团队？因为贴近数据最近的地方，通常是最了解数据的人。

你不能指望业务团队对于数据了如指掌，数据团队在数据的应用方面，具备天然的“降维打击”特征。

数仓团队要主动去了解业务的本质。

0x02 洞悉「业务」的本质

业务有很多种，并不一定是为了盈利才算是业务。

比如金融领域的监管合规需求，比如打车、外卖的路径规划问题。那么我们常见的业务，对于数据的需求，分为哪几种呢？

一种是运营团队，例如电商、广告行业，由于业务能够形成数据闭环，因此做各类的业务增长，都能够依赖数据来做决策。这种业务场景对数据的要求比价高，比如核心指标计算是否正确，业务口径是否能对齐，分析维度是否齐全，等等。

一种是内部团队，例如安全、风控等，这一类团队通常会需要非常明细的数据，通常不太会关心数据口径一类的问题，因为本身采集的数据种类比较多，需要处理成相同的类型，用于后续知识图谱的构建，因此数据的场景完整性，就很重要。

一种是分析团队，例如用户增长等，由于漏斗模型的存在，对于数据的下钻与链路要求就比较高，能够通过数据还原用户的每一次操作场景，以及下一次操作的类型。

一种是业务团队，比如财务、采购等，对于数据的需求就是跟着每年企业的战略走，没有固定的套路，通常会提出很多定制化的诉求。

如果总结一下，在数据场景中，业务的主要诉求，大约就集中在：要运营、要场景、要定制，三个大类。

而业务的本质，就是三种变化：是业务的变化、经营的变化，及政策的变化。

0x03 业务需要什么样的数据

既然拿到了业务的本质，我们就需要分别判断一下，业务本质对于数据的诉求是什么。

第一个关键词，就是变化。我们通常会希望构建一个稳定的数仓模型，但这依赖于业务的稳定，而当变化成为新常态时，如何不断适应业务，就显得很重要。因此，效率就是第一位的，需求要怎么排期、多久排期，模型是不是能够做到“开着飞机换引擎”，就非常考验团队的规划能力。

第二个关键词，是业务。业务虽然变的比较快，但业务会非常需要一个准确的指标。比如用户数，不能天天算出问题，来回变更口径，那么业务运营就无法有效的制定KPI，辛辛苦苦做了大半年，口径一变，效果全废，业务团队的积极性就被打击了。或者是数据产出非常慢，我做了一笔合作，新上了一个策略，要等第二天下午才能看到效果，那么就无法做到快速试错。因此，数据质量，其实对于业务，非常重要，是能不能做到有效运营的基础。

第三个关键词，是经营。企业刚开始的管理还会比较粗狂，但做的久了，势必要推动精细化的运作管理。比如报表的产出，就是从临时性的转向常态性的。那么这个时候，我们的数据能不能反应业务的细节，通过数据追溯业务的链路，通过数据分析所有可能的场景，就决定了企业是否能实现精细化的运营。

综上，数据的能力，更倾向于体现在：开发效率、数据质量、通用性，三个部分。

如果更通俗点讲，就是：算的准、算的快、易于理解。

0x04 数据价值的沉淀

对于数仓团队，确定了数据的能力之后，最后，就是如何透传数据的价值。

由于技术团队并不是面向一线的业务，那么什么样的方式，既能够满足多样化的需求，又是最易于理解的形态呢？

“把能力沉淀到产品上”。

很多人会问，数据产品，与提数的Cube，或者是报表的呈现，有什么不同？我想，最主要的不同，在于数据分析问题的思路不同。

举个例子：指标定义，指标一定是与运营的核心目标相关的。比如用户增长，我们就需要偏重过程性的统计，例如“是否第一次”、“是否点击”、“有无跳出”一类的修饰词；比如盈利增长，就需要偏结果性的统计，比如“带动利润”、“提升百分比”、“整体收益”一类的修饰词。

那么这个过程如何做？通常分为三个阶段：数据建模、指标建设及系统呈现。

数据建模是我们通常提到的维度建模方式，指标体系建设依赖于与业务方核对统一的度量值，系统呈现也需要覆盖常用的场景，比如数据大盘、漏斗分析、波动分析、关联分析，等等。如果新的分析场景比较有效，也可以沉淀到产品中来。

最后呈现给业务方的形态，就是告诉你我们有哪些数据，能分析怎样的场景，把数据的技术细节屏蔽，我们只谈数据场景。

数据如果能够以通用、易于理解的方式，在不同工种中间相互交流，价值才有了沉淀的基础。