【51CTO.com快譯】

最近，我們采訪了一些產品經理，他們均來自舊金山的那些年收入過1億美元的API-First公司。此次采訪主要聚焦于API產品的采用率(Adoption)、使用度(Engagement)、以及留存度(Retention)三個領域，重點和他們了討論各種常用的工具，以及各項最關心的API標準。下面我們來看看具體的內容。

大量數據的切入

分析數十億條針對API調用所需的存儲和記錄，往往會涉及到大量的數據。因此，它所產生的數據湖(Data lakes)也往往變得過于龐大，以至于與之對應的追溯分析，必須被限制在幾天甚至是幾個小時之內才能完成。

在此類情況下，API-First公司所采取的第一步便是：將非結構化的API數據、或整個原始的syslog(系統日志)，轉儲到Amazon Redshift(https://aws.amazon.com/redshift/)或Splunk(https://www.splunk.com/)中的數據湖里。從那里，數據架構團隊可以將產品經理感興趣的syslog事件提取出來，并將它們傳遞到Snowflake(https://www.snowflake.com/)之類的數據倉庫中，以便于查詢。此處，由商業智能團隊、產品經理、甚至是工程師，來把控實際處理和匯總的相關數據標準。

采用率：工具和標準

對于與大多數API-First公司來說，產品經理持續跟蹤的第一個、也是最重要的標準是開發者激活(developer activation)。具體而言，產品在采用環節上會涉及到如下步驟：

• 注冊新的賬號
• 首次API的調用
• 部署一個有效的API

API-FIRST公司團隊會使用Tableau(https://www.tableau.com/)或Looker(https://looker.com/)所提供的儀表板，來顯示正在注冊的人數、已注冊的人數、已登錄的人數、正在創建的應用數、以及應用中的API令牌數(API tokens)。

產品經理運用OKR(Objectives and Key Results，目標與關鍵成果法)，致力于提高開發者激活率，并減少激活時間。由于開發人員可能會在上述某個階段停留數天、或是更長的時間，因此跟蹤每個步驟的轉化率，以及抵達下一步所需的時間是非常重要的。例如：如果API的正常銷售周期為90天，那么產品經理就會關注四個分位數，即第50天和第75天等時間點的狀態，進而來確定對應的SDK(軟件開發工具包)和文檔的實用性。

一旦API被采用，產品經理往往希望能夠看到使用量的增加，付費訂閱方案的轉化，以及被準確識別出的功能缺陷。當然，客戶是否真的愿意付費購買，也取決于其所在公司的規模，是大型企業、小微企業還是初創型企業。

使用度：企業客戶的工具和標準

通過營銷渠道獲取API令牌

大多數公司會通過提供面向用戶的控制臺，來方便其應用被使用到，進而通過跟蹤各項活動，來獲悉用戶對目標API的采用率和使用度。用戶往往會通過Web管理界面，來進行注冊，配置其帳戶，管理可用的API，以及打開或關閉某些功能。如果您的API監控工具并非以用戶為中心，也就是說，它無法深入地研究API的調用，并確定其歸屬于哪個用戶和公司，那么產品經理就必須部署Heap(https://heap.io/)或Google Analytics 360(https://marketingplatform.google.com/about/analytics-360/)之類的分析工具了。這些工具可以被配置為：將Web界面上的某個用戶與組織中正在進行的API調用相關聯。

據此，產品經理可以跟蹤Google或Facebook廣告相應的營銷渠道歸因(marketing channel attribution)，以獲悉從帳戶創建到轉換為付費用戶的時間，以及他們首次開始進行API調用的時間。

如果直接使用了Moesif(https://www.moesif.com/features/api-monitoring/?utm_source=dzone&utm_medium=blog&utm_campaign=placed-article&utm_term=api-prod-managers-popular-tools-metrics)之類以用戶為中心的工具，那么產品經理可以與HTTP狀態響應代碼相同的方式，有效地監視UTM(Urchin Tracking Module)參數。據此，他們可以按照UTM來源或UTM活動，對API令牌進行分組，以便更好地區分哪些營銷渠道最為實用。

每周活動API令牌數

在給定的一周內訪問某個API的令牌數量，被稱為每周活動令牌數(Weekly Active Tokens，WAT)。這也是產品經理用來跟蹤其產品的最佳標準之一。與在線時間(Uptime)、服務水平目標(SLO)、以及每分鐘請求數等工程類目標標準不同，WAT需要與推動采用率、以及增加使用度等業務目標上保持一致。為了計算WAT，數據架構團隊需要從Redshift中提取相關的syslog事件，將其傳遞給Snowflake。之后，BI團隊再編寫SQL查詢語句，以實現在Tableau中的可視化。

由于一個開發者帳戶能夠會創建諸如：可用于沙箱、或生產環境的多個API令牌，因此更準確的衡量標準是“每周活躍用戶數(Weekly Active Users)”或“每周活躍公司數(Weekly Active Companies)”。不過，這些需要有機構能夠將API令牌鏈接到相應的用戶或公司帳戶上，進而執行基礎分析。

用戶數

一些產品經理會發現：帳戶轉換與用戶數量之間存在直接的關聯。也就是說：更多的用戶，通常意味著客戶會更多地使用API項目。因此，項目經理往往會通過“邀請其他人參加該項目，以幫助您完成工作”之類的活動，去吸引和邀請更多人加入到注冊流程之中。由此帶來的另一個額外的好處是：產品經理們可以從用戶那里獲得其他用戶的公司郵箱地址。畢竟邀請者可能不知道受邀者的Gmail地址，但是他們知道與之有工作往來的伙伴的郵件地址。

自助服務客戶

一些獨立的開發人員往往會選擇自助購買的業務類型。不過，在大多數情況下，這些開發人員既不想與產品經理交流，又不愿與銷售人員交談，更懶得回復電子郵件。實際上，他們會經常使用個人郵件進行注冊，以隱藏真實的工作信息。因此，產品經理很難從他們那兒，或是一些小微企業處，獲得更多的反饋與見解。

當然，產品經理們也可以通過查看，開發人員在產品使用過程中，所涉及到的基本內容、API調用的內容、以及在GitHub處API SDK使用情況的統計信息，來側面收集開發人員的使用體驗。

留存度

一旦產品經理對采用率和使用度有了一定的了解，他們就會通過API產品的留存度，來發現需要改進的地方。產品經理可以通過將用戶群根據注冊日期等維度進行細分，以跟蹤他們再次回來進行使用、調用、甚至與平臺有所互動的百分比。如下圖所示，通過將API留存度按照用戶的SDK進行分組，他們會發現PHP的留存率會遠遠低于其他SDK。這就意味著該API對于PHP的調用存在著錯誤，或需要通過修復來提高其性能。

此外，要確定是否添加或去除某個API或產品的功能，產品經理們也會查看SKU(Stock Keeping Unit)的計費情況。許多API會針對不同的活動類型，被分為一系列相互獨立的SKU。通過查看誰在為哪些SKU付費，產品經理就可以確定哪些需要保留或增強，而哪些可以斷舍離。

跟蹤設定的標準并不容易

設置一套可用作跟蹤的標準，往往涉及到通過與業務團隊協作，對可能的使用請求進行精準地分類。其代表性的步驟包括如下五個方面：

1)目標數據是否有對應的事件?

2)如果是的話，那么它們是否能被存儲在數據倉庫中?如果不是的話，則需要數據架構團隊創建一個新的syslog事件，然后將其引入數據倉庫。

3)創建關于如何在Tableau中可視化數據的標準，或定制報告。

4)讓BI數據團隊執行請求。

5)如果BI團隊無法實現數據的可視化，則需要工程人員對數據庫本身進行自定義的SQL查詢。

小結

良好的工具對于API-First公司的產品經理來說，不但能夠獲取開發使用者的獨到見解，并且能夠確保提供成熟且可靠的SDK，以及完整的文檔。如今，諸如Moesif之類的API分析工具，可幫助API驅動型企業，對API數據進行深入研究，并做出更加明智的決策，以推動企業及其API產品不斷迭代并創造價值。

【原標題】API-First Product Managers’ Popular API Tools and API Metrics ，作者: Larry Ebringer

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】