作為產(chǎn)品經(jīng)理，不懂一點接口怎么行？

接口有什么用？

作為一個互聯(lián)網(wǎng)公司，很多資源和信息需要內(nèi)部共享或外部流通，那相關(guān)的數(shù)據(jù)就需要通過接口來傳輸。無論是2C還是2B的產(chǎn)品，都會用到接口，其中2B的產(chǎn)品們——數(shù)據(jù)、后臺、開放平臺/供應(yīng)鏈，幾乎和接口都是正面接觸。

接口怎么用？

目的千差萬別，用法殊途同歸。本文主要以美團(tuán)門票舉例，介紹接口的基本屬性、產(chǎn)品邏輯和異常情況等，供大家參考和討論。

怎么理解接口？

API接口是Application Programming Interface的簡稱，是一些預(yù)先定義的函數(shù)，包括接口地址、傳入?yún)?shù)和返回參數(shù)。

可以簡單理解為，當(dāng)需要訪問某些數(shù)據(jù)，正常狀態(tài)下傳入合格參數(shù)，會收到該數(shù)據(jù)范圍內(nèi)的返回參數(shù)。

場景：在美團(tuán)旅游頻道，用戶選定時間、地點后搜索航班，后臺會調(diào)用搜索接口傳入時間、地點等參數(shù)，接收航班類別、價格等參數(shù)，在前臺頁面上進(jìn)行排列展示。同理，下單時會調(diào)用生單接口確認(rèn)是否成單，支付時會調(diào)用支付接口完成交易，自動修改訂單狀態(tài)。

產(chǎn)品邏輯

很多公司都有開放平臺（也叫供應(yīng)鏈），比如美團(tuán)作為一個平臺，很多的供應(yīng)商需要把自身資源導(dǎo)入平臺，在平臺頁面上集中展示，供用戶選擇。一般情況下，美團(tuán)會有自身的一套接口，供應(yīng)商可以開發(fā)對應(yīng)的接口進(jìn)行對接，這種叫（運價）直連。

以下以美團(tuán)門票為例，此鏈接http://open.trip.meituan.com/是商家對接的開放平臺，不涉密，商家技術(shù)、業(yè)務(wù)人員可以通過該地址上的接口說明進(jìn)行商家對接。

1.系統(tǒng)結(jié)構(gòu)

門票直連系統(tǒng)是通過接口，把商家的門票數(shù)據(jù)導(dǎo)入到美團(tuán)上收單，按用戶行為軌跡來說，實現(xiàn)“搜索-預(yù)定-下單-支付-售后”的自動化。異常情況通過郵件等形式預(yù)警，手工介入處理。

①正常情況下，涉及前臺和用戶行為的業(yè)務(wù)流程：

②涉及后臺的產(chǎn)品數(shù)據(jù)&訂單狀態(tài)更新（部分簡略）：

2.接口總覽

按接口類型和屬性可分為三類：數(shù)據(jù)類、交易類和通知類。有一部分為美團(tuán)接口，另一部分接口需要商家進(jìn)行開發(fā)。

1. 數(shù)據(jù)類：商家數(shù)據(jù)對接到美團(tuán)（涉及到商家的4個接口，拉取產(chǎn)品信息、產(chǎn)品變化通知、拉取景點信息、拉取價格日歷）
2. 交易類：“用戶——美團(tuán)——商家”的交易行為（涉及到商家的5個接口）
3. 通知類：包括商家開發(fā)的已出票、票已使用、已退款3個接口，美團(tuán)自有的已退款、查余額、編審狀態(tài)通知的3個接口。

異常問題

我做過的接口產(chǎn)品不多，但問題類似，主要包括兩類：接口問題、產(chǎn)品問題。接口問題就是無響應(yīng)、響應(yīng)過慢、重復(fù)響應(yīng)等，產(chǎn)品問題就是存量少、變價快、時間差導(dǎo)致下架更新不及時等。

在做接口相關(guān)的產(chǎn)品時，異常與正常流程同等重要，這與核心用戶和邊緣用戶不是一個概念。所以在考慮每一步的流程時，必須兼顧異常問題的發(fā)生與解決方法，盡量避免損害用戶體驗和商家損失。

一般的解決方法是數(shù)據(jù)監(jiān)控，通過對每個業(yè)務(wù)節(jié)點的多項指標(biāo)進(jìn)行監(jiān)控，一旦超出閾值，就可以用郵件、短信等形式通知相關(guān)人員，及時解決問題。

接下來我們從兩個方面具體探討如何應(yīng)對這些問題。

1.用戶體驗——具體場景&數(shù)據(jù)監(jiān)控

對用戶來說，流程的任一節(jié)點不順暢，都會導(dǎo)致體驗不好，故根據(jù)用戶行為軌跡來進(jìn)行數(shù)據(jù)監(jiān)控。

①頁面展示慢——接口響應(yīng)時長、用戶頁面停留時長、跳失率

• Reason：實時調(diào)接口查詢景點&產(chǎn)品信息，因數(shù)據(jù)量大或頻率快導(dǎo)致。
• Solution：緩存數(shù)據(jù)，每N分鐘更新一次。

②數(shù)據(jù)展示異常——后臺返回接口異常的次數(shù)和概率

• Reason：接口超時或異常。
• Solution：可以設(shè)定重復(fù)調(diào)用，多次重試失敗后，通過郵件等形式通知到運營、技術(shù)或商家。

針對數(shù)據(jù)型接口，對產(chǎn)品進(jìn)行下架或隱藏處理。

針對交易型接口，下單、支付的問題可以提醒用戶、為用戶推薦同類產(chǎn)品、對產(chǎn)品進(jìn)行下架或隱藏處理；退票類問題可以建議用戶之后重試，如果比較緊急可以聯(lián)系客服加急處理。

針對通知型接口，不涉及用戶，郵件處理即可，可人工介入更新信息。

③產(chǎn)品變動，特別是變價——下單失敗率、變價率、出票失敗率

• Reason：數(shù)據(jù)更新有時間差。
• Solution：

1. 當(dāng)某一產(chǎn)品的失敗率或變價率超出規(guī)定，可隱藏或下架；
2. 針對某些產(chǎn)品庫存少的情況進(jìn)行提示，預(yù)告風(fēng)險；
3. 設(shè)定合理的定時更新任務(wù)。

④下單/支付/退票失敗——失敗率、失敗原因

• Reason：用戶可能多次提交，或者訂單已使用、已關(guān)閉等客觀原因，無法成功。
• Solution：

1. 需要加入檢驗機制，比如在短時間內(nèi)重復(fù)提交不調(diào)用接口，直接返回原結(jié)果；
2. 善意提醒用戶不要重復(fù)提交，如“您的手太快了，請休息30s后再試”；
3. 可以提供IM人工或電話咨詢、留言等選項。

⑤服務(wù)響應(yīng)時間長——手工操作訂單量和占比

• Reason：比如用戶提交退票后長時間不退款；支付后長時間不出票
• Solution：

1. 定時調(diào)用訂單查詢接口，更新訂單狀態(tài)并短信/推送消息告知用戶；
2. 超過服務(wù)規(guī)范時間前發(fā)送預(yù)警郵件，人工介入處理。

2.商家體驗——數(shù)據(jù)監(jiān)控&具體場景

對商家來說，用戶體驗不重要，轉(zhuǎn)化率和利潤才是重點，故數(shù)據(jù)監(jiān)控以業(yè)務(wù)指標(biāo)為主。

①重復(fù)生單、生單不支付占庫存——訂單量、訂單支付轉(zhuǎn)化率、支付失敗率、庫存占用量和支付量

• Reason：用戶手速太快；惡意占庫存
• Solution：制定規(guī)則，同一人只能占一個庫存；同一訂單最多只能訂N個人。

②惡意重復(fù)調(diào)用接口——涉及到的每個接口調(diào)用頻率

• Reason：比如短時間重復(fù)調(diào)用某一接口
• Solution:

1. 規(guī)定同一IP地址不能在短時間內(nèi)多次調(diào)用；
2. 直接返回第一次調(diào)用接口的結(jié)果，不再重復(fù)調(diào)用；
3. 每個接口在同一時間最多N次調(diào)用，否則返回失敗等。

③因數(shù)據(jù)更新不及時等導(dǎo)致的虧損——（傭金、廣告）投入產(chǎn)出比、人為損失

• Reason：用戶使用后退款完成、用戶支付后變價等
• Solution：根據(jù)時間差、處理規(guī)則來明確劃定責(zé)任方。

④結(jié)算問題——財務(wù)對賬自身支出（退款）和收入（美團(tuán)給商家的結(jié)算金額）

• Reason：平臺和商家以“T+N”的方式結(jié)算
• Solution：

1. B端訂單系統(tǒng)里的財務(wù)對賬功能，可以用郵件形式每日發(fā)送；
2. 監(jiān)測異常數(shù)據(jù)，如當(dāng)日無結(jié)算、結(jié)算金額與訂單金額不一致。

以上即為接口主要的應(yīng)用對象和邏輯，邏輯不難但復(fù)雜度高，需要細(xì)心周到地考慮各種情況，希望能與大家一起討論。




本文摘自人人都是產(chǎn)品經(jīng)理