对产品经理来说，尤其是大公司里的策略产品经理，每一次的策略改进都需要拿出实实在在的证据来说明新策略的效果。有时候，新策略有好的效果，这当然是我们希望看到的，但有时候也会失手。但是无论数据是否好看，你都需要拿出准确可信的数据来说明策略的效果，并根据评估效果做出最终决策，效果优则使用，效果劣则改进。而能让你做出靠谱决策的基础，就是靠谱的效果评估。
一个靠谱的效果评估，首先要有明确和合理的评估标准，为了给后续评估相关的工作提供指导，这个标准甚至是在设计策略之前都已经确定了的。评估标准规定的是我们用哪些维度的数据来体现策略的效果，如果说策略的优化是不断的朝着一个方向前进，那么评估标准就是指引前进方向的路标。正是因为评估标准的路标属性，所以明确、合理是对评估标准的基本要求。明确是指方向是唯一的，或者有时候是主要方向是唯一的，这个方向，一般也是和策略改进的方向一致的。比如策略产品常见的策略优化目标点击率、使用率、转化率等等。合理是指评估的数据维度是和策略产品目标高度相关的，如果你的策略优化的是列表的展示顺序，那你就不能把列表召回的内容质量作为评估标准。
评估标准确定之后，后续就是贯穿产品策略上线前后的评估过程，主要包括效果预估、离线评估、线上评估三步。
效果预估是产品经理根据项目的性质，借鉴已有的一些数据，在项目还没有启动之前做的对策略效果的一个大致评估。比如，我们需要对用户搜索A类关键词无结果的情况做优化，这种词的搜索比例是10%，而与A类词相似的B类词的搜索结果到支付的转化率是8%，那么策略上线之后影响范围是10%的搜索次数，再预估A类词搜索结果到支付的转化率也是8%，那么理论上，策略上线之后能够提高10%*8%的转化率。
从性质我们就可以知道，这种预估是不可能完全准确的，但是，无法准确绝对不是不去做效果预估的借口。效果预估的值是一个策略效果的基准线，它能够为策略完成上线之后的效果提供一个对比标准，以直观的说明新策略是否有效，或者更功利的去说，效果预估往往是项目立项的数据支持，甚至会成为你的KPI。
离线评估是策略上线的最后一道检验程序，离线评估效果的好坏决定了策略是否有上线策略测试的机会。
离线评估有两种方式，一种是最原始的人肉检查，一种是机器评估。
人肉检查好理解，这就是凭人眼对策略生效场景一个个（Case By Case）的去验证。以前面说过的搜索策略优化的为例，我们拿A类词去搜索服务上测试，看新的策略下A类词的搜索结果是否符合我们的预期（判断如何算达到预期需要一套合理的评估工具，暂且不表），达到预期才算离线评估通过，否则就需要继续优化。
机器评估的工作原理其实人肉检查一样，只是在某些情况下，机器评估能够覆盖更多的场景，更能从全局场景下来说明效果好坏。
离线评估通过之后，策略就可以上线测试了。为什么一定要进行线上测试呢？如果离线评估确认策略有效，是不是就可以不经过线上测试呢？不行！因为不论你考虑的有多么全面，不论产品和工程师能力有多么强经验有多么足，你也不可能完完全全考虑真实环境的方方面面，总会有你遗漏的地方，所以只有在真实环境下测试有效的策略，才是真正有效的策略，应该说线上测试是检验策略的唯一标准。
效果评估除了验证策略效果优劣之外，还能给深入的策略效果分析、后续改进提供数据支持，甚至能够在新策略线上效果的数据中挖掘出新的有价值数据。
评估内容
前面已经提到，效果评估一般有效果预估、离线评估和线上测试三步，这三个评估从需求最开始启动开始，一直到需求正式上线前结束，就像是流水线上的一系列检验程序，保证最终呈现给用户的是最好的策略。由于这三个评估处于产品设计的不同阶段，作用和目的也不尽相同，因而评估方式和评估维度也存在着或大或小的差异。下面将对这三种评估做细致的介绍和分析。
1、效果预估
效果预估最主要的作用是评估一个需求的价值，它往往构成需求文档的前半部分，它需要说明某个需求在完成之后预计能解决多少问题，带来多少收益。或许你已经发现了，往实际了说，我们需要用效果预估来说服你的Leader以及合作伙伴，给自己的产品争取足够的资源和支持，如果你恰好是在一个产品经理不那么强势或者资源紧张的公司，其重要性不言而喻。除了这些比较实际的原因，效果预估能够让你对你将要做的事情心里有数，而这个数，会是需求进行中许多重要决策的基础，比如根据需求各细节部分重要程度调整需求开发顺序，设定需求进展里程碑，砍掉部分不重要的需求等等。
效果预估很重要，那么如何才能做好需求预估呢？四字总结：合理类比。在需求正式上线前，需求的效果确实是很难确定的，或许你能掌握一些数据，比如旧策略对多少比例的情境无效，或者旧策略坏的程度如何（根据评估标准来确定），但是新策略能多大程度解决问题，只有先知才能知道。这种情况下，摆在我们面前的能够采用的预估方式也就是拍脑袋和类比，在某些经验丰富的PM哪里，拍脑袋其实是已经在脑子里进行了类比，但是如果你希望你的需求能够顺利推进的话，我们依然谨慎使用这种方式（虽然几乎每个人都会或多或少的拍脑袋），拍脑袋的东西实在太没有说服力了，你不想在Leader和合作伙伴那里留下不靠谱的印象吧？类比是通过和新策略相似的策略在使用情境也相似的情况下的表现，来类比新策略的表现。相似策略在相似情境下的表现数据，一般可以从两种途径获得。一个是自家产品的其他类似策略的效果，比如你要在自家产品上开辟一个新的推荐位置，那么你大概能找到一个类似的位置推荐策略的表现数据，这个数据，就可以用来预估新策略的效果。除了在自家产品上找，你还可以通过某种方式来“窃取”竞对相似策略的效果数据。这个数据的获取看起来很难，但是请相信互联网上啥都有；如果互联网上没有，你身边总有从竞对来的同事吧（这个是最有效的）；如果这些条件你都没有，建议你去了解一下社会工程学（好像进入灰色地带了）。
现在你手里已经有了足够的类比数据，这表示你已经有了足够的资本去说服（忽悠）Leader和合作伙伴了。不过最后还是要提醒一下，由于一些你未知的原因，策略上线之后的效果很可能和你的预估存在差异。
2、离线评估
在讲离线评估之前，首先要告诉大家的是离线评估并不一定是必需的，如果已经确定了新策略一定会比旧策略效果好，而恰好同时你又必需让新策略及早上线测试（往往是因为旧策略存在错误或者烂到无以复加或者业务需要），那么离线测试这一步（大概）是可以省略的。不过这里仍然建议大家不要这么做，一个全面的离线评估能够避免我们将不好的策略推向前台，避免不必要的用户体验或商业损失。
前面已经介绍了离线评估的两种方式，人肉检查和机器检查。人肉检查相对费时费力（产品经理的时和力），但却是最直观的方式，也是最简单易达的方式，特别是对一些我们通过Badcase而产生的需求来说，人肉检查尤其合适。假设我们有一个新策略需求，需求来源是推荐的内容完全不符合用户的预期，那么最能说明新策略效果的离线评估方式，就是把需求开始前我们整理的Badcase拿出来，一条条的对比在相同情况下新策略的表现。如果我们人肉观测的这些Badcase已经解决，那就可以认为新策略解决了所有的相似问题，也就是新策略通过了离线评估（这里又要用到评估标准和工具）。而对于一些人肉无法检测的策略型需求，我们需要借助工程师的力量来进行机器评估。比如一个以点击转化率为目标的排序策略优化需求。因为转化率是一个整体的概念，人肉的方式是无法判定策略是否起到了优化的作用的，这时候我们只有借助机器来进行评估。或许你不懂怎么使用机器评估，或者没找到合适自己的工具，给你的工程师新开一个需求吧。
3、线上测试
如果新策略通过了离线评估，那么有很大概率新策略在线上也是有效的，但这仍然是停留在理论上，为了确认新的策略真的有效，你必须把新策略放到真实场景去进行检验。如果你是有一些工作经验的产品经理，一定知道AB测试的概念，你也应该知道AB测试就是用来对比测试产品线上效果的常用方式。AB测试是将产品的不同策略或设计推给不同的用户，在一个满足单一变量试验的情境中来确定新策略或设计的效果。一般来说，所有公司都会有AB测试系统去支持AB测试，这不是什么难事儿。但是AB测试有一些常见的陷阱和误区，后续部分详细介绍。
前面已经说到，线上评估是检验策略的唯一标准，那么为了能够做好线上评估，我们必须对策略后台系统进行改造以方便的做好线上测试和数据的搜集。从评估本身、成本和用户等方面考虑，一个好的评估系统应该具有以下特征：
1.可用的测试数据
策略产品是一个非常细致极度依赖数据的工作，可以说，可用的测试数据就是策略产品工作的基础，数据可用有两个方面的含义，一是数据能够获得，二是取得的数据是准确的。要获得可用的测试数据，就必须有可靠的数据统计工具，虽然数据工具和产品本身没有关系，但是却是产品持续改进的基础系统之一，在大公司，数据工具往往是一个很庞大的部门，这个部门负责设计数据统计框架，提供测试工具以便在各产品线上使用，对小公司来说，可以使用第三方的统计工具来完成这个工作。GA是常使用的第三方数据统计工具，还有我们常见的以某某统计命名的流量统计工具，这类工具会提供一个可调用的JS语句，插入到网页、App中，再在页面或app中需要统计的地方加上特殊标记，这样数据就能够生产、上报给第三方，然后我们可以在第三方工具后台查看到数据统计信息。这类工具对业务单一的小公司来说已经足够，但是它们往往提供的功能有限，不能够根据产品统计需要提供个性化的统计方案，所以业务复杂的大公司会自行搭建自己的统计系统。对策略产品来说，我们必须要选择一个可靠的统计工具来上报统计我们想要的数据，如果你能够拿到的统计方式不能够满足你的要求，那么你就应该推动数据产品经理帮你解决这个问题，或者亲自去解决了。
2.取样科学
既然我们的数据是用来做统计分析的，那么我们的分析过程就必须遵循一些统计学的基本原则，其中最重要的就是取样科学。在互联网产品中，我们最熟悉的就是测试方式就是AB测试，将不同的策略按照一定的比例放到真实场景中，一个作为对照组一个作为实验组，再把不同策略的数据拿出来分析两个策略的优劣。但是大家往往忽视了一个科学实验的基本问题，而这个问题决定了测试是否是可信的，那就是AB测试的A和B是不是真的单一变量。比如我见过有产品分iPhone和Android平台做AB测试，也见过分业务区域（比如O2O产品中的北京和上海）做AB测试的，这类测试表面上是做了对比，实际上对照组和实验组连可对比性都没有。在确认iPhone和Android用户行为一致前，这种AB测试的愚蠢程度就好比生物试验中让驴做实验组让马做对照组。其实，即使确认了iPhone和Android用户行为“一致”，我也不建议采用这种方式做AB测试，因为你所确认的行为“一致”，只是你观测到的那部分一致，而你是不可能知道全部的情况的。
前面说到了一些不好的AB测试方案，下面给大家说说什么是好的AB测试方案。做过实验的人都知道，前面所提的单一变量是做对照实验的基本原则，在产品策略的评估中，我们首先应该保证策略的不同是A和B的单一变量，简单的说，我们应该让我们AB方案的区分是尽量随机的。说到尽量随机，最直接的当然是每一次策略的调用都使用随机方式，确实它能够做到尽量随机，但是违背了下面要讲的第三条原则（后续详细介绍），所以一般情况下不适用这种方式。这里给大家介绍一种移动互联网情况下的比较合理的AB测试方案，根据设备标识符为每个设备生成唯一的数字识别符，然后取某一位的数字作为AB分配的基础，这种方式首先能够尽量的保证随机，而且能够分配AB方案的流量比例，比如0-1的使用A策略，2-9的使用B策略，那么A策略的线上流量就大概在20%左右。一般来说，这个方案能够解决大部分移动产品AB测试取样科学的问题，但是不能排除在某些特殊的情况下，还是需要产品经理们开动脑筋，设计出合适自己产品的AB测试分配方案。
事实上，如果你对自己的AB测试分配方案没有信心，你还可以用AA测试的办法去评估分配方案的合理性。AA测试是指认为将流量标记分为对照组流量和实验组，但是两组流量都使用相同的策略，如果在这种情况下两组流量的目标表现没有显著差异，则可以认为对照组和实验组的取样是随机的，符合统计要求的。否则，说明对照组和实验组样本上本身就存在差异，基于这种AB分组方式的AB测试是不可信的。
3.对用户打扰少
每一次策略的变更，都会带来展示的差异，虽然对策略性产品来说，这种差异是很难察觉的（比如排序的细微变化），但是我们毕竟是产品经理，减少对用户的打扰是我们必须要考虑的事情。在前面介绍科学取样时，我们介绍一种最符合随机要求的AB测试方法，那就是每一次策略调用层面上随机，我们已经说了这种方式不够好，原因在于它有一个很大的弊端，那就是你不能保证每个用户看到的策略是固定的。如果使用这种方式，那么用户每刷新一次，都有可能看到和上一次不一样的展示策略。想象一下，如果你刷新一次就看到一个跳动的列表，你会不会骂产品经理呢？前面介绍的设备层面的随机方式，就很大层面上解决了这个问题，这也是我们认为它相对合理的原因。顺便一提，前面介绍的分业务区域AB测试的方案同样存在打扰用户的问题。所以我们在设计评估测试系统的时候，应该考虑每一次策略优化的测试不要过多的给用户造成困扰。这方面的内容很难穷举，每个不同的产品都会有不同的打扰用户的问题，但是只要我们不忘初心及早考虑，这个问题是可以很大程度上避免的。
4.灵活迭代
作为策略产品经理，我们应该有一个最基本的常识：策略优化是一个持续的过程。它永远没有终点，就是像Google这样的公司，依然在不断的迭代更新搜索引擎算法。考虑到策略的优化是一个持续的过程，那么线上测试也会是一个持续不断的过程。认识到这点，那么将测试评估系统设计的方便迭代就是显而易见的事情。工欲善其事，必先利其器，一个方便迭代测试的系统，能够很大程度上节省工程师的时间，让工程师不在陷于无尽的无意义的测试开发，这对团队士气和工作效率的提升都是很大的帮助。针对这个问题，通常的处理方式搭建一个能够后台配置实时生效的后台，当需要进行测试或者进行策略切换的时候，能够方便快速的通过后台配置完成。如果更近一步，能够和流量分配功能结合在一起，那将是一个极佳的方案。
评估工具
如果你已经有了用于分析的数据，下一个摆在你面前的问题会是如何去分析？数据分析是策略产品经理必须具备的基本能力，掌握一些常见的策略产品分析工具和方法也是策略产品经理的必修课。对于一些常见通用的分析方式，在“产品经理应该了解的搜索排序评估方法”已经做了介绍。
评估不是目的
策略优化是一个持续的过程，策略产品经理的存在就是让策略越来越有效，某一次的策略优化不是我们的终点（虽然这将是你的KPI），效果评估也不是我们的目的。最理想的情况当然是我们每一次的优化都是有效的，但是往往事情并不会如此，这时候我们除了叹气之外，其实可以做的事情还很多。很多时候成功的原因很难找，但是失败的原因找起来却容易的多，当我们发现没有取得期望的效果的时候，那一定某个地方出了差错，如果我们深入挖掘测试数据中的内容，或许能挖到真的宝石。比如鄙人某一次信心满满的上了一个新策略，结果发现完全没有效果，在沮丧之下，我将场景做了拆分，发现这个策略在某些场景下是正面效果在某些场景下是负面效果，而这两个场景在整个策略使用场景中占比刚好是差不多都是50%。如果你已经做了足够的数据分析，所有的证据的都表明策略是无效的，而且也没有什么有价值的东西值得挖掘，那也不要气馁，它就是无效，这很正常。不过这时候你还有要做的事情，回顾分析上线前的那些分析哪里出了问题，以及，你要告诉所有人，这个策略可能是无效的，请大家谨慎尝试。
