1. 概述
作为一名数据分析师，你日常一个重要的工作就是根据业务需求，设计和制作看板，为业务方提供数据指引。
需求处理阶段包括三阶段：发现问题、需求确认、需求处理。
实际工作中，「问题」可以是领导或者业务方直接抛出，也可以是自己主动发现。但不管哪方发起，思考问题均离不开数据分析思维的支撑。
2. 发现问题
数据分析的核心目的就是发现问题和解决问题。
有时候业务提出的分析需求，可能只是一个个人的设想，作为分析师，需要有独立判断的能力，帮助提出问题的人梳理清楚问题，从而更好的进行问题解决。
有效问题的5个特点：
1）是否有价值
此“价值”是建立在公司利益之上的。有价值的问题并不是说角度新颖、前所未有，而是触及到了公司的重要层面。
该“问题”是否与公司、部门的OKR相关，是否有跟着公司的整体方向走。比如某个产品已经流量见顶了，公司整体策略由之前的拉新获客变更为提升活跃留存、维护老客，那么即使产品的用户体量趋势即使逐渐趋于平稳，孛离公司整体策略，也不需要再在这上面过于下功夫研究探索。
2）是否涉及核心指标
首先需要熟悉公司有哪些指标，尤其是核心指标具体是哪些。其次，需要继续了解这个问题是否涉及核心指标，且涉及了哪些核心指标。
3）是否影响面广
是否关系到公司的整体策略？这个问题如果不解决的话，会产生多大的影响？如果解决了的话，会有多大的利好？
4）是否可规避
受宏观影响还是微观影响？无法避免还是本可避免？
若这个问题受宏观政策的影响，比如疫情原因导致的线下门店销售下滑，再比如国家出台政策规定篇p2p年化利率最高36%，这是宏观因素，不可避免；宏观因素下，公司业绩指标变化较大，原因众所周知，且无法规避。此时单纯研究这个问题则意义不大。
若这个问题未受宏观影响，比如，某个产品的最近复购率下降，宏观上并未有任何政策影响，就莫名其妙的复购下降了，此时需要深入探索是不是产品本身存在了问题，还是竞品导致，或是其他。这个问题可以说是本可规避但未规避。
5）是否有时效
时效性的理解就是，如果这个问题现在不解决，对业务后续发展会产生一定的影响。
比如，研究前年10月销售下跌的原因则没必要，要保证数据与时俱进，避免数据过于陈旧；再比如，当前时间节点若是处于市场竞争激烈的态势，则需实时把握产品的数据变化，及时发现问题并解决，当前的问题延期到未来作用性衰减。
2.1 通过什么方式发现问题
与历史对比：是否符合历史惯例趋势，比如数据一直平稳波动还是突增or突降？
与同期对比：如周同期、月同期，年同期。比如2020年双11期间销售额较去年同期是涨了还是跌了？
与总体对比：比如某个sku盈利情况与所在品类盈利情况的对比，该sku对总体的的贡献率如何？
与竞品对比：与有相同应用场景、相同用户群体、存在竞争关系的产品进行对比，寻找差异点。
与目标对比：与公司目标、部门目标相匹配的可衡量指标进行对比，是否有跟着公司战略方向走？
与经验对比：以经验第一时间迅速洞察问题，比如双11某门店营收不升反降。经验不需要数据支持，但需要敏感的数据思维以及数据分析经验支撑。
与预测对比: 与预测数据的差距是否在正常范围内？
2.2 问题拆解与归类
常见的问题归类方式有：
按照四象限法则进行归类：紧急不重要、紧急且重要、不紧急不重要、不紧急重要
按照问题类型进行归类：交易相关、流量相关、用户体验相关、数据安全相关、财务数据相关……
有时候我们遇到的问题很棘手，大且复杂。一片迷茫，思维混乱。如何着手去解决？这时候，我们需要将复杂的问题进行拆解，而非将焦点浮在问题表面，把大问题围绕核心点拆解成可以行动的小问题，找到切入点。
打个比方，某个线上产品营收下降了10%，将10%拆解到各个子产品线、各个地区维度等，拆解出下降由哪方面带来，再针对性的逐个分析。
2.3 站在业务角度想问题
做分析，很容易陷入一个圈：为了分析而分析。
看到一个问题，会想可以用xx模型、xx技巧、xx模板来分析了。使用了一圈的技能，复杂的过程，密密麻麻的公式等，感动了自己，迷茫了需求方。
而对于需求方，在实际业务中其实并没有办法使用。
因此，从实际业务需求想问题，哪怕只是做了一些很基础的分析和计算，也可能会给业务带来很大的便利。
发现问题之后，有了初步的方向，下一步就是需求确认。
3. 需求确认与梳理
3.1 确认需求背景
了解清楚需求背景，才能明白这个需求的意义，是为了解决什么问题而出发的，不至于迷茫的做分析。需求背景就是需求产生的原因以及想要达成的目标。
需求产生的原因：为什么会有这样的需求？
需求要达到的目标：此需求期望在什么时间通过什么样的方式达到什么样的目标？
3.2 确认指标口径
需要确认清楚这个需求涉及什么指标，哪些是核心指标哪些不是核心指标。每个指标的口径是什么，最近有没有更改口径。
比如客单价，即使大家都知道客单价=GMV/用户数，但是不能想当然以为需求方肯定知道，需求方也以为你肯定也知道，双方未核对口径直接开工干活。这样会存在两波客单价口径不一致的风险。分子什么维度、分母什么维度，都需要对清楚。
因为分析角色是干活的一方，需求方是发布需求的一方，所以面对需求，自身需要想的更多些，有些点需求方可能没想到，此时分析师需要具备更多的主动性。引导沟通、多方核对。毕竟，不沟通清楚需求直接干，容易背锅且被投诉，也竹篮打水一场空，浪费了时间。
3.3 确认数据维度
数据维度可以理解为研究数据的角度，比如地区、城市、用户名等。
需要向需求方了解清楚:
需要什么维度的数据？
此维度按照什么方式聚合？
去重还是非去重？
直接聚合还是累积聚合？
……
3.4 确认底层逻辑
需求方提需求，一般只会讨论需求详情，但是需求怎么做，数据从哪里获取，他们不需要关心。
比如，需要看某个商品的七日复购率，数据库表中有七日复购率指标么？若有指标口径是否和需求方的口径一致？若无，需要从哪些数据库表进行关联得到所需数据？自己关联计算的逻辑需要数仓落表还是直接应用？
3.5 确认需求排期
在了解好需求后，需要根据当前的人力进行需求排期，确定完成需求的时间。
3.6 确认数据安全
分析师可以接触到很多底层数据，所以需要有数据安全意识。有的公司划分比较严格，某个模块的需求专门安排某个分析来一一对接。但有的公司没这么严格，所以需要判别下需求方是否可以查看该数据。
1）需求方是否可查看该数据
即使是同一个公司的人，各自的数据权限也并不一样，一般不允许非必要性情况下获取本职工作以外的数据。比如，两个部门做着类似的产品，有着类似的用户群体，也背负着各自绩效，数据不能相通。
但对方都是希望可以获取另一方数据来做对比，这种情况有的公司不被允许。分析师自然也要判别这种情况，该给给，不该给则果断拒绝这个需求。
2）明细数据是否涉及数据安全
另一方面，需求方有时候需要明细数据，即数据粒度较细的非聚合数据，比如ods层、dwd层的数据，还需要判别下是否能够提供明细数据。有的公司明细数据会受到公司安全部门的监管。毕竟，明细在手，各种角度的分析都能搞。
上一篇：排查异常指标
