关于实际业务中的数据分析

有过很多关于数据分析的文章，里面会对某个业务场景进行建模和处理。在接触实际业务后，发现这些分析内容，从方法论和模型上并没有什么问题，但是处理的业务场景却过于简单了，实际当中，方法和模型甚至要更普通和弱化，但对业务场景的抽象却远远比纸上谈兵中所说的那些复杂的多。

很多时候我们在公众号里看别人写的内容，会以一个“出现A → 从而B → 所以C”的这种模式去开展ta的论述。这样的分析思路没有问题，但是在实际中仅仅做到这样的分析是不够的。在实际业务中，“出现A”从来都不是一个事件真正起始环节，在分析的时候，往往会构成的关系链是“出现A → 分析为什么出现A而不出现B、C、D → 是由E导致A出现 → 如果不是E而是F、G、H，是不是会导致出现B、C、D → 是否还要继续看什么导致E出现 → 由于出现A从而I，但为什么不J，K → 如果出现J，K，说明A什么问题 → 当前出现的是I，所以才会有L，那么由A到L，为什么是最终的路径”。

这种关系链抽象起来确实比较难理清，但是仔细整理可以看出，实际业务中的数据分析往往不是为了解决问题，而是为了弄懂问题。解决问题只要顺藤摸瓜即可，但弄懂问题则需要来来回回反反复复，做向上的回溯，和向下的钻取，以及横向的比对，各个维度各个方向都要考虑上。既要弄清楚一件问题为什么会出现，还要弄清楚是什么导致了这个问题出现，以及这个问题出现之后会怎样，如果不是这个问题而是其他问题出现，又会怎样等等。实际业务中并不是以解决问题为数据分析的唯一目的，解决问题只是其中的一部分，而更多地是对问题进行全方位的探索，从而造成较高的业务复杂性。

如果将这种业务复杂性映射到SQL上，就会更好让大家理解。一个查询取数任务，在很多数分文章里，可能join的表不会超过5个，因为都是按顺藤摸瓜的思路以解决问题作为路径去完成。但实际当中join的表很多时候都以两位数来计算，并不是说解决这个问题需要用到的表真的这么多，而是弄清这个问题的前因后果来龙去脉，需要用到很多表。举个例子，解决一个转化率下降的问题，可能顺着这条转化链去取相关的表和数据即可分析是在哪个转化环节出了问题。但实际业务中，除了顺着转化链去取数据，还要和产品、运营、技术、设计、物流等业务部门沟通，从产品中取最新的产品迭代数据，从运营中取最新的运营活动数据，从技术中取近期相关的异常bug和功能优化数据，从设计中取日常APP美化和反馈数据，从物流中取相关时间段内的流通数据等等。因为一个简简单单的转化率下降，并不是只用看直接原因（转化链上的变化），而是既要看直接原因，也要看间接原因，看与之相关的所有，才能全方位地对一个问题做出解析，给出最合理的数分结论。