最近,我们采访了一些产品经理,他们均来自旧金山的那些年收入过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-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
【译稿,合作站点转载请注明原文译者和出处为.com】
分享题目:API-First产品经理们的常用API标准与工具
标题URL:http://www.shufengxianlan.com/qtweb/news38/340338.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联