很多数据分析师深陷 SQL 工具人的困境，只会罗列数字却拿不出业务认可的产出，频频遭遇业务端的质疑。本文从建立业务假设、优先解决显性问题、用数据测算支撑决策、监控排查新问题四个核心步骤，拆解如何让数据分析真正落地业务，摆脱单纯的搓数工作。
“你只是罗列数字，你的分析建议是啥？”
“你有没有提出对业务有用的建议，落地了没有？”
很多人听到上边的质问就头皮发麻。名为数据分析师，实则是SQL工具人，每天搓数却没有业务认可的产出，是数据人最怕的事。该如何从数据到业务落地？今天一文讲清楚，同学们记得点个赞，慢慢看哦。
首先，分析问题时，不能只停在数字表面。比如分析“业绩下滑问题”，很多人习惯性的只看销售收入数据，把收入拆成：客户数*转化率*客单价，再按地区/客群做个拆分就算完工了（如下图）。
此时的分析是很浅的，即使看到了“老客户消费率下滑”，也能只能写一句：“要搞高”，不能指导任何业务动作。做分析，要先落实到具体的业务假设，比如：
……
这样具体的假设，能指向：解决客户投诉/调整价格/提高服务等具体动作，至少到这一层，才让数据和业务建立联系。有人会说：我的销售数据表里没这些字段，咋办！谁规定了做数据分析只能用一张表的……结合业务假设，综合利用企业各种数据，也是数据分析的职责，具体的，往下看。
当假设很多的时候，根据数据详细程度，列出解决问题的顺序，是最重要的工作。问题明显的，容易排查的，优先解决。从简单到复杂，逐步解决问题。
比如在上例中，我司CRM系统有客户回访记录，可直接查询到：“客户本月营业状态”，那么直接把这个数据同销售记录关联起来用。此时，可以做如下图区分。
当数据指向一个可落地的业务动作时，就能停止拆分了。比如：
这两条举措都可以落地，此时可以停止拆分。
这里也可以做的更细，比如：不同客户的旺季，时间节点不一样。比如都是暑期旺季，游戏、旅行行业可能和学校放假有关，空调、冷饮可能和气温（小暑/大暑）有关，根据客户历史交易数据+今天气象预报/学校放假时间，做个更细的拆分，提前提醒业务部门，也是OK的（如下图）。
类似的，可以进一步细分客户情况。比如从客服系统里调客户投诉记录，查看：是否我司有问题，引发客户投诉，进而导致客户没有付费。此时，我们可以进一步丰富我们的分析逻辑树，逐步解决问题（如下图）。
看到：“我司出现问题”，很有可能你会直观的想到一条对策：“给客户赔钱！”所有涉及价格/补贴/利润的方案，都要做数据测算，避免盲目给优惠导致亏损。
此时可以从OMS系统调客户历史交易数据，计算：
从而估算出客户贡献的利润高低，进一步支持业务判断：是否值得给客户赔钱，吸引客户复购。并且可以进一步做价格弹性模型（如下图），支持业务做弹性测试，测测看不同方案的效果差异。
理论上，我们可以持续拆分问题，直到各类问题都有明确的业务对策。这样就实现了从数据到业务的落地。本文这里就不赘述后续拆分过程。
要强调的是：做问题拆分并不是分析的终点。在分清问题以后，可以设定监控指标，观察问题结构的变化。有可能随时间变化，问题的重点已经转移，此时要更换策略。
比如在上例中，我们发现：刚开始的时候，业绩不好主要问题是“客户自身处于淡季”，此时说明我司存量客户结构单一，集中在同一类行业，应努力扩展客户。之后，主要问题变成了“竞争对手价格更低”，此时价格战压力很大，可能要考虑如何控成本，以应对价格战（如下图）
综上可见：企业的数据分析工作，不是解数学题。不是先有一个考试卷子，写清楚了所有条件，然后我们来答题。而是需要我们自己：
这样才能做出高质量的分析，而不是困在SQL里当工具人。
本文由人人都是产品经理作者【接地气的陈老师】，微信公众号：【接地气的陈老师】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。