Destroy API onboarding and how to repair it
2022-03-21PV：138
Even the best APIs in the world have funnels. Potential users can only abandon the process as long as they register and may even complete the operation. In some cases, the causes of this situation are inevitable. For example, the product may be too expensive.
In other cases, something happens between the process of registering and actively using the API. Checking people's progress in the registration process may help you determine the reason for this decline, but then again, it may not.
In this article, we will explore some reasons why potential users may abandon the API before starting to use it. We will also study how to reduce API abandonment attempts and testing methods, as well as some emerging solutions.
Show, Don’t Tell, (With Code Samples)
杰弗里·摩尔(Geoffrey Moore)的《跨越鸿沟》是1991年出版的一本关于科技营销的书。你可能已经看过这本书的标志性图表，这是一条钟形曲线，直观地勾勒出创新者、早期采用者、大多数人以及技术采用落后者的模式。
代码示例与文档一样重要（尽管可能不比文档更重要）的想法是一个很难不同意的想法。打个比方，您不太可能会在看了数码相机的使用说明书后，没有看到一些使用数码相机拍摄的照片或将相机握在自己手中的情况下购买。
关于“拿着相机”的想法，如果你能提供一个沙箱，提供一个沙箱是一个好主意。如果没有，请考虑免费试用或免费增值模式。
付费API的创建者可能会拒绝免费提供呼叫的想法，但也许他们不应该——让开发人员在承诺购买之前自由探索 API 是良好入职流程的一部分。
如果每月的少量电话足以满足他们的要求，那么他们可能永远不会注册付费帐户。至少，在这个模型中，他们保持活跃，并且如果他们需要你的服务扩展，他们可能会升级。
同伴支持
sudoHERO 的创始人Chris Chandler建议“与其他客户群体不同……开发人员实际上更喜欢通过阅读可能有助于解决问题的信息来找到答案，然后再聘请支持代表。”2017年的一项小规模研究表明，开发人员平均每天进行 16 次搜索来完成他们的工作，其中一个主要搜索类别是“理解 API”。
这不是因为开发人员在遇到问题时不喜欢认输。Chandler继续说：“要准确诊断问题，需要传达无数变量，以便重现问题并提供合理的答复。”
提交支持请求时，通常会丢失一些重要的上下文。结果？“在等待数小时甚至数天后得到答复后，最初的支持票可能会得到答复，要求对问题的某些部分进行澄清。一旦提供，消息就会回到队列中，开发人员等待……再次。”
换句话说，提供 24/7 全天候支持可能并不是您认为的卖点。
同行支持感觉更像是与其他开发人员进行头脑风暴，而不是提交支持票，它可以成为入职流程的一个引人注目的补充，因为它让潜在用户了解那些已经在使用该产品的人正在做什么。
这是Miro做得很好的事情，在Hacker News和90年代论坛之间有一个吸引人的UI。请注意，Miro的开发者关系主管会定期介入以帮助人们；这有助于支持站点感觉更像是一个活跃的社区，充满可搜索的问答，而不是人们大喊大叫。
这与在 Apple 的支持社区中搜索 MacBook 或 iPhone 的问题并找到数百名遇到相同问题的其他人……但没有人提供解决方案完全不同。
文档悖论
Zapier的首席技术官Brian Helmig在与Codementor的对话中说：“信息应该在需要时自动分配。”
我们已经一次又一次地写了关于优秀文档的价值的文章，但是成功地做到这一点存在一种隐含的冲突：最好的API文档应该足够容易消化，不会让人不知所措，但也应该包括所有内容（或关闭到它）开发人员可能需要知道。这些想法相互矛盾。
使用自动化，Chandler正在尝试使用sudoHERO的上下文支持工具来解决这个问题。他建议“在解决问题时，开发人员通常会首先返回文档以查看语法并确认他们对如何使用命令或函数的理解。如果那里没有找到答案，他们就会到别处寻找更多信息。”
显然，对于宁愿让消费者留在“他们的世界”中的API开发人员来说，这并不理想。
为了应对这种漂移，该公司提供了一种工具，公司可以使用该工具将其他开发人员的知识库文章和相关见解直接嵌入到他们的文档中：
我们已经看到像Yext这样的公司希望使用AI来改变对消费者的搜索，但“超越搜索”的想法在API空间的背景下具有一些非常有趣的可能性。
当前版本的sudoHERO上下文支持从 iscourse开发者论坛中显示相关信息并从Stack Overflow中选择标签，因此它最适合严重依赖开发者社区来支持其用户的产品。然而，Chandler表示，对于依赖票务系统（而不是开发人员社区）的公司，还有一个额外的解决方案正在开发中。
随着时间的推移，根据反馈，该产品在向开发人员提供最佳可用答案方面变得更好。反过来，像这样的工具可以识别其文档的哪些部分产生最多的查询，并可以使用该信息来澄清它。
测量和迭代
培养引人入胜的开发人员体验并不是一个“一劳永逸”的过程。 当您第一次创建开发人员门户和文档时，会涉及大量的猜测。 但是，随着时间的推移，您可能希望改进此过程。
在您的API门户中找到一种方法来跟踪用户和潜在用户的行为是识别瓶颈和感兴趣领域的好方法。当您知道它们是什么时，您可以分别解决和强调它们。
Pronovix的零重力开发人员门户就是这种文档体验的一个例子，它优先考虑迭代和为作者/编辑提供引人入胜的编辑体验。
创建引人注目的文档不仅仅是使用OpenAPI规范和Swagger工具（其中一些可用于从OpenAPI规范生成多个文档版本），但它仍然是一个很好的起点。
小结
在我们关于首次调用时间 (TTFC) 作为API指标的重要性的文章中，我们谈到了旨在消除注册和开始使用产品过程中的障碍。上面，我们概述了一些关键的方法来做到这一点：
让人们了解如何使用 API 的代码示例
一旦他们准备好自己加入，就有大量的文档
通过建立社区和更好的环境来超越传统的支持
基于用户行为的反馈和分析迭代上述过程
这篇文章的标题指出API载入已损坏。这并不总是完全正确的，但API入职通常确实落后于SaaS领域中存在的一些完善的渠道。而且，随着API现在被更多地视为独立产品，这没有任何借口。
幸运的是，工具和系统似乎正在（或已经在这里）帮助API开发人员将他们的入职培训提升到一个新的水平。
Posted by: ArtCopywriter
参考：API abandonment
