大家好，我是策略产品经理夏唬人。上一篇我们讲了：策略产品经理都需要知道的主观评估（一）做主观评估必须要有一个策略评估标准。
有个case评测标准以后，就可以正式开始进行case评测。本篇文章将以搜索为例具体讲一下搜索是怎么进行case评测的。
01、谁来参与
通常在搜索团队内部，会把这个事情定义为“搜索用户满意度评测项目”，以便更好的进行组织和推进。
立项之后需要定义项目的参与方。“搜索满意度评测”一般包含这几个角色：项目负责人、产品经理，算法工程师，开发工程师。他们的分工不一样。
项目负责人：主要负责整个评测项目的时间计划制定，沟通机制建立，评测意见统一以及评测过程中遇到的问题处理
产品经理：负责具体case的测评，评测报告的撰写以及评测标准修订建议收集
算法工程师：负责具体case的评测，case归因分析
开发工程师：负责具体case的评测，一般参与较少
这里简单解释一下算法工程师和开发工程师，有的团队可能不会进行区分，统一称之为工程师；有的会做区分，算法工程师主要是负责人策略中算法、模型的开发；开发工程师则主要负责工程段的开发，通常指的是后端、服务端。
另外，搜索满意度评测项目的实施周期可以按照搜索迭代计划的快慢进行灵活设置。
在迭代较快的情况下，测评的频率也会相应加快，我见过一些团队一周一次；如果迭代较慢，或者优化项目周期跨度较长，可以适当把测评周期拉长，我们之前做的是2个月一次。
02、case抽样
case抽样是指提取评测案例，一般是由工程师通过sql在搜索日志中取数。
对于搜索来说，一个case最基本需要包括用户id，搜索关键词和搜索结果。随着业务的不同需要抽取的数据不同，比如在美团还需要抽取搜索时间，搜索地点等。
对样本的要求一般包括如下几方面：
时间上一般选择测评周期内的最后一周，这个时候相关的优化策略基本上都生效
case的数量按照项目参与人员的多少来确定，人均100个左右
对于中台搜索通常会服务于若干条业务线，因此需要控制好不同业务之间的case数量比例
总体的抽取规则采用随机抽取的方式，保证测评结果的可信度
需要注意的是，随机抽出的case很多时候都是无效case，比如：无关键词，关键词是特殊字符等等。但是只有基于有效case来进行评测，这样结果才可信，所以还需要对抽样结果进行过滤，一般抽样的时候会比计划评测case数量要多一些。
03、case测评
case评测是指评测人员对抽样后的case质量进行评估的一个过程，就类似阅卷，需要给每一份试卷进行打分。
为了操作方便，在大型企业，一般都会自建case测评平台，大家可以理解为这是一个case评测人员的协作平台。它主要提供的功能就是对case进行分配，筛选，查看，打分（分级）、若为badcase需要选择原因，以及填写备注。
注意这里的打分并不是按照评测热源的主观判断进行打分，而是会提前制定一个算法，算法大概的思路就是不同的badcase结果有不同的分数和权重，根据评测人员选择的原因分类自动进行分数计算。
比如：评测人员选择badcase原因是无关商品排序靠前，记为0分；若是低相关商品排序靠前，则为3分。通俗理解，就是badcase越严重，得分越低，也意味着对用户体验伤害越大。
case的评测最重要的前提就是需要定一个评测的标准，关于标准的制定见：。这里大家要注意的是，标准不是一成不变的，每一次评测都是一次优化、完善标准的机会。
04、结果统计
大多数团队在进行了评测之后就开始进行数据统计，看看goodcase有多少，badcase有多少，然后基于这两个数据计算当前评估周期的满意度。
搜索满意度的计算方式为：
goodcase/(goodcase+badcase)*100%
这里无论是goodcase，还是badcase，都是指的有效的case。
由于评测的标准是人工制定的，因此经常出现一些标准没有覆盖的case，以及大家理解不一致的地方，因此这个时候就需要加一个冗余case评测环节。
冗余评测就是对评测过程中有意见分歧的case进行项目组成员集体评测，最终做出决策。
显然冗余评测的目的除了能够保证满意度结果的公正，更为重要的一环是基于大家对badcase的不同理解，去完善评测标准。
评测标准可以说是满意度评测的根本，只有标准制定的好，才能产出一个客观的满意度结果。
05、case归因
case评测的直接目标是衡量搜索的满意度，但是根本目标还是通过badcase明确、指导搜索策略优化。
因此，当case评测进行了bad和good判定之后，最后一个环节就是case归因。简单来说，就是分析造成每一个badcase的原因是什么？
一般来讲对于搜索badcase，包含下面几类：
- 索引问题
- 查询分析问题
- 召回问题
- 排序问题
- 前端问题
这一块下一篇再详细讲解。
