起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何搭建一個case評測流程（一）
編輯導語：一個產品經理在日常工作中不可避免的內容就是處理業務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，包含下面幾類
- 詞典問題
- 查詢分析問題
- 召回問題
- 排序問題
- 前端問題
這一塊下一篇再詳細講解。
#專欄作家#
夏唬人，公眾號：夏唬人，人人都是產品經理專欄作家。某廠策略產品經理，關注推薦，搜索，AI策略方向，用數據來賦能業務。
本文原創發布于人人都是產品經理，未經許可，禁止轉載。
題圖來自 Unsplash，基于 CC0 協議。
還
是這樣評測嗎
你
合計