3. 通过什么方式发现问题与历史对比：是否符合历史惯例趋势，比如数据一直平稳波动还是突增or突降？
与同期对比：如周同期、月同期，年同期。比如2020年双11期间销售额较去年同期是涨了还是跌了？
与总体对比：比如某个sku盈利情况与所在品类盈利情况的对比，该sku对总体的的贡献率如何？
与竞品对比：与有相同应用场景、相同用户群体、存在竞争关系的产品进行对比，寻找差异点。
与目标对比：与公司目标、部门目标相匹配的可衡量指标进行对比，是否有跟着公司战略方向走？
与经验对比：以经验第一时间迅速洞察问题，比如双11某门店营收不升反降。经验不需要数据支持，但需要敏感的数据思维以及数据分析经验支撑。
与预测对比: 与预测数据的差距是否在正常范围内？
4. 问题拆解与归类工作中面对的问题大大小小会很多，即使是同一个问题也可能会被不同人的发起。每获取一个问题就记录下来，加以归类再去选择性的攻克。
常见的问题归类方式有：
按照四象限法则进行归类：紧急不重要、紧急且重要、不紧急不重要、不紧急重要
按照问题类型进行归类：交易相关、流量相关、用户体验相关、数据安全相关、财务数据相关……
按照优先级进行归类：P0（重要紧急，当前亟待解决）、P1（非紧急，可适当延后腾出时间优先解决P0）、P2（非紧急，可后续再做）……
有时候我们遇到的问题很棘手，大且复杂。一片迷茫，思维混乱。如何着手去解决？这时候，我们需要将复杂的问题“拆而解之”，而非将焦点浮在问题表面，把大问题围绕核心点拆解成可以行动的小问题，找到切入点。
打个比方，某个线上产品营收下降了10%，将10%拆解到各个子产品线、各个地区维度等，拆解出下降由哪方面带来，再针对性的逐个分析。
5. 站在业务角度想问题做分析，很容易陷入一个圈：为了分析而分析。
看到一个问题，会想可以用xx模型、xx技巧、xx模板来分析了。使用了一圈的技能，复杂的过程，密密麻麻的公式等，感动了自己，迷茫了需求方。不是说不能使用，而是要回归业务本质，先从业务角度出发，思考这个问题的价值。分析方法向业务靠拢，而非业务需求向分析方法靠拢。
了解清楚了问题的业务价值，以后最起码可以站在一个更高的公司策略层面的角度，谈论这个问题的核心意义。
我最初做分析的时候，就陷入了这种圈子。辞职的时候，跟领导说不想做这种只跟业务方打交道的分析，也没涉及任何模型，想去做涉及模型的分析。现在想来，好愚昧的想法。
做分析需求不一定需要复杂的模型，反过来，做模型一定需要深入了解业务知识，哪怕数据科学家这种对分析模型深入熟练的角色，也有着深入的业务了解程度。不管怎么说，深入了解业务，不亏。
发现问题之后，有了初步的方向，下一步就是需求确认。
二、 需求确认与梳理1. 确认需求背景了解清楚需求背景，才能明白这个需求的意义，是为了解决什么问题而出发的，不至于迷茫的做分析。需求背景就是需求产生的原因以及想要达成的目标。
需求产生的原因:当前现状是怎样的？为什么会提此需求？遇到了什么问题？
需求要达到的目标: 此需求期望在什么时间通过什么样的方式达到什么样的目标？（when、how、what）
2. 确认指标口径需要确认清楚这个需求涉及什么指标，哪些是核心指标哪些不是核心指标。每个指标的口径是什么，最近有没有更改口径。
比如客单价，即使大家都知道客单价=GMV/用户数，但是不能想当然以为需求方肯定知道，需求方也以为你肯定也知道，双方未核对口径直接开工干活。这样会存在两波客单价口径不一致的风险。分子什么维度、分母什么维度，都需要对清楚。
说白了就是，我以为你知道，你以为我知道，但是，咱们还是要对一下口径。
因为分析角色是干活的一方，需求方是发布需求的一方，所以面对需求，自身需要想的更多些，有些点需求方可能没想到，此时分析师需要具备更多的主动性。引导沟通、多方核对。毕竟，不沟通清楚需求直接干，容易背锅且被投诉，也竹篮打水一场空，浪费了时间。
所以前期不要怕沟通。最好是沉淀成文档，点对点沟通。
3. 确认数据维度数据维度可以理解为研究数据的角度，比如地区、城市、用户名等。
【 宏观|6000字干货｜数据分析需求处理详解