数据基建：先有指标还是先有数据？

数据指标用户老板北极星

发布于 2026-06-09

版权声明

我们非常重视原创文章，为尊重知识产权并避免潜在的版权问题，我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容，访问作者的公众号页面获取完整文章。

查看原文：数据基建：先有指标还是先有数据？

文章来源：

随风的数据分析

扫码关注公众号

扫码阅读

手机扫码阅读

大家好，我是随风；

咱们来聊一个特别“要命”的话题。

场景来自真实案例，主人公我们就化名老张吧；

周一，老板把他叫进办公室，拍着肩膀说：“咱们现在业务跑得不错，但我心里没底，你给我出个驾驶舱，让我每天打开手机就能知道公司咋样了”

老张说好，转头去找研发总监要数据。

研发总监一脸无奈：“数据是有，都在各个业务库里躺着呢。但你得告诉我你要哪些字段，我好给你开接口、做埋点。要不然几千万条数据我全给你导出来？”

老张心想有道理，又跑去找业务负责人聊指标口径。

业务负责人更直接：“我们也很想知道用户到底在哪个环节流失了，现在全靠猜。你先给我们看看现有的数据，我们才能定义出合理的指标啊。”

于是老张回到了座位上，打开电脑，盯着空白的Excel发了三个小时呆。

老板要驱动，研发要字段，业务要看数。

先得有指标，才能提数据需求；但不看数据，又定义不出靠谱的指标。

这不就是个死循环吗？

我跟老张说，你不是一个人。我见过的所有从0到1搭建数据体系的人——不管是数据负责人、第一个数据分析师，还是被赶鸭子上架的产品经理——几乎都在这个坑里摔过跟头。

而且更要命的是，这个死循环会催生出两种“看起来很努力但实际上在浪费生命”的应对方式。

第一种，我管它叫“完美全量派”。

逻辑是这样的：既然现在不知道需要什么，那我就先把所有能拿到的数据全都接进来。用户行为全埋点，业务库全量同步，日志文件一个不落。等数据攒够了，想算什么指标算不出来？

听着挺有道理对吧？但实际执行起来，三个月过去了，数据还在“接入中”。开发天天加班搭ETL管道，服务器成本往上蹿，老板问“驾驶舱呢”，你说“再等等，地基还没打好”。等你真把数据接完了，业务方向可能都换了两轮了。

第二种，我管它叫“完美指标库派”。

这一派更学院风。既然没有数据，那我就先设计一套完美的指标体系。花两周时间调研行业最佳实践，参考阿里京东美团的指标库，再结合公司业务画一张巨大的指标地图。从北极星指标拆到过程指标，从结果指标拆到驱动指标，层层下钻，环环相扣。

开评审会的时候PPT画得那叫一个漂亮。但一到落地环节就卡住了——你发现精心设计的137个指标里，有90个对应的数据根本不存在。研发问你“先埋哪部分”，你说“都得埋”，研发说“那得排期到下个季度”。

看出来了吗？

追求“完美全量”的，会死于资源耗尽。

追求“完美指标库”的，会死于落地不能。

这个困境，就是最经典的“先有鸡还是先有蛋”问题。而且它比哲学问题更残酷——哲学问题可以永远辩论下去，但你的老板可能等不了两个月就会开始怀疑“数据团队到底在干什么”。

今天我写这篇文章，就是想把这个事儿彻底说透。

在0到1的阶段，指标和数据的关系，既不是先有鸡，也不是先有蛋。

而是你得先知道自己想吃什么，再决定是养鸡还是买菜。

这个“想吃什么”，就是我们接下来要重点聊的点。

但在给出解法之前，我得先把这件事的本质拆开给你看。为什么看起来无懈可击的“标准做法”，在初创期会变成一个又一个的坑。

论点A：为什么说“全量数据接入”在初期是个谎言？

我得先声明，我不反对全量数据。大厂的数据中台动辄几千个节点，每天处理PB级的数据，那当然是全量的，那当然是要追求“数据全、维度细、时效高”的。

但问题在于，你是大厂吗？

太多初创公司的数据负责人，一上来就跟老板画大饼：“我们要建立统一的数据仓库，把所有业务系统的数据全部接入，构建OneData体系，未来任何分析需求都能秒级响应。”

老板一听，觉得专业，批了预算。

然后三个月后，老板发现钱花了一大笔，自己连个最基础的GMV趋势图都还看不到。

问题出在哪儿？

第一，全量意味着全慢。

一个典型的创业公司，数据分布在哪些地方？订单系统在MySQL里，用户行为在Nginx日志里，广告投放数据在百度腾讯巨量引擎的后台里，客服聊天记录在第三方SaaS工具里，销售跟进记录在CRM里，可能还有一部分核心数据在Excel里飘着。

你把这些数据全部规范化、结构化、清洗入库、打通关联，没有三到六个月的工程周期根本下不来。而且在这个过程中，业务是动态变化的——你这个月接完了订单表，下个月业务上线了新功能，数据结构又变了。

第二，全量意味着全贵。

就算你技术团队很强，能用最快的速度搭起一套数据管道。但你想过没有，那些“万一有用”的数据，每天的存储成本和计算成本是实实在在的。我见过一家A轮公司，为了“以后可能会分析用户行为路径”，把几亿条全埋点日志存了半年，每个月云服务账单多出几万块，但真正用到的字段不超过20个。

第三，也是最要命的——全量解决不了核心问题。

就算你真的用了半年时间、花了几十万成本，把所有数据都接进来了。然后呢？

老板说：“好，现在数据全了，你告诉我，为什么这个月的复购率跌了？”

你打开数据仓库，面对几百张表、几千个字段，依然不知道从哪里下手。

数据不等于洞察。全量数据更像是把一座图书馆搬到了你面前，但你依然不知道哪本书里有你需要的答案。

更重要的是，在初创公司，你最稀缺的资源不是数据，是时间，是老板的耐心，是研发团队的配合意愿。一旦大家觉得“数据团队搞了半天也没什么产出”，你的信任账户就透支了，后面再想推动什么事情会难上加难。

所以结论很明确：在0到1的阶段，“全量数据接入”不是地基，是沼泽。你越是用力往下挖，陷得越深。

好，那有人说了，数据接入这条路不通，那我先把指标定义清楚总行吧？磨刀不误砍柴工嘛。

这个想法，带出了第二个问题。

论点B：指标库不是设计出来的，是“长”出来的

很多人职业生涯早期，应该都经历过意气风发的时期

刚入职，老板说“你去把指标体系搭起来”。你关起门来，花了两周时间，参考了行业报告、竞品分析、各种数据分析框架模型，洋洋洒洒写了一个68页的指标字典。从获客到激活到留存到变现到传播，AARRR每一层都拆得明明白白。评审的时候，大家纷纷点头，“专业”、“全面”、“高大上”。

然后呢？

然后那份文档就安静地躺在公司Wiki的某个角落，再也没人打开过。

为什么？因为那份指标字典里定义的很多东西，要么是数据根本拿不到，要么是跟当前业务阶段严重脱节。比如我在里面详细定义了一个“用户内容消费深度指数”，需要计算用户观看视频的完成率、点赞评论转发的权重、停留时长的分段得分……但当时产品连播放进度上报都还没做。

闭门造车式的指标规划，最大的问题在于，它假设你提前知道所有需要知道的东西。

但现实是，在业务早期，你对用户的理解、对业务逻辑的理解、对关键驱动因素的理解，几乎每天都在刷新。你今天觉得“用户注册转化率”是最重要的指标，明天跟几个用户聊完发现，注册不是问题，问题是注册完不知道干什么。

指标体系不是一张蓝图，它更像一棵树。

蓝图是设计好再施工，每个房间干什么用一开始就定好了。但树不是，树是从一颗种子开始，先长主干，再长枝干，最后才是叶子。你没办法“设计”一棵树长成什么形状，你只能给它阳光和水，然后引导它往正确的方向长。

所以，在0到1的阶段，放下那种“我要搭建一套完整指标体系”的执念。你需要的不是137个指标，你只需要一个，最多三个。

说到这儿，我们的第三个论点就自然浮现了。

论点C：北极星指标——那个“想吃鸡蛋的胃”

鸡和蛋的死循环之所以难解，是因为我们总在“手段”层面打转——是先有数据还是先有指标？

但如果我们跳出这个二元对立，往上一层看，你会发现有一个东西比数据和指标都更前置。

那就是“你到底想解决什么问题”。

用吃来打比方可能更清楚。

你纠结于先有鸡还是先有蛋，是因为你还没想清楚自己到底想吃什么。如果你想吃的是鸡蛋灌饼，那你需要的是鸡蛋；如果你想吃的是大盘鸡，那你需要的是成年的鸡；如果你只是渴了想喝口汤，那你鸡和蛋都不需要，你需要的是水。

这个“想吃什么”，在数据基建里，就是你的北极星指标。

北极星指标这个词这几年被说烂了，但我发现很多人其实没理解它的真正价值。它不是一个挂在墙上的口号，也不是拿来给投资人看的虚荣指标。它是那个能让你在资源极度有限的情况下，果断地说出“这个数据现在不重要”的唯一依据。

我来举几个具体的例子，让你感受一下有北极星和没北极星的区别。

假设你在一家做内容社区的初创公司。老板说“我们要提升用户活跃度”。

如果没有北极星指标，你会怎么做？你可能会去定义什么叫“活跃”——日活？月活？发帖数？点赞数？停留时长？然后试图把所有能反映活跃的数据都接进来，再慢慢看哪个更重要。

但如果老板说：“我们的北极星指标是单日人均发帖量。”

整个世界瞬间就清晰了。

要计算这个指标，你需要分子（总发帖数）和分母（日活用户数）。

所以你只需要接入两个数据：用户每天的登录记录，和用户每天的发帖记录。

其他所有数据——点赞、评论、转发、浏览深度——在这一刻都变得“不那么紧急”。

看到了吗？一个清晰的北极星指标，就像一把刀，咔嚓一下把所有看似重要实则噪音的数据需求全部砍掉，只剩下那根最核心的骨架。

再比如一家SaaS公司。如果北极星指标是“月度经常性收入（MRR）”，那你第一优先级的数据就是每个客户的合同金额、起止时间、续约状态。至于用户在使用产品过程中的点击行为、功能使用频次，那是第二步甚至第三步才会考虑的事情。

一家电商公司，如果北极星指标是“首单转化率”，那你首先要盯死的数据是用户从访问到下单的整条链路，尤其是注册登录、加购、填写地址、支付这几个环节的完成率。至于用户下单后的物流体验、售后评价，虽然也很重要，但初期可以先放一放。

所以，破解“先有指标还是先有数据”这个死循环的关键，根本不在数据和指标本身。

在于你要先找到那个“想吃鸡蛋的胃”——那个能让所有人都点头说“对，这就是我们现在最应该关心的东西”的北极星指标。

有了它，指标自然就有了（围绕北极星的拆解指标）。

有了指标，数据范围自然就有了（只接跟这几个指标相关的数据）。

鸡和蛋的问题，被一个“想吃鸡蛋的胃”给化解了。

读到这儿，你可能觉得有道理，但紧接着下一个问题就来了：道理我懂，但老板自己都说不清楚北极星指标是什么，怎么办？

这就是实操层面的事了。

从0到1的数据基建，最忌讳的就是“大而全”。你一上来就要做全身CT、核磁共振，先不说花多少钱、多少时间，关键是很多部位拍了片子也看不出毛病，反而把真正有问题的那个穴位给淹没了。

针灸的思路是：找到最痛的那个点，一根针扎下去，用最小的代价，撬动最大的效果。

对应到数据基建，这根针就是北极星指标，而扎针的过程，就是下面这三步。

第一步：如何在1小时内锁定关键穴位

这一步的目标非常明确：在第一次跟老板聊数据需求的时候，就把他脑子里的北极星指标给“逼问”出来。

注意，我用的是“逼问”这个词。因为根据我的经验，绝大多数老板在刚开始聊数据的时候，脑子里是一团浆糊的。他只知道“我想要数据”、“我想看板”、“我想有掌控感”，但你问他具体要什么，他大概率会说“你先随便拉点数据我看看”。

你千万不能真的“随便拉点”。那是一个巨大的陷阱。你随便拉了一堆数据过去，他看了之后会提出更多更发散的问题，然后你就会陷入“拉数-发散-再拉数-再发散”的无限循环，永远走不出第一步。

正确的做法是，用一套结构化的提问方式，帮他把那团浆糊沉淀成一个清晰的目标。

第一问（定方向）：“老板，如果这个季度末，我们的业务只能有一个数字让你觉得‘这季度没白干’，这个数字会是什么？”

这个问题很关键。它直接把讨论从“什么数据都有用”拉到了“什么数据最重要”的层面。

很多人会问“我们的目标是什么”，这种问法太虚了，老板可能会回答“增长”、“活跃”、“赚钱”。但当你加上“只能有一个数字”这个限制条件后，他就不得不做取舍了。

他可能会说“那肯定是销售额”，也可能会说“日活用户数”，也可能会说“付费客户数”。不管他说什么，记下来，这就是候选的北极星指标。

第二问（定边界）：“这个数字如果下跌了，你第一反应会去看哪个环节？”

这个问题是用来验证第一步的，同时帮你拆解出支撑北极星的二级指标。

假设老板第一问答的是“销售额”。第二问他可能会说：“我会看流量有没有跌，转化率有没有跌。”

你看，这里已经蹦出来两个关键的方向了——流量和转化率。

假设他第一问答的是“日活用户数”。第二问他可能会说：“我会看新增用户够不够，老用户还回不回来。”

于是你又得到了两个方向——新增和留存。

第三问（定场景）：“你一般在什么情况下会想看一眼这个数字？是每天早上打开手机就想看，还是开会前想看，还是心里没谱的时候随时想看？”

这个问题看起来很随意，但它决定了你后续数据可视化的形态和更新频率。

如果他每天早上蹲马桶的时候就想看一眼，那你的产出物就应该是一个每天早上自动推送的微信卡片或者极简报表。

如果他只是在周一经营例会上需要，那你周末跑个数，周一早上发一张Excel截图就够了。

不要小看这个细节。数据产品的体验设计，起手式就是搞清楚用户的使用场景。

好，三轮问下来，15到30分钟，你应该已经拿到一个相对明确的北极星指标方向了。

接下来，你要花半小时，自己把这个北极星指标拆解成不超过3个原子指标。

什么叫原子指标？就是那种不能再拆的、可以直接对应到具体数据字段的指标。

我来给你三个典型场景的拆解案例，你看完就能套用。

场景一：内容社区（北极星：单日人均发帖量）

原子指标1：日活跃用户数（DAU）

原子指标2：单日总发帖量

原子指标3：人均发帖量 = 指标2 / 指标1

就这么简单。这三个指标一旦定下来，你要找的数据字段就极其清晰了：一个用户登录表（拿日活），一个帖子发布表（拿发帖量）。别的先不管。

场景二：电商初期（北极星：首单转化率）

原子指标1：落地页独立访客数（UV）

原子指标2：当日首次下单用户数

原子指标3：首单转化率 = 指标2 / 指标1

对应的数据字段：一个页面访问日志（拿UV），一张订单表（拿首次下单用户）。别的先不管。

场景三：SaaS工具（北极星：周活跃付费租户数）

原子指标1：付费租户总数（去重）

原子指标2：近7日有过登录行为的付费租户数

原子指标3：周活跃率 = 指标2 / 指标1

对应的数据字段：一张客户信息表（含付费状态），一张登录日志表。别的先不管。

你发现没有，不管什么业务，拆到最底层，你初期真正需要盯死的指标，不会超过一只手的手指头数量。

第一步的产出物应该是什么？

一张极简的业务地图

：就画三个圈，分别代表那三个原子指标，用箭头连起来，标注清楚计算逻辑。

一份写死了计算公式的指标定义文档

：比如“日活：统计周期内至少发生过一次登录行为的去重用户数。数据来源：user_login_log表”。

拿着这两样东西，你再去找研发提需求，底气是完全不一样的。你不是在说“我需要用户行为数据”，你是在说“我需要user_login_log表里的user_id和login_time两个字段”。

清晰，具体，不可拒绝。

第二步：如何用半天时间摸清家底

有了明确的目标指标，很多人的第一反应是：赶紧写需求文档，提给研发排期。

别急。

在你正式提需求之前，我强烈建议你先做一件事——翻垃圾桶。

别误会，这是个比喻。我指的是，去那些你觉得“不太正规”但实际承载了公司大量信息流转的地方，看看数据到底长什么样。

为什么要这么做？两个原因。

第一，降低研发的配合门槛。你直接丢过去一个需求单，研发一看，要接这个表那个表，还要做ETL，还要建调度，头都大了，本能反应就是“这个需求很复杂，得排到下个月”。但如果你能告诉研发“其实我只需要xx表里的两个字段，你帮我开个只读账号就行”，事情的难度就指数级下降了。

第二，发现那些隐藏的数据源。很多初创公司，真正的数据不在数据库里，在别的地方。

那具体“翻”哪些地方？

第一站：直接去查业务数据库（如果有权限的话）。

打开MySQL客户端，或者用公司现有的数据查询工具，针对你在第一步确定的原子指标，挨个确认：

这个表存在吗？

这个表里有没有我需要的那个字段？

这个字段的数据质量怎么样？是每一条都有值，还是大量为空？

数据是实时更新的，还是T+1更新的？

你不用把所有表结构都看一遍，你就盯着那三张核心表看。半小时足够了。

第二站：打开公司的共享文件夹，找那些“神一样的Excel”。

说出来你可能不信，很多公司的核心经营数据，最准的版本不在系统里，在财务或运营总监的Excel里。

有很多公司，订单系统的数据是乱的，但运营每天手动记的Excel表格，一笔不差。为什么？因为系统有各种异常订单、退款订单、刷单订单需要人工甄别，只有她知道哪笔是真的哪笔是假的。

所以，去问问那些在公司待得久的人：“咱们平时汇报业绩、算提成、分奖金的时候，最终以哪个数为准？”

那个数背后的Excel，就是你的金矿。

第三站：翻微信聊天记录。

搜索关键词：“昨天数据”、“日报”、“周报”、“曲线”。

你会发现，可能已经有人——可能是产品经理，可能是运营负责人——在定期手工产出一些数据截图了。他们可能每天早上打开几个后台，截屏，拼成一张图，发到高管群里。

找到这个人，请他喝杯咖啡。他能告诉你的东西，比十份需求文档都多。比如：老板真正关心的是哪个数？哪个数最容易被挑战？哪个数从来没人看？

这三个地方翻完，你手里应该已经有一份清晰的家底清单了。

我建议你把它整理成一张极简的《数据现状摸底表》，格式如下：

原子指标	需要的字段	是否存在	存放位置	数据质量初判	获取方式
日活用户数	user_id, login_time	是	user_log表	字段完整，无空值	开只读账号即可
总发帖量	post_id, create_time	是	post_info表	部分老数据无时间戳	需清洗历史数据
付费金额	order_amount	部分存在	订单表有字段，但大量空值；财务Excel有准确数据	系统数据不可用	先用Excel顶替