高德技術評測建設之路
前言
近幾十年是網際網路高速發展的時代。隨著網際網路行業的發展壯大,必然會出現角色的細分,從而演化出了不同的職能崗位。隨著日益激烈的市場競爭,修煉內功,提升產品效果也成為了各公司發展的重要工作。產品效果如何評估?使用者體驗如何度量?本文試圖闡述 評測這一新崗位在高德的主要職責,發展進化過程,以及這一崗位所負責的產品效果評估手段與體系搭建。
當你在各搜尋引擎輸入評測二字時,看到的相關搜尋通常是這樣的:
這些問題其實能代表大部分人對評測的瞭解——就是除了遊戲評測、手機評測、汽車評測、生活用品評測之外,人們對評測其實不太瞭解。網際網路公司裡Title是評測的同學又是做什麼的呢?也許大家的瞭解就更少了。
做了三年多的評測,在第一年經常面對的靈魂拷問就是:“你們評測是做什麼的?”這種問題回答起來,基本類似於哲學的終極三問了:“你是誰?你從哪兒來?你到哪兒去?”
評測是誰?這是評測的定位問題。評測從哪兒來?這是評測的根基和起源。評測要到哪兒去?這是評測的發展目標和方向。
評測是誰?
簡單地說, 評測是評估產品效果的團隊。希望能站在使用者的角度,在上線前驗證需求效果,在上線後通過對自身、使用者資料和競品的全面分析,建立起產品立體的效果評估體系,也就是評測體系。
評測從哪兒來?
要回答這個問題,其實就是——為什麼要評測?
如同每個版本更新,我們都會關心效能如何一樣,當上線了新的策略時,大家也會同樣關心產品的效果。產品效果如何評估?策略相關的需求開發完成之後,研發實現的實際效果是否和產品經理的預期一致?實際效果又是否和使用者的預期一致?在理想情況下,這三者應該是無差異的。但我們也應該有衡量它們之間是否有差異的方式,給出效果變化是否正向的結論,以更好地保障使用者的使用體驗。
此外,即使上線前,所有人都一致給出了正向結論,認為需求上線後一定會給使用者體驗帶來極大提升。真實的產品體驗如何,仍然得使用者說了算。比較大的修改可以通過AB實驗的方式圈出小部分使用者,快速收集使用者資料,進一步對需求效果是否正向做出評價。或者直接上線,通過對行為資料及使用者反饋的分析來完成線上評估。
同時,要在市場上找準自己的位置,對競品的分析必不可少。
有了這些效果評估及分析的需求,就有了評測團隊。
如何進行評測
上線前的離線效果評測及分析、AB實驗及分析、上線後的指標監控及問題分析、問題挖掘,競品監控和分析是常見的評測手段。
一、離線評測
上線前,針對產品的需求,評測的職責是通過各種方式分析及驗證產品效果,給出是否能達到上線標準的結論,同時分析出頭部問題所在。
技術評測團隊成立之初,主要建設的部分有:確定合作流程、建設評測專業能力和建設評測工具。
-
合作流程
對標一個版本開發的專案流程,從需求確定到開發,到測試驗證再到上線。評測從需求串講階段開始,明確有哪些需求涉及到效果變化。再根據變化情況制定評測方案,同時檢查工具是否符合需要,如否則進入工具快速開發階段。然後獲取評測資料,進入評估驗證階段,最後傳送報告,給出需求是否通過評測的結論,並對出現的問題進行總結分類。
對於評測介入的不同業務線來說,評測的流程大致相同。但由於業務不同,評測方案與方式會有很大不同。
-
評測方案
根據產品需求,明確效果修改影響範圍,從而確定評測樣本、評測方式和評測標準。
-
評測樣本
評測樣本通常會根據需求影響範圍的不同,區分為隨機語料和特定語料。
特定語料一般針對需求修改的特定維度、型別進行抽取,目的是保證評測任務的覆蓋率。隨機語料則是為了反映需求的真實影響範圍。當一個評測任務需要使用特定語料時。通常建議使用特定及隨機語料各一份,以同時保證足夠的覆蓋,同時瞭解真實影響範圍,確保不會出現不符合預期的變化。
除真實語料外,在特定場景下也會使用自己構建的語料。通常原因為:1)策略上線之前沒有真實線上語料;2)影響的場景太小,在真實語料中很難找到足夠的Case。
-
評測標準
評測標準通常涉及到一個概念,即真值。當某類資料在現實世界中有唯一正確答案時,即有絕對真值存在,如資料資訊。因此我們對這類資料的評價標準就是是否跟真值一致。
另一類是相對真值。來源可以是使用者日誌。例如,當我們在判斷提供給使用者的預計到達時間(ETA)是否正確時,可以用使用者在起終點之間的真實行駛時間作為真值和我們的預估時間進行對比。但由於單一使用者的實際行駛時間受個人行駛習慣以及單次的行駛情況所影響,並不是完全準確的。因此是相對真值。在搜尋等業務線,使用者的點選行為,也可以成為相對真值,從而成為效果評測的標準。
是否有真值,真值是否容易獲取,能否大批量自動化的獲取,是在確認評測標準時需要做的判斷。
-
評測方式
對應不同的評測目的,我們給出不同的離線評測方式。有真值的業務,通過真值的自動獲取或者標註,可以實現自動化評測。而無真值的業務線,判斷效果好壞的成本較高,通常需要進行人工評測或者半自動化評測。
人工評測,顧名思義,就是靠人力打分。各搜尋公司大概是最早對自己的產品進行效果評估的,谷歌、微軟、百度、蘋果等,都採用了類似的方式對質量進行評價。
Google曾經發布過長達164頁的人工質量評估指南。百度和必應也釋出過類似的文件。
蘋果在介紹自己的評測體系時,也曾經專門解釋過Human Judgement metrics, why we track them?
-
可以在上線前發現版本問題。
-
人工評測的指標與定量指標緊密關聯。
-
可以定義一個版本的整體質量,並可持續跟進效果變更。
-
比使用者反饋更詳細,更容易定位問題。
人工評測缺點不用多說,成本高、覆蓋面小、效率偏低。因為它的優點,目前仍然是各公司評測體系不可缺少的一部分。與別的評測手段結合使用時,能起到很好的效果。
要保證人工評測的質量和效率,有三個關鍵點,一是標準,二是流程,三是工具。
標準文件,類似於操作手冊,目的是降低人員培訓成本,並在一些較難判斷的Case上,儘量減少大家認知上的差異。所以標準文件應該越傻瓜越好。定義明確、所有的特殊和例外場景都有示例、在實踐中反覆檢驗,並且保持更新頻率。文件更新應該有專人負責,並且明確更新週期,同時將更新點同步到所有評估人員。
人工操作錯誤在所難免,沒人能達到百分百的準確。同時需要人工評測的評測物件,通常本身沒有客觀統一的確定答案,因此大家難免在判斷上有差異。這些問題都需要從流程上加以保障。如同一Case必須多人標註,僅保留一致率較高的Case,否則便丟棄。或者採用初審複審制,經驗較少的人員進行初審,高階人員進行復審。
盲審,這種方式通常在對比時使用,去掉新舊版或者左右版的標識,並且讓結果隨機出現,從而保證評測人員的客觀性,不受主觀因素影響。
人工評測中的人,通常也有兩種身份。一種是普通使用者,一種是專家。專家評測需要站在更專業的視角,結合自己對業務的理解和經驗才能得出結論。另一種則是普通使用者也能站在自己的視角給出效果好壞。後一種可以進行眾測,達到較大範圍的收取使用者體驗與反饋,同時獲得一些真實資料支援迭代優化的效果。地圖導航由於其專業性,通常需要進行專家評測。
-
評測工具
評測工具是評測效率和質量的保證。核心功能包括,資料倉儲、任務管理、任務的抓取和解析,diff統計和篩選,任務例項的展示、評測、流轉,抽樣、分配,結果管理、自動化報告。
通用流程之外的任務型別、打分方式、 Case形態都可以自己定義。由於大部分是對比類的評測任務,如何做diff也非常關鍵,儘量把業務關注的各個重點都進行diff差分。以便快速瞭解迭代效果影響面,以及快速定位問題。專家型評測在分析和定位問題時,還需要輔助分析或者判斷的資料及工具。工具的接入常常能極大地提高評測效率。
人工評測能夠良好執行,有了一定的評測經驗積累和業務瞭解之後,開始進行半自動化和自動化的評測建設。
方式包括定義指標波動閾值和極端Case的冒煙評測,及模擬人工評測的自動打分模型。
自動打分模型通過學習人工評測的特徵,自動給出GSB的評分,統計評分結果,對評測任務的效果進行初步判定。目前可以成為輔助判斷的參考手段。
冒煙評測先定義出業務核心關注的場景和維度,設定指標。並根據既往評測經驗計算出可接受的波動閾值。另外定義出在效果變化上不可接受的惡劣Case。對於部分需要快速驗證上線的實驗,可以實現縮短評測週期,並保證無異常的效果。在部分業務線藉此實現了自動釋出上線的過程。
指標分析+異常檢驗的評測方式,是目前無真值業務線離線評測的最佳實踐方式之一。通過定義整體指標、場景指標、異常指標,形成較為全面的指標體系。觀察新版本在不同情況下的指標整體波動和分佈變化。在過程中篩出異常Case再進行人工校驗。最終根據指標變化情況和人工檢驗結果給出結論。如無異常則可以快速通過評測。
最後, 路測是導航產品效果驗證的終極手段。從使用者視角體驗並評估全過程。雖然成本高,效率低,但必不可少,與其他手段並用,也是上線前效果保障的方式之一。
二、AB實驗
部分需求尤其是模型調優。需要上線觀察效果。因此在快速通過離線評測之後,進入AB階段進行效果評估。
AB的核心鏈路是分流打標、指標觀測和實驗結論產出。關鍵點是實驗的科學性。效果評估鏈路中,AB能力的具備不難,但AB實驗的建設是個長期的過程,在此不贅述。
三、線上驗證
經過離線驗證、AB實驗,證明效果都是正向之後,需求通常全量上線,上線之後的效果如何,需要對線上指標進行分析,並觀察使用者反饋情況,瞭解是否在核心指標上有預期的收益,以及觀察指標是否有異常變化。
一個產品的核心是滿足使用者需求,創造使用者價值。因此是否滿足了使用者需求,使用者滿意度如何,產品在市場上的情況怎麼樣,必然是一個產品創造者要長期關注和回答的問題。以上便是我們試圖去回答這些問題的方式。
結語
評測的建設過程,其實也是產品效果評估立體體系的搭建過程。這個職責在任何一個網際網路公司都需要有人承擔。不過角色也許是測試、也許是產品、也許是運營。在高德,之所以把這個角色獨立出來,源於對使用者體驗和產品效果的重視。這一體系當然遠遠未臻完美,還在不斷搭建進化的過程中,我們始終希望能夠通過不斷努力,讓出行更美好。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69941357/viewspace-2690873/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 高德引擎構建及持續整合技術演進之路
- 衛星影像識別技術在高德資料建設中的探索與實踐
- 技術管理之路三、團隊建設:怎麼帶隊伍?
- 高德Serverless平臺建設及實踐Server
- 高德 Serverless 平臺建設及實踐Server
- 高德全鏈路壓測——精準控壓的建設實踐
- Digital Foundry:谷歌Stadia技術評測Git谷歌
- 高德全鏈路壓測——語料智慧化演進之路
- UI自動化技術在高德的實踐UI
- 《計算機程式設計藝術》作者高德納計算機程式設計
- 21年技術建設覆盤
- 高併發設計技術方案
- 高德技術團隊:深度學習在導航速度預測中的探索與實踐深度學習
- 2020高德技術年刊:18萬字、750頁+,智慧出行最佳技術實踐都在這了
- 團隊技術資訊流建設
- 高德客戶端及引擎技術架構演進與思考客戶端架構
- 高德AR & 車道級導航技術演進與實踐
- 18-網路安全測評技術與標準
- 等保測評乾貨錦囊,安全管理測評和安全技術測評區別和聯絡是什麼?
- 技術實踐|百度安全「大模型內容安全」高階攻擊風險評測大模型
- web技術分享| 【高德地圖】實現自定義的軌跡回放Web地圖
- 簡述網站建設技術難點網站
- WebGL程式設計指南(8)高階技術Web程式設計
- SMP2018中文人機對話技術評測
- 質量體系建設之路---從介面測試開始基建
- 商家下載中心設計演進之路|得物技術
- 3倍+提升,高德地圖極致效能優化之路地圖優化
- 某熊的技術之路指北 ☯
- jaeger的技術演進之路
- IT技術人的晉級之路
- 我的技術成長之路
- 如何給Flutter寫一個高德地圖定位外掛 | 掘金技術徵文Flutter地圖
- 如何利用AI技術推進班組建設?AI
- 中小團隊的技術負責人如何做好技術團隊建設
- 高併發技術
- 內網穿透技術淺評內網穿透
- 3倍+提升,高德地圖極致效能最佳化之路地圖
- 德勤:2024年法律技術趨勢