编辑导语：一个产品经理在日常工作中不可避免的内容就是处理业务badcase，然而很多团队、PM对于badcase的处理还停留在发现一个问题，处理一个问题阶段，效率低到可怕。本文作者结合自身的工作经验，为我们分析了如何搭建一个case评测流程。

badcase，是互联网产品行业非常流行的一个术语，尤其是搜索、推荐策略产品领域经常会涉及到对badcase处理。

一个case，可以区分为goodcase和badcase。

顾名思义，badcase就是“坏例”，主要是指由于机制缺陷导致一些给用户、商家、平台带来较差体验的事件。它和bug的区别就在于badcase影响的是产品体验层面，对用户使用当前产品，享受正常的产品服务没有太大的影响。

也正是因为如此，包括我待过的公司，以及据身边很多同行的反馈，都缺少一个主动的、标准化的badcase处理流程。很多团队、PM对于badcase的处理还停留在发现一个问题，处理一个问题阶段，效率低到可怕。

一、策略不确定性

badcase为什么会主要在策略领域比较多，而在前端、功能类产品中比价少，这个其实本身是由策略产品的不确定性造成的。

我们做一个功能，上一个页面，其实整个交付结果是确认无疑的；包括功能背后的交互流程、业务逻辑、到一个页面的布局，用色都不能出现像素级别的差距，有错误，那就是bug！

但是策略就不一样了，它对应的结果通常是不确定的。

比如搜索结果的排序，其背后是由很多策略模型共同作用决定的，比如价格模型、销量模型、转化预测模型等等。而且随着各种非规则、非约束类策略的应用，看起来就更像一个“黑盒”，源源不断的输出它的计算结果，很难定位到某个结果是由单一的策略导致的。

所以，每当有人反馈说“我们上了低价模型策略，为啥有些价格低的物品在搜索结果中还是没有排在前面”，这个其实就是策略的一种不确定性，低价策略并不能保证所有价格低的物品都排序靠前，它更多的是一种保证业务生态健康的考量。

二、怎么做

需要主动一点，为了发现badcase，本身就值得建立一个标准的case评测流程。

当前很多团队badcase都来源于“第三方”反馈，商家、业务、运营或者用户，缺少主动反馈，发起自测的机制。

首先：真正的badcase本身就是策略缺陷导致的，因此这是一个非常好的策略迭代优化的触发点，要比竞品分析、产品规划更具象，迭代速度和效果反馈更快。

另外：仅仅接收第三方的反馈肯定是有一些局限性的，每方在反馈badcase的时候，都是基于各自的利益点阐述的，而策略产品则需要考虑的是整个大盘的方案。

如何完成一个完整的case的评测流程搭建？

1. 评测标准制定

评测标准是case评测的唯一依据，也是保证评测结果质量的关键所在。

它就类似一部法规，用来帮助判断各种case是否为badcase，及其严重程度，因此在建立case评测流程之前，首先就需要制定一个评测标准。

以搜索case评测为例，通常badcase标准包含两个方向的内容：召回和排序。

• 召回：主要是规定判断召回结果与query的相关性的规则，一般分为精确相关、高相关、低相关、无关四种。
• 排序：主要是规定判断召回结果中排序的合理性的规则，通常排序会与物品的质量度挂钩，因此这块还需要定义物品的质量度。比如质量度高排序靠后，质量度低排序靠前等都可以定义为badcase。

除了上述两大方面，还有很多细则需要单独进行定义，比如图片质量、标题质量等等。

这里需要注意的是如同法律法规会有刑事、民事、行政、经济等分类，评测标准也需要按照不同的业务领域进行个性化定制。比如商品和药品，判别的标准就会有区别，所以需要单独制定对应的评测标准。

有个case评测标准以后，就可以正式开始进行case评测。

2. 怎么进行case评测

1）谁来参与

通常在搜索团队内部，会把这个事情定义为“搜索用户满意度评测项目”，以便更好的进行组织和推进。

立项之后需要定义项目的参与方，“搜索满意度评测”一般包含这几个角色：项目负责人、产品经理，算法工程师，开发工程师，他们的分工不一样。

• 项目负责人：主要负责整个评测项目的时间计划制定，沟通机制建立，评测意见统一以及评测过程中遇到的问题处理；
• 产品经理：负责具体case的测评，评测报告的撰写以及评测标准修订建议收集；
• 算法工程师：负责具体case的评测，case归因分析；
• 开发工程师：负责具体case的评测，一般参与较少。

这里简单解释一下算法工程师和开发工程师，有的团队可能不会进行区分，统一称之为工程师；有的会做区分，算法工程师主要是负责人策略中算法、模型的开发；开发工程师则主要负责工程段的开发，通常指的是后端、服务端。

另外，搜索满意度评测项目的实施周期可以按照搜索迭代计划的快慢进行灵活设置。

在迭代较快的情况下，测评的频率也会相应加快，我见过一些团队一周一次；如果迭代较慢，或者优化项目周期跨度较长，可以适当把测评周期拉长，我们之前做的是2个月一次。

2）case抽样

case抽样是指提取评测案例，一般是由工程师通过sql在搜索日志中取数。

对于搜索来说，一个case最基本需要包括用户id，搜索关键词和搜索结果。随着业务的不同需要抽取的数据不同，比如在美团还需要抽取搜索时间，搜索地点等。

对样本的要求一般包括如下几方面：

• 时间上一般选择测评周期内的最后一周，这个时候相关的优化策略基本上都生效；
• case的数量按照项目参与人员的多少来确定，人均100个左右；
• 对于中台搜索通常会服务于若干条业务线，因此需要控制好不同业务之间的case数量比例；
• 总体的抽取规则采用随机抽取的方式，保证测评结果的可信度。

需要注意的是，随机抽出的case很多时候都是无效case，比如：无关键词，关键词是特殊字符等等。

但是只有基于有效case来进行评测，这样结果才可信，所以还需要对抽样结果进行过滤，一般抽样的时候会比计划评测case数量要多一些。

3）case测评

case评测是指评测人员对抽样后的case质量进行评估的一个过程，就类似阅卷，需要给每一份试卷进行打分。

为了操作方便，在大型企业，一般都会自建case测评平台，大家可以理解为这是一个case评测人员的协作平台。它主要提供的功能就是对case进行分配、筛选、查看、打分（分级）、若为badcase需要选择原因，以及填写备注。

注意这里的打分并不是按照评测人员的主观判断进行打分，而是会提前制定一个算法，算法大概的思路就是不同的badcase结果有不同的分数和权重，根据评测人员选择的原因分类自动进行分数计算。

比如：评测人员选择badcase原因是无关商品排序靠前，记为0分；若是低相关商品排序靠前，则为3分。通俗理解就是，badcase越严重，得分越低，也意味着对用户体验伤害越大。

case的评测最重要的前提就是需要定一个评测的标准，这里大家要注意的是，标准不是一成不变的，每一次评测都是一次优化、完善标准的机会。

4）冗余评测

大多数团队在进行了评测之后就开始进行数据统计，看看goodcase有多少、badcase有多少，然后基于这两个数据计算当前评估周期的满意度。

搜索满意度的计算方式为：

goodcase/(goodcase+badcase)*100%

这里无论是goodcase还是badcase，都是指的有效的case。

由于评测的标准是人工制定的，因此经常出现一些标准没有覆盖的case，以及大家理解不一致的地方，因此这个时候就需要加一个冗余case评测环节。

冗余评测就是对评测过程中有意见分歧的case进行项目组成员集体评测，最终做出决策。显然冗余评测的目的除了能够保证满意度结果的公正，更为重要的一环是基于大家对badcase的不同理解，去完善评测标准。

评测标准可以说是满意度评测的根本，只有标准制定的好，才能产出一个客观的满意度结果。我微信后台放了一个评测标准的模板，大家可以输入模板来获取。

5）case归因

case评测的直接目标是衡量搜索的满意度，但是根本目标还是通过badcase明确、指导搜索策略优化。

因此，当case评测进行了bad和good判定之后，最后一个环节就是case归因。简单来说，就是分析造成每一个badcase的原因是什么？

一般来讲对于搜索badcase，包含下面几类

1. 词典问题
2. 查询分析问题
3. 召回问题
4. 排序问题
5. 前端问题

这一块下一篇再详细讲解。

#专栏作家#

夏唬人，公众号：夏唬人，人人都是产品经理专栏作家。某厂策略产品经理，关注推荐，搜索，AI策略方向，用数据来赋能业务。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。