詳解API：應用程序編程接口終極指南
我們一批成熟的 API 優(yōu)先公司使用Tableau或Looker儀表板來顯示有多少人正在注冊、有多少人正在登錄、有多少人正在創(chuàng)建應用程序以及有多少應用程序創(chuàng)建了 API 令牌。為了使 Tableau 和 Looker 儀表板運行得更快，您可以清除設備上的緩存。
PM 的 OKR 主要致力于提高開發(fā)人員的激活率并確?？s短激活時間。由于開發(fā)人員可能會在單個漏斗階段停留數天甚至更長時間，因此跟蹤每個步驟的轉化率以及到達下一步所需的時間非常重要。
如果正常銷售周期為 90 天，則 PM 喜歡查看四分位數：第五十四分位數在做什么，第七十五四分位數在做什么，然后他們使用它作為代理來確定他們的 SDK 和文檔有多大用處。
一旦 API 被采用，PM 希望看到使用量增加，從而促成付費計劃、突出熱門端點以及識別缺失功能的能力。在此階段，客戶的購買動向根據其公司規(guī)模分為兩類：大型企業(yè)或中小型企業(yè)/初創(chuàng)公司。
大多數情況下，領導層都會要求大多數開發(fā)人員評估 API 產品的可能性。有時他們會創(chuàng)建一個開發(fā)人員組織并試用所有功能。然后，當他們的公司決定簽署協(xié)議時，他們實際上最終會提供一個單獨的帳戶。將開發(fā)人員組織映射到付費帳戶，并將收入帳戶綁定到 Salesforce 中，并不總是非常清晰。因此，PM 有時不會嘗試解決該映射問題，而是只關注更多的采用，因為采用是客戶是否會使用該產品的一個很好的指標。
大多數公司認為，在面向用戶的控制臺中跟蹤活動有助于提高使用率和參與度。當客戶注冊、配置帳戶、管理可用的 API 或打開和關閉功能時，他們會通過管理 Web 界面。如果您的 API 監(jiān)控工具不是以用戶為中心的（即它無法深入研究 API 調用并確定其歸屬用戶和公司），那么 PM 必須部署Heap或Google Analytics 360等分析工具。然后配置這些工具以將 Web 界面上的用戶與其組織中其他人可能進行的 API 調用相關聯(lián)。
然后，PM 可以跟蹤營銷渠道對相應 Google 或 Facebook 廣告的歸因。他們可以從創(chuàng)建帳戶開始，一直跟蹤到客戶轉換為付費計劃，再到他們首次開始進行 API 調用。
在 Moesif 等以用戶為中心的工具中，UTM 參數的監(jiān)控方式與 HTTP 狀態(tài)響應代碼的監(jiān)控方式相同。這樣就可以按 UTM 源或 UTM 活動對 API 令牌進行分組，從而更好地了解哪些營銷渠道有助于提高參與度。
在給定的一周內訪問 API 的不同令牌的數量，即每周活躍令牌(WAT)，是產品經理用來跟蹤其產品的最佳北極星指標之一。與正常運行時間、SLO 或每分鐘請求數等與工程目標保持一致的基礎設施指標不同，WAT 與推動采用和提高參與度的業(yè)務目標直接保持一致。為了計算 WAT，數據基礎設施團隊需要從 Redshift 中提取相關的系統(tǒng)日志事件并將其傳遞到 Snowflake 中。到達那里后，BI 團隊編寫 SQL 查詢并在 Tableau 中將其可視化。
由于單個開發(fā)者帳戶可以創(chuàng)建多個 API 令牌（例如用于沙箱和生產環(huán)境），因此更準確的衡量標準是Weekly Active Users或Weekly Active Companies 。然而，這需要能夠將 API 令牌鏈接到相應用戶或公司帳戶的分析基礎設施。
“讓邀請他人變得容易”
一些產品經理發(fā)現帳戶轉換和用戶數量之間存在直接相關性。更多的用戶通常意味著客戶對項目更加認真。因此，產品經理會通過諸如“邀請其他人加入這個項目來幫助你完成工作”之類的話來推動邀請其他人加入注冊流程。通常，額外的好處是，這是從用戶那里獲取公司電子郵件的另一個機會，因為邀請者可能不知道被邀請者的 Gmail，但會知??道他們的工作電子郵件。
在自助服務購買動議中，客戶是一名獨立開發(fā)人員，在 5 人或 10 人的初創(chuàng)公司或中小型企業(yè)中，他只需插入 CTO 信用卡即可立即開始使用付費服務。
除了 PM 為企業(yè)帳戶所做的工作之外，很難從這個群體中獲得更多見解，因為大多數開發(fā)人員非常喜歡自助服務路線。
“這不是一個絕對的聲明，但在大多數情況下，開發(fā)商不想與你交談，他們不愿意與銷售人員交談，也不想回復電子郵件。事實上，他們經常使用個人電子郵件注冊，試圖隱藏他們?yōu)檎l工作，”舊金山的總理。
然而，通過查看開發(fā)人員在產品中使用的內容、他們點擊的內容、他們進行的 API 調用以及來自 GitHub 中 API 的 SDK 的使用統(tǒng)計信息，可以在一定程度上收集開發(fā)人員情緒的代理信息。
在項目經理對采用和參與度有了很好的了解后，他們開始研究 API 產品留存率，以找到需要改進的領域。產品留存率是一個源于收入留存率的概念，需要將用戶群細分為群組，例如通過注冊日期。項目經理會跟蹤每個群組返回與您的平臺互動的百分比。在下面的示例中，API 留存率按用戶的 SDK 分組。您可以看到 PHP 的留存率遠低于其他 SDK，這意味著 PHP 存在錯誤，或者存在需要修復的性能問題。
確定要添加或棄用哪些產品功能的另一種方法是查看計費 SKU。許多 API 被分為一組 SKU，每種不同的活動類型都分配有自己的單個 SKU。通過查看誰為哪些功能付費，可以確定哪些功能正在使用，哪些功能沒有使用。
從項目經理的角度來看，監(jiān)控商業(yè)智能的速度無疑是一個問題。
一位不滿的總理表示：“從提出新指標請求到得到統(tǒng)計數據，需要花太長時間。”
設置指標跟蹤的過程分為五個步驟。它涉及向單獨的 BI 團隊發(fā)出請求，然后該團隊必須對請求進行分類，然后將其納入，并且通常涉及談判和政治。代表性步驟包括：1) 所討論的數據是否有事件？2) 如果答案是肯定的，那么它是否在數據倉庫中？如果答案是否定的，那么數據基礎設施團隊中的某個人需要創(chuàng)建一個新的系統(tǒng)日志事件，然后將其納入。3) 創(chuàng)建指標在 Tableau 中可視化的方式的要求或更改報告。4) BI 數據團隊必須執(zhí)行請求。5) 如果 BI 因太忙或超出其能力而無法將其可視化，那么 PM 將不得不要求工程部門對數據庫本身進行自定義 SQL 查詢。
原文鏈接：API-First Product Managers’ Popular API Tools and API Metrics
