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