1. 为什么接需求前要先分型：数据分析项目的地基问题
在数据运营的日常工作里，我见过太多类似的情况：业务方跑过来丢一句"帮我看看这个数据怎么回事"，等你折腾两天把数提出来，对方又说"这不是我要的，我是想知道接下来该怎么办"。问题出在哪？出在接需求时没有先判断——这到底是一个什么类型的数据分析项目。
数据运营手里的分析需求五花八门，有的是"把本周核心指标做个汇报"（描述），有的是"转化率突然降了帮我查原因"（诊断），有的是"下个月的投放预算怎么分"（预测+规范），有的是"新用户首单率太低，怎么办"（诊断+规范）。这些需求看起来都叫"数据分析"，但分析目标、方法路径、交付物、时间成本完全不同。把类型搞错，后面每一步都会走偏——该给结论的时候给了一堆报表，该排查根因的时候只做了趋势图，该预测未来的却只复述了过去。
所以我在带人做数据运营时，第一课永远是"分型"。不是学工具，不是记指标，而是先建立一套判断框架：拿到任何一个需求，先归类，再动手。这套框架分两个维度：一个是按分析目的分，回答的是"这次分析要解决什么认知问题"；另一个是按业务场景分，回答的是"业务方在哪个环节需要数据支撑"。两个维度交叉，基本能覆盖日常工作中百分之八九十的分析项目。
这篇先讲按目的分的四类项目，以及按业务场景分的第一批常见类型。目的维度的四类是骨架，场景维度的各种类型是血肉，把骨架立起来，后面学场景才不会乱。
2. 按目的分四类：描述、诊断、预测、规范，它们的方法和产出完全不同
2.1 描述性分析：把"发生了什么"说清楚并不简单
描述性分析是所有数据项目的起点，回答的问题是"发生了什么"。上周活跃用户多少？本月的GMV环比涨了多少？各渠道的点击量怎么分布？这些都是描述。
描述性分析看着最简单，其实最容易出问题。最大的坑不是不会算，而是口径不统一。我遇到过不止一次：运营说的"新增用户"按设备号去重，产品说的"新增用户"按账号去重，技术说的"新增用户"按注册时间统计，三份数据放到同一张会议上，数字对不上，会议直接变成扯皮现场。所以做描述性分析之前，第一件事永远是确认口径：时间范围怎么定义、去重键是什么、包含不含测试数据、异常值怎么处理。
描述性分析常用的方法也很基础，但要用对：趋势对比（看连续变化）、同环比（看季节性规律）、结构拆解（按渠道、地区、商品类目等维度拆分看构成）。输出物一般是日报、周报和可视化看板。
很多新人觉得描述性分析"没技术含量"，我完全不认同。把"发生了什么"用数据精准、无歧义、可追溯地表达出来，是后面所有分析类型的地基。诊断要建立在准确的描述上，预测要依赖历史描述的数据质量，规范建议也要基于描述提供的现状信息。地基歪了，盖什么楼都会塌。
2.2 诊断性分析：异常波动排查是最能拉开差距的项目
诊断性分析回答的是"为什么发生"，它是数据运营日常里最考验功底的一类项目。典型场景：DAU连续三天下降、下单转化率跌破历史低点、某渠道投放突然没有回报。
诊断分析的核心是建立排查链路，而不是直接找答案。我自己的排查习惯是先分层、再拆维度、最后落细节。
先说分层。以"DAU下降了"为例，先拆成三块：是新增用户少了，还是老用户留存变差了，还是流失用户回流变少了？这一步把一个大问题拆成几条互斥的路径，目的性立刻清晰。
然后是拆维度。比如发现是"新增用户少了"，再拆：是哪个渠道少了？哪个地区少了？哪个设备类型少了？是iOS少还是Android少？是哪个版本迭代后开始的？这一层拆下来，问题基本能锁定到某个具体人群和来源。
最后是细节确认。锁定到"某渠道的新增量从某天开始减少"之后，再去看对应渠道是不是改了投放策略、出了素材事故、或者竞品同时段在抢量。这时候所有推断都必须落到可验证的证据上，而不是"我觉得可能是"。
诊断类项目的方法论核心是对比：与同期比、与上一周期比、与对照组比、与历史最好最差比。没有对比的诊断都是讲故事。输出物通常是一份诊断报告，必须包含"现象—排查过程—根因结论—佐证数据"四个部分。很多分析报告写不好，就是因为只写了前两个部分，根因靠猜、佐证靠嘴。
2.3 预测性分析：给未来一个可验证的区间
预测性分析回答的是"将会发生什么"。这类需求在业务中越来越常见：下个月的DAU大概是多少、这批投放能带来多少新增、季度末能不能完成业绩目标。
预测性分析跟前面的描述、诊断完全不同，它的本质是基于历史规律外推未来，所以对数据的时间跨度、稳定性、外部变量都非常敏感。方法上常用时间序列、回归模型、生命周期模型，但比方法更重要的是对数据基础的判断：数据至少要有足够长的历史周期，业务不能刚发生过重大变化（比如刚上大改版、刚换投放策略），否则外推的假设本身就不成立。
我在实际做预测项目时有个深刻的教训：预测一定要给区间，不要只给单点值。刚开始带项目时，我习惯预测"下月DAU是100万"，结果业务方拿着这个数去做资源准备，实际只有92万，所有人都觉得我预测错了。后来我改成"中性预期95万，浮动范围90万到102万，前提是保持当前的投放节奏和转化水平"，虽然表述变复杂了，但业务方反而觉得更靠谱。因为预测的价值不是精确到小数点，而是让决策者有一个提前量的判断，并且清楚这个判断在什么条件下会失效。
预测性分析的输出物除了预测数值本身，还必须写清楚三件事：预测使用的模型或逻辑、关键假设、可能造成偏差的风险点。这三件事缺一个，预测就变成了"拍脑袋的数字"。
2.4 规范性分析：从分析走向建议的最后一公里
规范性分析回答的是"接下来该怎么做"，这是数据分析里离业务决策最近、也最难做的一类。它不仅要回答现状和原因，还要基于分析给出行动建议、方案评估甚至最优选择。
典型的规范性分析场景：预算有限，三个渠道怎么分配；用户流失率偏高，先做召回老用户还是先优化新用户体验；两种活动方案，选哪个更可能达成目标。这类项目的难点在于，分析只是前半段，后半段还要进行策略设计、测算和取舍。
做规范性分析时，我最常用的是场景测算：把问题简化成几个可比较的场景，每个场景给定输入变量和约束条件，算输出结果。比如投放预算分配问题，先把各渠道的历史转化率、平均客单价、边际成本列出来，然后设定三个分配方案，分别测算ROI和总收益，再结合业务方对不同目标的权重倾向，给出排序建议。
要注意的是，规范性分析输出的"建议"必须附带成立条件和不确定性。我见过不少分析同学在建议部分翻车，原因是把复杂决策简化成了单维度判断。比如"只看ROI就建议全部投渠道A"，但没考虑渠道A的流量天花板和长期成本增长。好的规范建议应该是：在什么条件下首选哪种方案、风险和副作用是什么、有没有备选路径。
2.5 四类项目快速对照表
为了方便日常判断，我整理了一个对照表，新人可以直接拿来当参考：
| 类型 | 核心问题 | 常用方法 | 典型输出 | 典型周期 |
|---|---|---|---|---|
| 描述性分析 | 发生了什么 | 趋势、对比、维度拆解 | 日报周报、看板、汇报PPT | 小时到周 |
| 诊断性分析 | 为什么发生 | 分层定位、多维拆解、对比验证 | 诊断报告 | 数小时到数天 |
| 预测性分析 | 会发生什么 | 时间序列、回归、生命周期模型 | 预测区间、风险提示 | 半天到一周 |
| 规范性分析 | 我该怎么做 | 场景测算、实验设计、最优选择 | 策略建议、方案对比 | 数天到数周 |
这个表看起来简单，但价值在于提醒自己：不同类型项目的交付物完全是两回事。把"为什么"做成"发生了什么"，交付再美观也是白做；把"怎么做"做成"为什么"，给再多原因也不会被采纳。
3. 按业务场景切分：从需求方的语言出发识别项目类型（上）
3.1 用户分析类：研究对象是人，不是指标
按业务场景分，用户分析类是我认为最常遇到、也最值得系统掌握的类型。它的研究对象不是某一块业务，而是人：用户是谁（画像）、用户怎么分层（分群）、用户处于什么阶段（生命周期）、哪些用户要流失（预警）。
用户分析类项目经常被误解为"拉一堆用户标签出来"。但真正做好用户分析，重点在分层逻辑和生命周期视角，而不是标签数量的堆积。
举个例子，某SaaS产品做用户流失分析。需求方最初说"把流失的用户画像拉一下"，如果只按"所有流失用户的平均注册时长、平均功能使用次数"来拉，最后得到的画像毫无区分度——因为平均值掩盖了不同流失路径的巨大差异。正确做法是先给流失定义一个可落地的标准（比如连续30天未登录、且未发起任何核心操作），再按用户的价值层级（高价值客户、普通客户、试用客户）分别追踪流失前的行为序列，最后才能得出"高价值客户流失前两周的某个关键功能使用率显著下降"这样真正有业务含义的结论。
用户分析类的常用方法包括：RFM分层、用户生命周期划分（新用户、成长用户、成熟用户、衰退用户、流失用户）、行为分群（基于使用频次和深度组合分群）。输出物一般是用户画像报告、分层分群表、流失预警规则。
我做用户分析最大的体会是：任何用户分析项目，都必须先把"研究对象是谁、边界是什么"定义清楚。"用户"在电商里是买家人，在内容产品里是阅读者，在SaaS里可能是管理员账号、企业付费账号、普通员工账号，研究对象定义错了，后续所有分析都会失真。这也是为什么这类项目初期沟通的时间成本特别高，但省不掉。
3.2 渠道与流量分析类：回答钱花得值不值
渠道与流量分析类项目，业务方最常问的一句话是"钱花得值不值"。这类项目在投放型业务中占据数据运营很大的工作量，涉及渠道监控、质量评估、预算分配和归因逻辑。
渠道分析的基础是一组连环指标：曝光量、点击量、下载/落地页转化、注册/激活、首次付费、次留/七留、LTV。只看最前面的曝光和点击，会严重误判渠道价值；只有把后面留存和LTV接上，才能知道这个渠道带来的是高质量用户还是"羊毛党"。
我曾给某电商APP做过一次渠道评估。当时A渠道带来的首日ROI是1.8，B渠道只有1.2，投放团队据此想把预算大部分转给A。但把观察周期拉长到60天，按LTV重新计算ROI后，B渠道的长期收益反而更高——因为A渠道的用户次留和90天复购率明显偏低，首日的高转化主要是由一次性福利刺激出来的。这就是典型的把描述性分析当成规范性分析的错误：只看首日ROI是描述现状，不回答"该不该加预算"，必须加上长期价值测算才能支撑预算决策。
渠道分析类项目里不得不提归因问题。用户的转化路径通常要经过多个渠道触点，归因给谁、按什么权重分配，直接决定每个渠道的ROI数值。常用归因模型有末次点击、首次点击、线性归因、时间衰减归因等。没有绝对正确的归因模型，只有跟业务模式匹配的归因模型：品牌认知类投放适合首次点击或位置归因，效果类投放适合末次点击。这个口径必须在项目初期就明确，否则渠道之间互相争功扯皮是常态。
渠道与流量分析类的输出物，日常是渠道监控日报/周报，专题则包括投放效果复盘报告、渠道质量评估表、预算分配建议方案。这类项目的核心价值，是让投放决策从"感觉这个渠道效果好"变成"这个渠道在什么条件下、对哪类用户、带来多少长期收益"。
4. 接到需求后的五个问题与类型映射清单
4.1 收齐背景的五连问
无论需求方描述得多简单，我在动手提数之前都会先问五个问题。这五个问题不是走流程，而是为了把项目类型定准、避免返工。
第一个问题：这个数据最终要支持什么决策？比如是要在周会上汇报现状，还是决定砍掉某个渠道的预算，还是判断要不要上线某个功能。目的越具体，类型越明确。回答"只是想看看"的基本是描述性项目；回答"因为涨跌异常"的是诊断项目；回答"要分配预算"的是规范项目。
第二个问题：底层数据现在是现成的，还是要重新取数？这决定了项目的时间投入和数据基础。如果数据没有埋点、没有历史记录，那么即使是诊断或预测需求，第一步也得先做描述性的数据准备。
第三个问题：你要的是单次分析，还是长期监控？单次分析适合用专题报告交付，长期监控则要考虑做成报表或看板，甚至固化成数据产品。这个区别直接影响交付物设计和后续维护成本。
第四个问题：时效要求是什么？是"下班前要"，还是"本周内"，还是"这个季度内顺便看"。时效紧的分析项目只能优先用现有数据和快捷方法，时效宽松的可以上更完整的方法和建模。
第五个问题：需求方有没有预设的假设？比如"我觉得是上次版本更新导致转化率下降"。有预设假设不一定是坏事，但要把假设当作待验证项，而不是分析结论。我会明确告诉需求方：假设可以写进去，但最终结论以数据验证为准。
4.2 需求映射到类型的自查表
五连问问完之后，我会把需求做一次映射，判断它属于哪种类型组合。下面这个自查表是我常用的：
| 需求方的表述 | 主要类型 | 可能包含的次要类型 | 对应的核心交付物 |
|---|---|---|---|
| "帮我把本周的数据汇报一下" | 描述 | 无 | 报表/汇报PPT |
| "DAU掉了，帮我看看怎么回事" | 诊断 | 描述（需要先描述变化过程） | 诊断报告 |
| "预估一下这个月的GMV能不能达标" | 预测 | 描述 | 预测区间报告 |
| "三个渠道预算怎么分" | 规范 | 描述+预测 | 方案对比与建议 |
| "想了解我们的核心用户长什么样" | 描述 | 诊断（为什么这些用户有价值） | 用户画像/分群报告 |
| "活动做完了，帮我复盘一下" | 描述+诊断 | 规范（下次活动建议） | 活动复盘报告 |
这个自查表的价值在于，它把模糊的业务语言翻译成可执行的分析语言。拿到需求先过一遍这个表，就能知道该往哪个方向使劲，避免一开始就往工具和代码里钻。
4.3 最容易踩的三种误判
第一种误判是把诊断需求接成了描述需求。常见的表现是：业务方问"为什么转化率降了"，分析同学花两天做了一个非常精美的转化率趋势看板，把下降曲线画得清清楚楚，但既没有定位到具体环节，也没有排查到变化起点。看板描述了"降了多少"，却完全没回答"为什么降"。这种交付在业务方眼里基本等于没做。
第二种误判是把预测需求做成了历史复述。业务方问"年底能不能达成目标"，分析同学拉出历史十二个月的业绩表，说"过去一直呈上升趋势，所以按趋势看能达成"。这不是预测，这是把过去背了一遍。真正的预测至少要基于驱动业务的核心变量（活跃用户规模、转化率、客单价）做推演，并说明关键假设。
第三种误判是在诊断还没做扎实的情况下直接给建议。有些分析同学悟性高，拿到异常数据马上就能冒出好几个猜想，然后直接跳到一个看起来合理的建议上。但跳过验证环节，往往会被打脸。我自己的血泪经验是：诊断没穷尽现象之前，一切建议都不要写进报告里。先把"是什么、在哪、何时开始"都说清楚，再谈"为什么、怎么办"。
5. 不同类型项目的产出形态、时间节奏与优先级经验
5.1 日常监控型与专题分析型的交付差异
不同项目类型对应着完全不同的产出形态和协作节奏，如果这个匹配错位，双方都会很痛苦。
日常监控型项目（大概率是描述性分析）讲究轻、快、稳。交付物是日报、周报、自动化看板，更新频率固定，指标口径一旦确认就尽量不变。它不需要写长篇报告，但要保证数据每天定时更新、异常能够预警、任何指标变化都能回溯。这类项目最大的成本在前期自动化和口径梳理，运行起来后维护成本很低，但新人接手时最容易疏忽的是"口径变更了没同步给使用者"——指标数字前后对比不一致，信任就崩了。
专题分析型项目（诊断、预测、规范都有可能是专题）讲究深、透、实。交付物是一份结构完整的分析报告，周期通常数天到数周，需要跟需求方多次对齐。专题型项目不一定用复杂的模型，但一定要把逻辑闭环：问题定义 -> 数据准备 -> 分析方法 -> 结论 -> 建议 -> 可落地动作。我写专题报告的固定结构是：先说核心结论（一句话），再给支持结论的三到五个关键证据，然后是详细的排查或分析过程，最后才是附带行动建议。业务方普遍很忙，结论前置是尊重对方时间的做法。
5.2 分析模型与数据产品的固化边界
当一个分析项目的价值被反复验证之后，就应该考虑把它固定下来，从"每次临时分析"变成"持续可复用的数据产品"。
比如用户流失预警，刚开始是诊断项目，后来每次做流失分析都要重复一遍，那就把它固化成自动化的流失预警报表：每天产出高危流失用户名单，推送给运营跟进。渠道质量评估也一样，从每个月人工跑LTV，固化成自动计算的渠道质量看板，投放团队可以随时自行查看。
但固化不是无条件的。我判断一个分析能否固化成数据产品，有三条标准：一是业务场景足够稳定，不会一两个月就变一次口径；二是分析逻辑足够标准化，可以描述成一套固定规则；三是有持续的使用方和维护人。很多分析项目固化失败，是因为场景本身还在快速变化，固化成产品反而变成包袱。
我自己踩过的坑是过早追求"自动化"。一个诊断类项目刚做了一次，还没验证逻辑是否稳定，我就急着写SQL存成定时任务，结果业务口径连续调整，每次都要改底层逻辑，维护成本比手工分析还高。现在的做法是：先手工跑两到三次，确认分析逻辑和业务认知一致，再考虑固化。
5.3 我的优先级排序方法
最后分享一个我用得非常顺手的优先级判断方法。当手里同时压着多个分析项目时，我按两个维度排序：决策影响面和时效性。
决策影响面大的（比如影响几百万元预算分配、影响核心功能是否上线的项目）排在最高优先级。决策影响面小但时效紧的（比如周报数据临时变动），能快速处理就快速处理，无法快速做的就跟需求对齐给一个明确的截止时间，而不是闷头赶工。
还有一个容易忽略的原则：先做能解锁后续工作的项目。比如一个新的诊断项目需要先补齐一笔数据口径，那这个口径梳理任务的优先级就应该被提高，因为它是关键路径。业务方看不到这种"内务型"任务的价值，但这是保证长期效率的关键。
我用一个简单的四象限顺序做内部排序：高影响+高时效 > 高影响+低时效 > 低影响+高时效 > 低影响+低时效。这个排序不完美，但比"谁的嗓门大先做谁"要靠谱得多。
最后分享一点个人体会。做数据分析项目，最大的成就感不是把图表做得漂亮，也不是模型跑出多高的精度，而是你能清楚地告诉业务方"这事分几种情况，每种情况我们该怎么应对"，并且得到对方的认可。要达到这一步，前端是技术和工具，后端其实是这套分型思维——它在项目开始前就替你规划好了路径，让每一步都走在正道上。下一步我的计划是把活动分析、商品/内容分析这些场景类型逐个展开，再配合具体案例讲如何把"类型方法论"落到真实数据里。
