API-First产品经理们的常用API标准与工具
最近，我们采访了一些产品经理，他们均来自旧金山的那些年收入过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查询。
小结