CASE分析是策略产品经理的基础工作，无论是搜索还是推荐、无论是线上广告和线下匹配。
业内普遍认为CASE分析认为是脏活累活。很多公司会以策略产品经理Title，招聘很多实习生做CASE分析和标注工作。很多初级策略产品经理的主要工作也就是CASE分析，做久了发现没有提升，对策略产品的工作了失去热情。
实际上，CASE分析是策略产品迭代的根本出发点，也是每个策略产品经理都应该坚持做的事。但是要让CASE分析发挥出应有的作用，还需要有配套的系统条件和科学的分析方法。
系统条件
要做CASE分析，首先需要完备的大数据系统。CASE分析需要抽丝剥茧，找到系统中的问题和解决方案，不可避免需要访问大量的系统数据。这需要做CASE分析的人可以方便地访问各种内部数据。大部分公司会使用Hive整合各种业务数据库，并提供对应的数据字典，方便各方通过SQL查询。
除了完备的大数据系统之外，还需要策略系统能够提供一些过程数据，用于查询和校验。什么叫过程数据呢？比如分析为什么给用户A推荐了某个看起来不相关的内容B，那么可能就需要了解内容B被什么规则召回、A的大数据平台。
分析方法
CASE分析从大的步骤上来讲只有三步：确定问题范围、定位问题原因、找出解决方案，但是每一步都需要非常多的经验积累和技巧。
确定问题范围是最容易被忽略的一步，尤其是面对一些外部反馈的CASE。
某搜索引擎的老板深夜看到自己微博下的一个搜索CASE反馈，错得比较离谱。但是产品经理查了下，一周只有几个搜索量，还算上老板和那个反馈用户，属于根本不重要的问题。然而在老板的重压下，工程师半夜起来加班连夜修复了这个只有几个人查询的CASE。
对于策略系统而言，一定会有各种各样的问题，而问题总是一个一个出现，要最大效率地对系统迭代，就需要想办法统计出来每一类问题具体的占比，不管是通过数据分析还是一些预估。然后根据覆盖率、严重性、问题解决难度综合确定解决问题的顺序。
定位问题原因需要对于系统逻辑有足够的了解。在很多公司，产品经理无法理解算法，即使有很好的数据系统，也无法自主定位问题。目前的各种算法涉及比较多高等数学的知识，传统意义上产品经理不需要理解这些知识，于是在很多公司从定位问题开始就已经属于工程师负责的范畴了。长期如此，产品经理只要就变成问题收集者以及与业务沟通的桥梁。
找到解决方案是基于问题定位的基础上，同时需要理解系统运行的内部逻辑，然后去对系统做出修正。这种修正可能是调整展示方式、增加数据源、调整业务规则，也可以能修改策略逻辑、权重配比、甚至是调整算法结构。在这些调整中，除了效果有限的展示方式调整之外，其他的调整都需要深入理解业务场景和算法逻辑。
进阶建议
公众号之前有一些提问，就是作为策略产品经理，做的事情都是基础的CASE分析，该怎么提升。其实方法很简单，那就是更深入地做CASE分析，从而逐步开始做更高阶的策略迭代。
对于有一定经验的策略产品经理而言，按图索骥去开展工作就好了。
如果缺少系统高效迭代的系统条件，就应该主动推动系统的建设。构建整合了全量数据的大数据平台，收集过程数据并且可以构建可以查询过程数据的内部平台，依据这些系统更深入地分析CASE。
自己主动分析CASE，也积极收集其他渠道的CASE反馈。面对新的CASE，确定问题范围、定位问题原因、找出解决方案。
积极理解所负责业务的内部算法逻辑，积极理解业务的各种决策逻辑，从而更好地做出融合业务和算法的产品方案。
当然，可能大家还是希望了解一些通用的算法系统知识，我们会在后续系列文章中进行更新。
