B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

在日常工作中對接第三方系統的時候,常見的小困擾是第三方系統返回的錯誤資訊的處理。為了方便理解,我們需要將錯誤資訊轉化為友好型提示,如何轉化呢?一起來學習一下吧。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

作為一個B端或者SaaS產品經理,在日常的工作中經常需要對接第三方的系統。在對接第三方的系統的時候,比較常見的小困擾就是第三方系統返回的錯誤資訊的處理。

有一些研發能力比較強或者說介面做的比較完善的第三方,他們返回的錯誤資訊會比較的齊全,會包含錯誤碼,錯誤資訊和其他內容等,我們可以透過這些資訊知道發生了什麼錯誤,應該要怎麼解決。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

截圖出自:Aftership的API文件

同時第三方的API文件中也會有一個公共的錯誤碼查詢頁面,當我們遇到了一些問題之後,可以檢視這些文件去嘗試自己解決問題。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

截圖出自:速賣通的API文件

但是在實際的工作中,我們也會發現有一些第三方的API其實做得很不完善。有一些錯誤資訊沒有規範處理,可能沒有錯誤碼,也可能錯誤資訊都是一些偏術語性的程式錯誤,導致我們拿到了錯誤資訊之後並不知道錯誤資訊到底是怎麼產生的,應該要怎麼解決。類似於下圖的錯誤,是在對接一些國際物流渠道的時候經常會遇到的問題:

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

DHL返回的錯誤,即使翻譯了也看不太懂原因是啥

在跨境電商SaaS ERP或者SaaS WMS/TMS這一類系統中,以上問題出現的頻率很高。尤其是SaaS ERP,因為它需要對接很多外部的第三方系統,例如說:

對接電商平臺,Amazon,eBay,Walmart,Shopify等;

對接物流商,國際物流(DHL,FedEx,UPS),跨境物流(雲途,燕文,4PX)等;

對接海外倉,穀倉,萬邑通,4PX,其他SaaS WMS等;

對接一些工具服務商,圖片翻譯,圖片編輯,支付收款,選品分析等;

這些第三方系統,有一些是有比較專業的研發團隊,有一些則是不太專業的研發團隊,所以就會導致在對接完成了之後,使用者在使用的過程中如果遇到了問題或者錯誤,反饋回來的原始錯誤資訊有可能是不太好閱讀的,甚至是壓根對不上的錯誤資訊。

除此之外,由於要對接很多國外的系統(國際物流商),這些系統返回的錯誤資訊還有一些語言上的差異,例如說德國的物流渠道會返回的錯誤是德語,法貨的物流渠道返回的錯誤是法語,即使是比較通用的英語,有一些錯誤資訊還是需要藉助翻譯工具才能理解其中的意思。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

DHL Packet返回的錯誤是德語

基於以上的背景,當我們對接了大量的第三方系統,而第三方系統返回的錯誤資訊可能是千差萬別,甚至非常不利於客戶理解的時候,我們就需要考慮去對第三方系統返回的錯誤資訊做一個

轉換處理

,這個處理過程我稱之為:

錯誤資訊轉化為友好型提示的過程

一、什麼是友好型提示?

當用戶在使用系統的過程中,使用者並不關心繫統背後對接了多少家第三方系統,使用者甚至也不擔心在使用的過程中遇到報錯,

使用者擔心的是報錯看不懂,報錯有誤,這種不確定性會很容易消耗掉使用者的耐心,從而讓使用者對系統產生一些負面的看法

作為一款資訊系統的設計者(產品經理),我們都知道系統執行發生錯誤,提示錯誤資訊是不可避免的。但是我們期待的是,當系統出現了錯誤時,呈現給使用者看到的東西是“友好型的提示”,也就是讓使用者容易理解,最好是能能讓使用者自主排查問題、自行解決問題的一種提示。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

友好型提示案例1

如上圖所示,我在刊登產品到Shopify的時候報錯了,系統告訴了我錯誤原因是“Unavaliable Shop”,同時還告訴了我解決方案,是因為我的店鋪不可用,需要重新授權,點選就可以檢視具體的授權操作幫助指引。

這種錯誤提示對使用者來說就是“友好型提示”,除了告訴我出錯了,還告訴了我錯誤原因是啥,我應該怎麼去解決這個錯誤。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

友好型提示案例2

上面這張圖反饋的也算是“友好型提示”,先告訴了我遇到了錯誤,同時也告訴了我錯誤原因是“account numer must be of the legth 14”,所以我要做的就是檢視我的account number是否有超長。

並不是說“友好型提示”就一定要翻譯成中文或者一定要帶上解決方案,

只要能讓使用者快速知道問題所在,並知道怎麼解決這個問題,那麼這種錯誤提示都可以稱之為“友好型提示”

二、錯誤資訊如何轉化為友好型提示?

當我們請求第三方系統的時候,從結果上來看,要麼是成功的,要麼是失敗的。如果只看失敗的情況下,失敗的提示也就分成兩種,要麼是能看得懂的(友好型),要麼是看不太懂的(非友好型)。

所以,當我們討論怎麼將錯誤資訊轉化為友好型提示時,其實前提是將“非友好型”的錯誤資訊轉化為“友好型”的提示。因為,有一些第三方系統是會對錯誤資訊處理好後才拋給請求方,這樣的錯誤資訊一般情況下都是友好型的,而有一些第三方系統則是因為種種原因,所以就直接將非友好型的錯誤資訊回傳給請求方了。

如果第三方回傳的是友好型提示,那麼後端接收到了錯誤資訊之後,無需處理,直接傳給前端去展示對應的錯誤即可;如果第三方回傳的是非友好型提示,那麼後端接收到了之後就需要額外處理、轉化加工之後再傳給前端,去展示處理後的友好型提示。

那麼,後端怎麼判斷第三方系統返回的錯誤資訊是友好型提示還是非友好型呢?

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

錯誤資訊轉化為友好型提示的示意圖

最簡單的辦法就是在“錯誤資訊”和“友好型提示”之間,

加上一個過濾器,也稱之為處理規則或對映機制

當系統接收到了第三方返回的錯誤資訊之後,將錯誤資訊推給處理規則,如果命中了處理規則,則返回處理後的資料,即友好型提示;如果沒有命中規則,則返回原始的錯誤資訊。

系統增加一個“處理規則”的維護模組,可以手動建立多個處理規則,然後所有的錯誤資訊進入系統之後,都去輪詢跑所有的處理規則,看是否命中了對應的規則,如果命中了則按規則的配置進行處理,如果沒有命中在,則迴圈下一個規則,直到所有的規則都迴圈處理完成。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

處理規則其實也很簡單,分成三部分,一個是規則基礎資訊,一個是規則的匹配邏輯,另一個就是處理後的友好型提示。

基礎資訊模組

,可以定義規則的名稱,規則適用於什麼第三方物流服務商,以及規則的優先順序等,下圖的示意圖沒有設定優先順序,是以對接的物流服務來舉例的,大家實際在設計的時候可以靈活的調整。

規則的匹配邏輯模組

,可以被匹配的原始錯誤資料有兩類,一個是錯誤碼,一個是錯誤資訊,而匹配的方式有三種,所以組合之後一共是最多6種匹配邏輯,這些匹配邏輯可以採用或的關係,也可以採用且的關係。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

舉個例子,如果某第三方物流商的錯誤碼和錯誤資訊如下圖所示,當系統需要建立處理規則來匹配其返回的錯誤碼或者錯誤資訊的時候,可以有很多種配置方式。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

第三方錯誤碼示意圖

針對錯誤碼設定匹配邏輯,可以有“完全匹配”,“模糊匹配”,“正則匹配”,如下圖所示:

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

如果是針對錯誤資訊設定匹配邏輯,可以有“完全匹配”,“模糊匹配”,“正則匹配”,如下圖所示:

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

除此之外,還可以設定多條匹配規則,然後採用且或者或的關係進行組合,有非常多的組合方式,很是靈活。

處理後的友好型提示

模組,必須要填寫的內容是“友好型提示”,而“解決方案”是非必填的。當第三方原始的錯誤資訊匹配了該條處理規則之後,系統會將“友好型提示”和“解決方案”的內容傳給使用者展示。這樣使用者就可以看到處理後的提示,能更容易理解遇到了什麼問題,將要怎麼處理。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

同時也要注意一下,為了帶來更好的體驗,

“解決方案”這個欄位還可以支援維護超連結的文字

,這樣使用者還可以直接點選就跳轉到對應的幫助手冊中。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

使用者在前端介面看到的友好型提示

三、一些設計背後的思考

截止到寫這篇文章之前,我陸續做過2次的錯誤碼對映轉化的需求,但是之前的方案感覺建模的過程搞混了,所以有一些邏輯沒有想清楚,就總覺得這個方案不太好,是不是還有什麼更優解之類的。

當時設計方案的時候,一直把焦點放在了歷史的錯誤資訊上。期望的是當一個新的錯誤資訊進來後,先在歷史的錯誤資訊池中找一遍,看是否能找到對應的錯誤,也就意味著這個錯誤曾經發生過,然後把之前的錯誤資訊對應的處理方式賦值給新的錯誤資訊,相當於就直接得出了這條新錯誤的處理方式。

但是實際上,這樣的設計就是因為建模物件搞錯了,把重心放在了錯誤資訊池上,每次進來的新錯誤都要插入到錯誤資訊池中,同時還要標記上對應的處理規則,而這個處理規則是從歷史的錯誤資訊的處理規則複製過來的。這樣就會導致每次去匹配歷史的錯誤資訊都要花費很多時間,因為錯誤資訊池肯定是會無限膨脹,逐步增加的。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

當我為了寫這一篇文章,重新去對這些業務物件梳理、建模之後,發現只要把建模的核心放在處理規則上,其實這個事情就沒有想象中的複雜。因為處理規則是少量的,是可控,也是相對來說固定的,只要預設好處理規則,把它當做一個管道,原始錯誤進入管道,能處理的就會變成友好型提示,不能處理的就會用原始錯誤資訊展示。只需要不斷地對這個管道昇級和維護,未來它能處理的訊息數量、型別、種類等都會隨之提升。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

在此,我分享一個之前看到的聚水潭ERP的處理方式,當時單看這張圖的時候,我也想了挺久也搞不明白,但是結合我上面的分析之後,我發現看懂這張圖就不難了。

B端產品經理必知:如何將第三方錯誤資訊轉化為友好型提示?

聚水潭ERP apiErrorMapping

四、總結

剛好最近在體驗ERP的刊登功能,就發現了原來除了物流系統之外,其實很多系統都會需要與第三方系統對接,而且都會遇到這種錯誤資訊不利於使用者理解的場景,所以設計一套錯誤資訊的轉化規則還是挺有價值的。適用於不同的行業,也適用於不同的系統,學會之後可複用性很高。

我在寫這篇文章的時候,在網上找了一下,發現幾乎沒有看到什麼相關的問題,我猜測一方面是因為產品經理可能沒有意識到這些錯誤資訊對使用者來說體驗可能不太好,或者意識到了但是不太懂技術也不知道這個東西還可以最佳化;還有一方面就是來自第三方的錯誤資訊實在是太多了,這個工程量還是蠻大的,綜合考慮來看,這些優先順序可能會排的比較後;還是就是寫這種細節類、實操類總結文章太費時間,而且不是大家愛看的選題……

在我日常的調研和體驗多個SaaS/B端系統的過程中,我發現只有一些比較知名或者說重視使用者體驗的產品才會在這一塊投入較多的資源去最佳化解決,其他同類型的競品做了類似的最佳化的比較少見。

對於跨境電商領域的SaaS產品來說,這一塊的最佳化尤為重要,尤其是SaaS ERP。畢竟一款成熟的ERP對接的第三方系統實在是太多了,很難保證諸多第三方的API體驗在及格線之上,既然如此,那還是選擇自己去做兜底的事情吧!

希望我的一些小小的思考能夠幫助大家,給大家一些啟發,如果你們有更好的解決方案的話,也歡迎留言與我交流。

為我投票

我在參加人人都是產品經理2022年度作者評選,希望喜歡我的文章的朋友都能來支援我一下~

點選下方連結進入我的個人參選頁面,點選紅心即可為我投票。

每人每天最多可投35票,投票即可獲得抽獎機會,抽取書籍、人人都是產品經理紀念週邊和起點課堂會員等好禮哦!

專欄作家

我叫維他命(Vitamin),微信公眾號:PM維他命,人人都是產品經理專欄作家。前PHPer,做過線上教育類產品,也做過5年多的跨境供應鏈方向的產品,現任某跨境電商ERP的產品負責人。主要專注於WMS/OMS/TMS/BMS/ERP等領域,分享跨境和供應鏈相關的產品知識。

本文原創釋出於人人都是產品經理,未經作者許可,禁止轉載。

題圖來自Unsplash,基於 CC0 協議。

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供資訊儲存空間服務。

頂部