API-First產(chǎn)品經(jīng)理們的常用API標(biāo)準(zhǔn)與工具
譯文【51CTO.com快譯】
最近,我們采訪了一些產(chǎn)品經(jīng)理,他們均來自舊金山的那些年收入過1億美元的API-First公司。此次采訪主要聚焦于API產(chǎn)品的采用率(Adoption)、使用度(Engagement)、以及留存度(Retention)三個領(lǐng)域,重點和他們了討論各種常用的工具,以及各項最關(guān)心的API標(biāo)準(zhǔn)。下面我們來看看具體的內(nèi)容。
大量數(shù)據(jù)的切入
分析數(shù)十億條針對API調(diào)用所需的存儲和記錄,往往會涉及到大量的數(shù)據(jù)。因此,它所產(chǎn)生的數(shù)據(jù)湖(Data lakes)也往往變得過于龐大,以至于與之對應(yīng)的追溯分析,必須被限制在幾天甚至是幾個小時之內(nèi)才能完成。
在此類情況下,API-First公司所采取的第一步便是:將非結(jié)構(gòu)化的API數(shù)據(jù)、或整個原始的syslog(系統(tǒng)日志),轉(zhuǎn)儲到Amazon Redshift(https://aws.amazon.com/redshift/)或Splunk(https://www.splunk.com/)中的數(shù)據(jù)湖里。從那里,數(shù)據(jù)架構(gòu)團(tuán)隊可以將產(chǎn)品經(jīng)理感興趣的syslog事件提取出來,并將它們傳遞到Snowflake(https://www.snowflake.com/)之類的數(shù)據(jù)倉庫中,以便于查詢。此處,由商業(yè)智能團(tuán)隊、產(chǎn)品經(jīng)理、甚至是工程師,來把控實際處理和匯總的相關(guān)數(shù)據(jù)標(biāo)準(zhǔn)。
采用率:工具和標(biāo)準(zhǔn)
對于與大多數(shù)API-First公司來說,產(chǎn)品經(jīng)理持續(xù)跟蹤的第一個、也是最重要的標(biāo)準(zhǔn)是開發(fā)者激活(developer activation)。具體而言,產(chǎn)品在采用環(huán)節(jié)上會涉及到如下步驟:
- 注冊新的賬號
- 首次API的調(diào)用
- 部署一個有效的API
API-FIRST公司團(tuán)隊會使用Tableau(https://www.tableau.com/)或Looker(https://looker.com/)所提供的儀表板,來顯示正在注冊的人數(shù)、已注冊的人數(shù)、已登錄的人數(shù)、正在創(chuàng)建的應(yīng)用數(shù)、以及應(yīng)用中的API令牌數(shù)(API tokens)。
產(chǎn)品經(jīng)理運用OKR(Objectives and Key Results,目標(biāo)與關(guān)鍵成果法),致力于提高開發(fā)者激活率,并減少激活時間。由于開發(fā)人員可能會在上述某個階段停留數(shù)天、或是更長的時間,因此跟蹤每個步驟的轉(zhuǎn)化率,以及抵達(dá)下一步所需的時間是非常重要的。例如:如果API的正常銷售周期為90天,那么產(chǎn)品經(jīng)理就會關(guān)注四個分位數(shù),即第50天和第75天等時間點的狀態(tài),進(jìn)而來確定對應(yīng)的SDK(軟件開發(fā)工具包)和文檔的實用性。
一旦API被采用,產(chǎn)品經(jīng)理往往希望能夠看到使用量的增加,付費訂閱方案的轉(zhuǎn)化,以及被準(zhǔn)確識別出的功能缺陷。當(dāng)然,客戶是否真的愿意付費購買,也取決于其所在公司的規(guī)模,是大型企業(yè)、小微企業(yè)還是初創(chuàng)型企業(yè)。
使用度:企業(yè)客戶的工具和標(biāo)準(zhǔn)
通過營銷渠道獲取API令牌
大多數(shù)公司會通過提供面向用戶的控制臺,來方便其應(yīng)用被使用到,進(jìn)而通過跟蹤各項活動,來獲悉用戶對目標(biāo)API的采用率和使用度。用戶往往會通過Web管理界面,來進(jìn)行注冊,配置其帳戶,管理可用的API,以及打開或關(guān)閉某些功能。如果您的API監(jiān)控工具并非以用戶為中心,也就是說,它無法深入地研究API的調(diào)用,并確定其歸屬于哪個用戶和公司,那么產(chǎn)品經(jīng)理就必須部署Heap(https://heap.io/)或Google Analytics 360(https://marketingplatform.google.com/about/analytics-360/)之類的分析工具了。這些工具可以被配置為:將Web界面上的某個用戶與組織中正在進(jìn)行的API調(diào)用相關(guān)聯(lián)。
據(jù)此,產(chǎn)品經(jīng)理可以跟蹤Google或Facebook廣告相應(yīng)的營銷渠道歸因(marketing channel attribution),以獲悉從帳戶創(chuàng)建到轉(zhuǎn)換為付費用戶的時間,以及他們首次開始進(jìn)行API調(diào)用的時間。
如果直接使用了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)之類以用戶為中心的工具,那么產(chǎn)品經(jīng)理可以與HTTP狀態(tài)響應(yīng)代碼相同的方式,有效地監(jiān)視UTM(Urchin Tracking Module)參數(shù)。據(jù)此,他們可以按照UTM來源或UTM活動,對API令牌進(jìn)行分組,以便更好地區(qū)分哪些營銷渠道最為實用。
每周活動API令牌數(shù)
在給定的一周內(nèi)訪問某個API的令牌數(shù)量,被稱為每周活動令牌數(shù)(Weekly Active Tokens,WAT)。這也是產(chǎn)品經(jīng)理用來跟蹤其產(chǎn)品的最佳標(biāo)準(zhǔn)之一。與在線時間(Uptime)、服務(wù)水平目標(biāo)(SLO)、以及每分鐘請求數(shù)等工程類目標(biāo)標(biāo)準(zhǔn)不同,WAT需要與推動采用率、以及增加使用度等業(yè)務(wù)目標(biāo)上保持一致。為了計算WAT,數(shù)據(jù)架構(gòu)團(tuán)隊需要從Redshift中提取相關(guān)的syslog事件,將其傳遞給Snowflake。之后,BI團(tuán)隊再編寫SQL查詢語句,以實現(xiàn)在Tableau中的可視化。
由于一個開發(fā)者帳戶能夠會創(chuàng)建諸如:可用于沙箱、或生產(chǎn)環(huán)境的多個API令牌,因此更準(zhǔn)確的衡量標(biāo)準(zhǔn)是“每周活躍用戶數(shù)(Weekly Active Users)”或“每周活躍公司數(shù)(Weekly Active Companies)”。不過,這些需要有機(jī)構(gòu)能夠?qū)PI令牌鏈接到相應(yīng)的用戶或公司帳戶上,進(jìn)而執(zhí)行基礎(chǔ)分析。
用戶數(shù)
一些產(chǎn)品經(jīng)理會發(fā)現(xiàn):帳戶轉(zhuǎn)換與用戶數(shù)量之間存在直接的關(guān)聯(lián)。也就是說:更多的用戶,通常意味著客戶會更多地使用API項目。因此,項目經(jīng)理往往會通過“邀請其他人參加該項目,以幫助您完成工作”之類的活動,去吸引和邀請更多人加入到注冊流程之中。由此帶來的另一個額外的好處是:產(chǎn)品經(jīng)理們可以從用戶那里獲得其他用戶的公司郵箱地址。畢竟邀請者可能不知道受邀者的Gmail地址,但是他們知道與之有工作往來的伙伴的郵件地址。
自助服務(wù)客戶
一些獨立的開發(fā)人員往往會選擇自助購買的業(yè)務(wù)類型。不過,在大多數(shù)情況下,這些開發(fā)人員既不想與產(chǎn)品經(jīng)理交流,又不愿與銷售人員交談,更懶得回復(fù)電子郵件。實際上,他們會經(jīng)常使用個人郵件進(jìn)行注冊,以隱藏真實的工作信息。因此,產(chǎn)品經(jīng)理很難從他們那兒,或是一些小微企業(yè)處,獲得更多的反饋與見解。
當(dāng)然,產(chǎn)品經(jīng)理們也可以通過查看,開發(fā)人員在產(chǎn)品使用過程中,所涉及到的基本內(nèi)容、API調(diào)用的內(nèi)容、以及在GitHub處API SDK使用情況的統(tǒng)計信息,來側(cè)面收集開發(fā)人員的使用體驗。
留存度
一旦產(chǎn)品經(jīng)理對采用率和使用度有了一定的了解,他們就會通過API產(chǎn)品的留存度,來發(fā)現(xiàn)需要改進(jìn)的地方。產(chǎn)品經(jīng)理可以通過將用戶群根據(jù)注冊日期等維度進(jìn)行細(xì)分,以跟蹤他們再次回來進(jìn)行使用、調(diào)用、甚至與平臺有所互動的百分比。如下圖所示,通過將API留存度按照用戶的SDK進(jìn)行分組,他們會發(fā)現(xiàn)PHP的留存率會遠(yuǎn)遠(yuǎn)低于其他SDK。這就意味著該API對于PHP的調(diào)用存在著錯誤,或需要通過修復(fù)來提高其性能。
此外,要確定是否添加或去除某個API或產(chǎn)品的功能,產(chǎn)品經(jīng)理們也會查看SKU(Stock Keeping Unit)的計費情況。許多API會針對不同的活動類型,被分為一系列相互獨立的SKU。通過查看誰在為哪些SKU付費,產(chǎn)品經(jīng)理就可以確定哪些需要保留或增強(qiáng),而哪些可以斷舍離。
跟蹤設(shè)定的標(biāo)準(zhǔn)并不容易
設(shè)置一套可用作跟蹤的標(biāo)準(zhǔn),往往涉及到通過與業(yè)務(wù)團(tuán)隊協(xié)作,對可能的使用請求進(jìn)行精準(zhǔn)地分類。其代表性的步驟包括如下五個方面:
1)目標(biāo)數(shù)據(jù)是否有對應(yīng)的事件?
2)如果是的話,那么它們是否能被存儲在數(shù)據(jù)倉庫中?如果不是的話,則需要數(shù)據(jù)架構(gòu)團(tuán)隊創(chuàng)建一個新的syslog事件,然后將其引入數(shù)據(jù)倉庫。
3)創(chuàng)建關(guān)于如何在Tableau中可視化數(shù)據(jù)的標(biāo)準(zhǔn),或定制報告。
4)讓BI數(shù)據(jù)團(tuán)隊執(zhí)行請求。
5)如果BI團(tuán)隊無法實現(xiàn)數(shù)據(jù)的可視化,則需要工程人員對數(shù)據(jù)庫本身進(jìn)行自定義的SQL查詢。
小結(jié)
良好的工具對于API-First公司的產(chǎn)品經(jīng)理來說,不但能夠獲取開發(fā)使用者的獨到見解,并且能夠確保提供成熟且可靠的SDK,以及完整的文檔。如今,諸如Moesif之類的API分析工具,可幫助API驅(qū)動型企業(yè),對API數(shù)據(jù)進(jìn)行深入研究,并做出更加明智的決策,以推動企業(yè)及其API產(chǎn)品不斷迭代并創(chuàng)造價值。
【原標(biāo)題】API-First Product Managers’ Popular API Tools and API Metrics ,作者: Larry Ebringer
【51CTO譯稿,合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】