hprof文件生成原因（hprof文件怎么产生的）



原文：Moesif Blog

协议：CC BY-NC-SA 4.0

原文：https://www.moesif.com/blog/technical/cpu-arch/What-Every-Web-Developer-Should-Know-About-CPU-Arch-Part1/

介绍

有很多讨论软件开发范例和最佳实践的博客文章，也有一些是关于硬件的。与此同时，从计算机体系结构的角度来看，讨论每个开发人员应该知道什么的文章的数量我一只手就能数出来。本文的目标不是深入探究 CPU 架构、操作系统等。我将概述一些原则，这些原则是我们作为开发人员在繁忙的日子里可以放松的。

线程与进程

安全性和可靠性

在 Docker 容器和 VM 出现之前，CPU 硬件有一个最古老的沙盒技巧:进程和虚拟内存。作为开发人员，您应该明白，一个进程将在它自己的隔离内存空间中运行，并且只能通过特定的机制(如进程间通信(IPC))与其他进程对话。因此，如果您有进程 A 和进程 B，并且它们都有一个逻辑地址 0x0，那么它们实际上指向物理内存中两个独立的区域。现代 CPU 硬件通过分页提供安全保护，确保进程只能从自己的内存空间读写。常见的分段错误实际上最初是由 CPU 硬件通过一个 #PF(页面错误)由于非法访问而触发的。(注意:我将省略 x86 分段，因为分段寄存器在 64 位模式下不再真正“使用”)。

另一方面，同一进程中的线程共享相同的地址空间。访问同一个地址空间可能是好事也可能是坏事。如果线程崩溃，应用程序的状态可能是未知的。硬件中没有安全保护来防止流氓线程以非预期的方式访问其他线程的数据。事实上，Chrome 开始在自己的进程中运行每个浏览器标签，而不是仅仅使用多线程。如果你曾经在 Chrome 标签中看到“哦，Snap…”的话，那是一个无意中执行了某些东西的过程。失败的选项卡崩溃并且不再运行，但是剩余的选项卡可以照常继续工作。

这不是意味着进程必须在内存中复制代码和数据吗？

是也不是。现代操作系统和硬件可以用一种叫做写时复制(COW) 的东西做一些聪明的事情。当您在 Linux 中调用 fork()时，最初并不是所有内容都被复制到内存空间的一个新部分。确保进程不会写入进程外内存空间的同一个分页硬件也可以在写入标记为只读的页面时抛出#PF。此标志允许操作系统处理故障，这意味着如果需要，将旧页面复制到内存中的新页面。

使用进程不需要缓慢的上下文切换吗？

是的，进程需要上下文切换，但是线程也需要。一个线程还具有附加到它的执行上下文，它由它的各种 CPU 寄存器值(例如 x86 中的 EAX、EBX…)组成，在下一个线程可以开始执行之前需要存储其他内容。事实上，现代 SIMD 编码，如许多视频编码和压缩算法，以观看您最喜爱的高清网飞节目，使用一些相当大的寄存器，需要写入内存。事实上，AVX 的最新版本由 32 个 64 字节宽的寄存器组成！当提到进程比线程慢时，通常指的不仅仅是上下文切换本身，而是刷新翻译后备缓冲器(TLB)中的条目。TLBs 保存了我们前面提到的分页机制的缓存翻译。因为一个新进程将在它自己的内存空间中执行，所以它不能使用旧进程的翻译，并将重新开始。这意味着 TLB 对新的工艺将会冷淡。如果翻译不在 TLB 中，则在存储器访问完成之前，页面未命中处理器(PMH)需要逐级遍历页面表。页表遍历是繁重的指针追踪算法，可以降低加载延迟。有一些捷径可以最大限度地减少行走所需的关卡数量，但最终的问题是寒冷的 TLB 会导致加载延迟远远大于温暖的 TLB。即使被访问的变量已经在某个地方的 CPU 缓存中，也会发生这种情况(我们将在后面讨论)

所以最终的结论是，流程的上下文切换可能不会太长，但是可能会有延迟的影响，甚至会降低后上下文的速度。

线程太多。

在这个寒冷的 TLB，过程并不是唯一可以忍受的东西。如果线程没有被调度在同一个逻辑 CPU 上(CPU 亲缘关系)，也可以经历这种情况。这引出了下一个问题:应用程序可以运行的逻辑 CPU 数量是固定的。虽然现代操作系统有许多进程和线程可以在各种阻塞和等待状态下同时运行，但实际上 CPU 一次只能运行固定数量的线程。无论线程是否在同一个进程中，都是如此。当你启动更多的线程，然后你可以积极地运行，操作系统必须抢先上下文切换。如果您只是为每个任务生成一个又一个线程，认为它将全部并行运行，您可能会惊讶地发现，与在一个线程池中运行少量线程相比，您对性能的损害可能更大。

一般来说，大量线程会导致系统颠簸。系统颠簸是一个通用术语，当 CPU 开始交换或移动资源而不是执行实际执行时使用。CPU 的资源大小是有限的，TLB、高速缓存、甚至内存中分配的页表都是有限的。当您开始在更多线程之间切换时，您可能会给这些子系统带来压力，导致仍然热的数据被驱逐，这对性能是有害的。默认情况下，许多异步 web 框架被配置为将它们的工作线程池与逻辑核心的实际数量相匹配，或者它们可以添加一些额外的阻塞，但仍然在一个数量级内。想想优步的司机。有时候，让长途旅行的乘客上车，开一会儿车，然后不断地让新乘客上车，让老乘客下车，会更容易、更快捷。乘客数量是您的固定资源，如逻辑处理器、缓存大小和 TLB。如果你接了新乘客，你必须先赶走老乘客，为新乘客腾出空间。如果您开始发现自己在等待卸载和装载，而不仅仅是驾驶(工作或执行)，这种进出行为就是颠簸。

第二部分

这是较长系列的第 1 部分，请继续关注下一部分

谢谢

我们感谢我们的精选测试版客户，他们一直在试用 Moesif，为我们提供了宝贵的反馈，使调试变得更加容易。

原文：https://www.moesif.com/blog/api-product-management/developer-platforms/What-Is-An-API-Product/

我们都听说过 API 产品或 API-as-a-product 这样的术语。这些术语本身似乎使用得相当自由，让我们中的一些人对其含义有一个假设，但没有真正牢固的掌握。随着加入 API 经济并为其做出贡献变得越来越受欢迎，API 产品成为任何寻求利用它的企业的重要组成部分。所以问“什么是 API 产品？”是一个有很多不同角度的相关问题。

API 产品与任何其他产品没有什么不同:它以某种方式、形状或形式传递价值。在 API 的上下文中，我们基本上是说，我们已经创建并打包了一个可以为内部和外部组织带来价值的 API。您可能决定从一开始就构建一个 API 产品，或者您可能选择将 API 产品化，作为数字化转型推动的新商业模式的一部分。

您可能熟悉的 API 产品的几个例子是:

谷歌地图

google maps API 可能是使用最广泛的 API 之一。大多数需要任何类型的位置查找、地理跟踪或任何其他基于位置的功能的网站和移动应用程序都可能使用谷歌地图 API。简单的入门、使用和优秀的文档是这款产品的一些标志。

Tomorrow.io

Moesif customer Tomorrow.io 也是一个很好的 API 产品的例子。该 API 被大大小小的组织所使用，实现了真正的 API 产品方法，提供了丰富的开发人员文档、多个定价层以及 API 消费者注册和自助服务/板载的能力。

如您所见，API 产品通常专注于一组特定的功能，比如位置查找或当前天气。这些公司已经找到了一种方法来创建 API，为其他开发者和他们的组织提供价值。这就是构建 API 产品的真正含义。

因为任何为开发者提供价值的 API 都可以转化为 API 产品，所以对于开发者和构建它的公司来说，看看什么是好的 API 产品是很重要的。

自助集成

开发人员以自助方式从注册到实际使用 API 的能力至关重要。大多数开发人员不喜欢复杂的入职或由销售团队领导的入职。开发人员应该能够注册和订阅您的 API，并以一种非常“低接触”的方式集成它，只有当他们遇到独特的情况或无法克服的错误时，才会寻求支持。这也可以通过使用 API 网关或 API 管理平台来改进，以确保 API 集成和 API 访问在所有 API 资源中是统一的。

开发者文档

由于 api 是高度技术性的，好的 API 文档对于支持好的产品是至关重要的。帮助 API 消费者的开发人员文档应该相对多样化，包括集成技巧、如何使用特性，甚至如何解决开发人员可能面临的常见问题。你也可以考虑通过添加全面的书面和视频教程来进一步增强你的文档，这些教程向 API 消费者展示如何实现共同的结果。

API 货币化

要开发一个产品并维持下去，你需要增加收入。对于 API，这意味着弄清楚向 RESTful API 开发人员收取什么费用，以及如何实现这个过程。作为一个 API 提供商，通常，你需要决定你是否有一个免费的试用或免费层，如果你要做预付费或后付费计费，以及你将使用哪个计费提供商。这些考虑是你的 API 货币化策略的关键方面。当然，API 货币化可能非常复杂，但让结账、管理费用和收款变得容易是良好客户体验的关键。

收集用户反馈的能力

在您构建产品时，您会希望不断改进和增加客户使用的关键领域的价值。这意味着您需要收集关键的操作数据、用户数据和 API 调用的使用度量。将这些因素结合在一起将有助于您开发一个更稳定的 API 产品，它是高性能的，并且在客户最常用的所有领域都有交付。这也是深入了解您的入职体验并揭示客户在采用您的 API 的早期阶段可能会遇到的挑战的一个很好的方式。

Moesif 可以通过利用该平台的一些核心特性来帮助公司构建优秀的 API 产品。这些特性有助于实现我们上面提到的一些要点，这些要点是成功的 API 产品的一部分。Moesif 可以帮助简化 onboarding、API 货币化、帮助开发人员导航产品等等。让我们看看下面的一些细节。

用户渠道

使用 Moesif 的用户漏斗分析，您将能够在用户旅程的每个步骤中看到某些趋势和转化率。如果你把焦点放在入职上，这很能说明问题。例如，您可能有这样一个用户漏斗:

• 注册
• 第一次 API 调用
• 第二次 API 调用
• 第 1000 次 API 调用

通过跟踪这一点，您将能够看到一些关键的见解:

• 有多少人注册了却从来不做 API 调用？
• 有多少人进行了第一次 API 调用而没有后续调用？
• 开发人员进行第 1000 次 API 调用的比例是多少？

你还可以看到在顾客旅程的不同阶段之间转换所花费的时间，并想出可能的改进方法。例如，你可能认为从注册到第一次 API 调用，用户应该只需要 5 分钟。但是，当查看数据时，您会发现实际上平均花费了一个多小时。这可能暗示您需要改进您的集成步骤，或者只是简单地添加一些更好的文档。

当您进行这些改进时，您可以不断地检查转换的改进以及步骤之间花费的时间。这将有助于你确定你是走向优化还是远离优化。

计费仪表

Moesif 计费表允许你轻松地将你的 API 货币化。这是可能的，因为 Moesif 允许你拨入你的计费标准，然后 Moesif 会将 API 使用统计数据发送给你选择的提供商，例如 Stripe 、 Recurly 或 Chargebee 。让你的 API 成为产品的一大障碍是实际实现端到端的解决方案来实现你的 API 货币化模型。有了 Moesif，这不再是一个问题。例如，看看这个使用 Moesif、Stripe 和 Kong 的现成 API 货币化示例。计费表也可以与 moesif 中创建的 API 治理规则很好地匹配。这些规则可以用于阻止基于未付发票的端点的 API 请求。

行为邮件

无论是“欢迎”邮件、“后续步骤”邮件，还是帮助陷入困境的开发人员的邮件，与客户建立积极的沟通渠道都是至关重要的。这些类型的电子邮件可以让客户参与进来，还可以帮助他们解决问题，而不必寻求支持。

使用 Moesif，您可以为何时发送电子邮件创建特定的标准。这可能是当用户注册您的 API 时，当他们使用新添加的 API 功能或许多其他场景时，他们在 30 分钟内从一个端点收到超过五个 401 响应。设置这些电子邮件极其简单，并且可以不费吹灰之力为您的客户体验增加价值。

警报

Moesif 允许您设置一些条件，在这些条件下，您的团队将收到诸如新客户注册、入职问题、持续错误等事件的警报，而不是以手动方式主动监控开发人员。这些警报可以发送到许多不同的渠道，包括电子邮件，短信，寻呼机，Slack，或一个自定义的网络挂钩。

通过设置警报，您的支持团队(和其他人)可以在客户找到他们之前主动采取措施帮助他们，或者更糟的是，决定放弃使用 API。

嵌入式模板

您可以为用户构建一个自定义仪表板，以查看诸如实时日志或用户使用时间序列之类的内容。Moesif 可以通过嵌入的模板特性帮助加速这一过程。有了嵌入式模板，您可以使用您最喜欢的图表，甚至那些无法访问 Moesif 的人也可以使用它们。例如，您可以在您的 API 仪表板中嵌入一个时间序列图表，其中添加了一个配额行，以显示开发人员离达到其配额还有多远，以及他们的 API 请求量如何随时间变化。

API 产品与任何其他产品没有什么不同，它们都要求用户在使用产品时有一个轻松愉快的体验。像大多数产品一样，分析可以帮助确保您在采用和客户满意度方面朝着正确的方向前进。Moesif 可以帮助挖掘这些分析，获得洞察力，并允许您通过行为电子邮件或警报等功能采取行动。要升级您的 API 产品游戏，现在就注册 Moesif 的,获得深入的见解和功能，帮助您发展和改进平台。

原文：https://www.moesif.com/blog/api-engineering/api-observability/What-is-API-Observability/

API 可观察性是正确执行 APIOps 循环并确保您为 API 用户构建有价值的东西的关键要素。如果你对 APIOps 周期不熟悉，看一看本指南中的，它提供了一个敏捷框架来快速构建面向业务和服务客户需求的 API。API 可观测性本身是传统监控的一种进化，脱胎于控制系统理论。

传统的监控侧重于跟踪已知的未知情况。这意味着您已经知道要度量什么，比如每秒请求数或每秒错误数。虽然度量值可能事先不知道，但是您已经知道要测量或探测什么，比如一个计数器来跟踪桶中的请求。这使得可以报告系统的健康状况(如红色、黄色、绿色)，但对于解决工程或业务问题来说，这是一个糟糕的工具，因为这通常需要询问任意的问题。

您如何确定自己已经达到了传统监控的极限？嗯，当你正在调查一个问题，你告诉你的同事“我们可以解决这个问题，但我们没有合适的背景”。上下文是一个负载词，但它意味着你的解决方案无法回答未知的未知。相反，您需要修改您正在跟踪的指标，重新部署，然后最终查看结果以获得该上下文。

API 可观测性源于控制系统理论，通过推断状态和行为，从系统的输出尽可能多地观察系统的内部工作。有了一个复杂的分析工具来分析所有这些数据，您就能够回答任何关于您的 API 行为的任意问题，而不仅仅是一些可直接测量的预定义指标。这意味着你可以回答任何关于你的“黑匣子”如何进入这种状态的问题，甚至可以重现这种状态。

API 可观察性不仅仅用于诊断 API 所表现出的工程问题，它还可以帮助诊断业务问题。这些可能在本质上更抽象，但与观察你的身体服务有着相同的原则，只是扩大了范围。为了实现这一点，您不仅需要对物理基础设施进行全面观察，还需要对其他投入进行全面观察，如收入、增长和销售效率指标。这使您能够将您的“黑匣子”从仅仅一项服务扩展到整个产品或业务单位。

通过将您的 API 中发生的事情与更广泛的业务信息(如客户人口统计)联系起来，我们现在能够回答业务问题。例如，我们可以看到哪些客户请求了缺货的商品。我们不需要直接有一个计数器来测量每个顾客的缺货商品的数量。相反，像 Moesif 这样的高基数、高维度分析系统能够跟踪从 API 流出的所有信息，使我们能够动态地创建这个报告。在这种情况下，所有信息都已经可以用来创建任意报告。

原文：https://www.moesif.com/blog/developer-relations/definition/What-is-Developer-Relations-and-What-are-Common-Roles/

开发者关系不仅仅是 API 优先公司的一个角色或部门。开发者关系是一种心态，让开发者采用一个平台，让他们的计划成功，而不是试图卖给那些开发者。这使得开发者关系不同于传统的销售和营销角色。然而，如果你问“什么是开发商关系？”，您可能会得到许多模棱两可的回答，因为开发人员关系是各种不同角色和职位的总称。有些头衔包括“开发者倡导者”和“开发者传道者”，但也可以包括其他新的头衔，如“开发者体验经理”。“这些角色因公司而异，甚至在公司的不同团队中也是如此。

这篇文章概述了 devrel 中的一些不同角色，例如:

• 开发者福音传播者
• 开发商代言人
• 开发者体验
• 开发者营销

开发者关系的艺术是在你的社区内建立真实的关系，而不是向他们推销或营销。这可以通过面对面、在线或其他方式完成。与开发人员的任何交流通常都属于 devrel 的范畴，需要高超的技术交流技巧，与角色无关。一些开发人员关系角色专注于社区参与和宣传。其他 devrel 角色专注于产品管理和开发者体验。

当工程师听到开发人员关系时，就会想到开发人员传道者的角色(也称为技术大使)，因为这是最受关注的角色之一。一个开发者传道者专注于“把话传出去”。这可能意味着在会议上发言、参加聚会和举办黑客马拉松。他们的日程表很快就被承诺排满了，出差的时间可能比在办公室的时间还多。然而，他们也花费大量时间在线创建代码样本、网络研讨会和主持虚拟办公时间。布道者必须有技术头脑，但不一定自己就是工程师。他们大部分时间都在充当公司的品牌大使。

与开发人员布道者不同，开发人员倡导者的目标不是制造轰动，并向全世界介绍你的平台。相反，开发人员倡导者的角色更多的是客户成功和产品之间的融合。他们的目标是让开发人员能够成功地利用您的平台和 API，同时向内部产品团队宣传他们的需求。他们是更大的社区和各种内部产品团队之间的有效纽带。他们可能会收集反馈，创建演示和代码示例，或者找到产品问题和产品缺陷的解决方案。在一些公司，他们可能表现得像“销售工程师”或“解决方案顾问”，通常比布道者更专业。

就像移动应用需要好的用户体验一样，好的 API 需要好的开发者体验(DX)。对于开发人员使用的任何东西，一个专门的开发人员体验团队的行为就像事实上的产品所有者一样。他们可能拥有入职流程、SDK/API 设计和文档。在一些公司中，开发人员关系存在于产品组织中，并拥有整个开发人员体验。在其他公司，devrel 可能与市场营销保持一致，导致开发人员体验归另一个团队所有，如产品团队或专门的开发人员体验团队。

营销本身通常不包含在 devrel 的保护伞下，但是 devrel 确实与开发者营销紧密合作，保证了它的包含。开发者营销有传统的营销目标，如营销合格的线索(MQLs)和推动收购。然而，对开发者的营销与传统的 B2B 或 B2C 营销有很大不同。如果它围绕着“集客营销”的原则，创造一个吸引人们的品牌，而不是把一个品牌推给开发商。开发者营销几乎总是涉及大量内容联合战略，但也包括付费渠道，如广告词，以及活动赞助。开发商营销可能会赞助一个会议，他们公司的一个拥护者会在会上发言。

Devrel 是一个现有的新领域。如果你是一家 API first 或平台公司，拥有一个 devrel 团队可以帮助你与开发者建立关系，而不会在营销或销售方面显得过于强势。

原文：https://www.moesif.com/blog/technical/api-analytics/What-Is-Dynamic-Sampling-And-How-It-Works/

有时，您可能希望限制进入 Moesif 的分析数据量。这可能是因为您想要排除特定的流量，例如内部或运行状况检查流量，或者您可能想要减少不必要的数据以控制成本。我们的企业计划为客户提供的动态采样正是为此而构建的。动态采样允许您根据客户或 API 行为控制将哪些 API 调用记录到 Moesif。Moesif 智能推断指标，即使在多采样率下也能准确报告。这意味着，无论您设置了什么样的规则或采样速率，您都可以确保您看到的仍然是数据的准确表示。

动态采样通过在 Moesif 仪表板中设置采样规则来控制。您可以根据请求路径、响应状态代码、用户或公司行为等标准创建规则。您还可以控制每个规则应用的采样速率。采样率是事件进入 Moesif 的百分比。例如，如果您设置一个规则，对 50%的事件进行采样，那么 Moesif 将智能地记录一半的匹配事件(而不是每隔一个事件记录一次，以满足 50%的采样率)。

我们的动态采样功能适用于客户的两种使用情形:

• 让用户能够减少 Moesif 中过多或不感兴趣的呼叫，同时保留您从平台中获得的洞察力。
• 允许用户降低其企业订阅成本并节省资金。Moesif 会考虑您创建的采样规则，并智能地推断使用指标。

抽样的 API 调用不计入您的配额；例如，如果您的 API 通常每月看到 100 万个 API 调用，但全局采样率被设置为 25%，则只有每月进入 Moesif 的 25 万个事件将计入该配额。

如果您避免对进入 Moesif 的特定事件进行动态采样，那将是最好的。这些用例包括当您利用其他 Moesif 功能时，如计量计费或治理规则，您希望在 Moesif 中评估每个呼叫。

对进入 Moesif 的 API 调用数量进行动态采样会影响货币化的 API，因为它无法跟踪确切的使用情况，可能会遗漏一些事件，这取决于所应用的采样率。这将影响您的计费仪表和发送给客户的发票。但是，一种解决方法是对未货币化的端点应用动态采样，并让事件以 100%计入您的计费表样本。

不使用动态采样的另一个原因是，当记录的 API 调用少于订阅计划支持的调用数量时。例如，假设您正在进行的 API 调用比您的订阅计划包括的要少。在这种情况下，动态采样是不必要的，除非您只是试图在 Moesif 中排除不想要的数据，以保持数据的整洁。这方面的示例可能不包括来自运行状况检查探测器或内部测试的流量。

动态采样规则分为四种样本集，并按以下方式排列优先级:

• 单个用户或公司的采样速率
• 基于正则表达式规则的采样率
• 基于用户行为和人口统计数据的采样率(保存的群组)
• 全球适用的采样速率

这意味着，如果为特定客户设置了采样率，这将优先于与客户所属的行为群组相关联的采样率。全局采样速率的优先级最低，默认情况下，所有客户的采样速率都设置为 100%。如果一个 API 调用与多个规则匹配，它将由优先级层次结构中的第一种采样率进行处理。

现在您已经了解了什么是动态采样以及它能做什么。我们简单看一下如何设置一些动态采样规则。首先，导航到 Moesif 中的动态采样屏幕。

在这里，我们可以访问已经创建的所有采样率。

选择 + Rule 按钮将允许我们创建新的用户或公司、正则表达式或群组采样规则。

特定用户或公司

选择新用户规则或新公司规则后，分别选择用户查找或公司查找按钮。

在本例中，我们将展示用户查找，但公司的流程是一样的。

继续从用户列表中选择一个 ID 进入他们的 剖面图 。您可以使用 Users Where 过滤器快速找到您要寻找的用户。

在“采样速率”下的“配置文件”视图中，选择铅笔图标以更改特定用户的采样速率。

禁用继承切换以允许调整用户的采样速率。通过手动输入速率或使用滑块设置所需的采样速率，然后选择保存。

正则表达式规则

返回到动态采样规则页面，在 +新下拉菜单中选择新正则表达式规则，输入您想要的标准和采样率并保存。在这个例子中；我们将采样率设置为零，以排除对任何健康端点的所有 GET 请求。这些呼叫不会出现在用户界面中，也不会计入我们的活动配额。

通过保存的群组获得行为或人口统计数据

通过利用保存的群组完成行为和人口统计采样；如果你对保存的队列不熟悉，请查看我们的博客文章、书面指南或视频指南以了解更多信息。

设定群组的取样率相当容易。在动态抽样规则页面选择 +新按钮，然后选择新用户规则或新公司规则。将出现一个模式，让您选择一个普遍保存的群组。继续设置所需的采样速率和优先级。优先级在用户或公司群组内排序。用户样本规则始终优先于公司样本规则。

全球的

您可以通过点击动态采样规则页面上的设置按钮来应用全局规则。出现的结果模式允许您设置全局采样速率，抑制已知的 bot 流量，以及明确或通过 regex 规则阻止来自给定 IP 地址的流量。模态的底部展示了在其各自的用户配置文件中设置了采样速率的所有用户或公司。

出于许多原因，动态采样可能是 Moesif 配置的重要组成部分。我们还回顾了一些限制和场景，在这些场景中，动态采样不是最佳选择，比如在对端点应用计费计量或治理规则时。最后，我们讨论了如何在 Moesif 内部建立不同类型的规则。

如果您已经加入了 Moesif 企业计划，那么您可以使用动态抽样。请随意查看我们的深度书面教程或视频指南。如果您没有企业计划，您可以联系我们的销售团队来解锁这一强大的功能。如果您是 Moesif 的新手，今天就注册，开始为您的组织释放 API 分析的力量。

原文：https://www.moesif.com/blog/engineering/middleware/What-Is-HTTP-Middleware/

为了从任意环境中捕获 API 调用，我们必须为许多常见的 web API 框架创建中间件。这里介绍的一些知识也可以帮助那些创建中间件的人。

特别是，我们为以下框架创建了中间件:

• Python Django
• Ruby on Rails
• PHP Laravel
• 节点快递
• Java servlet
• 春天
• 球衣
• 支柱

什么是中间件？

我使用术语中间件，但是每种语言/框架对这个概念的称呼不同。NodeJS 和 Rails 称之为中间件。在 Java 企业世界(即 Java Servlet)中，它被称为过滤器。C#称之为委托处理程序。本质上，中间件在用户定义的控制器之前或之后的 HTTP 管道中的特定阶段对 HTTP 请求或响应执行一些特定的功能。中间件是一种设计模式，可以在没有很多代码接触点的情况下，雄辩地添加横切关注点，如日志记录、处理认证或 gzip 压缩。

由于这些横切关注点是在中间件中处理的，控制器/用户定义的处理程序可以专注于核心业务逻辑。

中间件能做什么

中间件通常非常灵活。一些中间件是被动的，比如日志中间件。gzip 压缩等其他中间件可以对请求或响应主体执行转换。中间件可以添加 HTTP 头，添加供业务逻辑使用的内部标志，等等。这是管道设计模式的实现。

事实上，甚至像主体解析这样的基本框架特性也可以被认为是中间件。如果框架中包含的那些不适合您的用例，您可以为各种二进制协议添加定制的主体解析。

您甚至可以调用其他服务，例如在 Redis 中查找会话令牌，或者从 MaxMind 数据集执行 GeoIP 查找。

如果你想做某件事，首先要考虑的是中间件。所以中间件最适合横切关注点。如果它是一个特定的业务逻辑，只适用于很少的情况，那么，也许中间件不是正确的选择。

如果您应用程序有许多常见的任务(比如日志记录、身份验证、解析 JSON 或者向每个请求或响应添加一些公共共享数据)，那么将逻辑重构到中间件中是有意义的。

表演

由于中间件的跨领域特性，确保它的性能尤其重要，因为任何增加的延迟都可能影响整个应用程序。延迟可能来自 I/O，如磁盘或网络访问。

例如，如果您为需要在 SQL Db 中查找用户信息的 API 创建了身份验证中间件，那么 I/O 读取将会停止 HTTP 请求管道，直到收到来自 SQL Db 的响应。即使使用 NodeJS 这样的非阻塞框架，客户端仍然会看到增加的延迟。

关于延迟与带宽的初级读本

延迟与带宽是两个正交但相关的指标。带宽指的是诸如每秒请求数或一次活动客户端或连接的最大数量等指标。另一方面，延迟是指对第一个字节的响应时间，或者执行特定查询的平均时间。然而，它们是相关的，因为延迟的增加也会减少系统的带宽。例如，增加等待时间也可能增加队列的驻留时间。

通常，NodeJS 等非阻塞框架主要关注通过不占用资源(即线程)来增加应用程序的带宽*。类似于添加额外的虚拟机或负载平衡器来处理额外的流量。然而，无论系统的带宽如何，也无论使用非阻塞还是阻塞架构，每个用户或客户端仍可能经历高延迟。* *对于我们的例子，更好的解决方案可能是使用内存中的散列表，比如 Redis，通过会话令牌进行查找。更低延迟的解决方案是使用 JSON Web 令牌(JWT ),其中安全认证和授权只需要 CPU 周期。

一些框架，比如 Node，被设计成自下而上的非阻塞 IO。然而，在其他框架中(比如 PHP 或 Ruby on Rails)，在后台线程上执行 IO 或处理繁重的任务是很重要的。

被动中间件

尽管存在上述 NIO 的局限性，但这并不是说它对减少延迟没有好处。特别是对于只写 I/O 的被动中间件，将中间件设计成非阻塞或异步的是理想的。例如，Moesif 的中间件不修改响应，所以 HTTP 管道没有理由等待任何对 Moesif 的写入。因此，我们将 Moesif 中间件设计成异步的。

对于 PHP Laravel 这样的阻塞框架，您可能需要实现自己的异步方法。对于 Moesif Laravel 中间件，我们利用一个 unix fork 在一个单独的进程中处理向 Moesif 发送任何数据。

令人惊讶的是，在 linux 中派生一个进程是一个轻量级的任务。关于原因的更多信息，请阅读每个 web 开发者应该知道的关于 CPU Arch 的事情

排序

每个中间件都被实例化为管道中的一个步骤，因此排序对于功能正确性可能很重要。然而，即使两个中间件可以重新排序，您也应该考虑性能或安全问题。具有短路返回路径的轻量级中间件应该在较重的中间件之前。

例如，通过 301 永久重定向将非 HTTPS 重定向到 HTTP 域的中间件应该放在解压缩和解析请求体的中间件之前。否则，你就是在浪费 CPU 周期来解压一个将被丢弃的身体。

还要考虑安全性和 DDoS 保护。如果只有一个特定的 IP 地址白名单被允许访问您的 API，而所有其他的都被拒绝，那么您可能希望在执行昂贵的操作(如查询数据库中的帐户信息)之前检查 IP 地址。

基本框架

通常，您正在使用的框架实际上是建立在另一个框架之上的。例如，Ruby on Rails 构建在 Rack 之上。所以当你在构建一个 rails 中间件时，你实际上是在为 Rack 构建一个。

这可以为你所用。在 Moesif，我们不需要为每个 Java 框架创建一个单独的中间件。相反，我们发布了一个单独的 Java Servlet SDK。许多现代 Java 框架都是建立在 Java Servlet 之上的，比如 Spring、Struts 和 Jersey。有时，您可以选择在 Java Servlet 之类的基础框架上构建，或者在 Spring 之类的高级 web 框架上构建。

构建中间件会迫使您深入研究每个框架更多底层技术。框架的许多公共服务(比如认证和主体解析)都是作为中间件实现的。

了解更多信息*

原文：https://www.moesif.com/blog/developer-platforms/self-service/What-Is-Product-Led-Growth-and-Why-Is-It-Critical-for-API-First-Companies/

有一种普遍的误解，认为产品导向的增长意味着企业不关注销售。事实并非如此。只是在客户旅程的后期，产品导向的增长会在销售中层层叠加。这可能是一种非常有效的方法，特别是当它与深入的数据洞察相结合来推动增长时。

对于 API 优先的公司来说，这种以产品为导向的方法是成功的基石。我们将在下面深入探讨为什么它如此重要的细节，但首先让我们从基础开始…

产品导向型增长正如其名称所暗示的那样——获取、激活、扩张和保留主要是由产品导向的。客户要么使用产品的免费版本，要么支付象征性的费用来使用它，只有在客户有机会直接看到产品的价值后，销售才会进入等式。

在产品主导的模式下，推动销售的是产品本身。通过使用该产品，在公司客户支持团队的支持下，同时在销售团队的支持下，客户几乎无缝地通过产品采用的四个阶段:激活、扩展、保留和采用。

使用产品导向的增长模式并不意味着假设产品自我销售，没有销售人员。这只是意味着销售团队关注人们实际上在用产品做什么，而不是坐在那里分析目标行业和创建理想的客户角色。他们的目标是增加现有客户的账户，而不是向冷淡的潜在客户销售。

通过在客户旅程的后期阶段进行分层销售，任务的性质发生了根本的变化。推销产品需要更少的努力，因为客户已经熟悉它和它所能提供的价值，所以推销新东西的努力就被消除了。相反，销售工作更多的是为组织创造更多的价值。这可能是让更多的团队使用产品，增加产品的使用率，或者找到更多的用例，以便客户升级到更高价值的计划。

谈到产品导向的增长，销售人员和客户成功团队之间有着紧密的联系。客户成功员工致力于确保客户从产品中获得最大收益——他们了解产品的价值，如何充分利用产品，以及产品如何为他们的业务带来最大利益。虽然重点是确保客户获得价值，而不是销售，但展示产品的潜力可以导致更深层次的整合和不断增长的使用。产品对客户的成功变得越来越重要。

产品导向型增长并不适合所有企业。例如，如果你在销售太阳能电池板，前期成本和安装过程就排除了使用产品导向的增长方式。然而，对于 API 优先的公司来说，让客户试用产品的成本和努力是最小的，产品导向的增长模式可能特别有效。

其中一个原因是，他们在一个购买变得更加分散的领域销售产品。个人开发人员将寻找适合他们特定用例的解决方案，并且他们可以以最低的成本试用。这些开发人员通常对销售和营销团队持怀疑态度，因此在做出任何重大承诺之前使用产品的实践性质在多个层面上起作用。

将技术团队作为一个整体进行销售可能会很困难。他们有源源不断的更高优先级的任务要处理，当你试图引入新事物时，你正在与“这里没有发明综合症”作斗争。事实上，当您尝试向他们销售新产品时，许多开发人员自然倾向于怀疑他们是否能够自己构建它！

产品导向的增长避开了这场艰苦的战斗，取而代之的是工程师们以他们自己的方式和速度发现产品。如果集成很容易，通过采用产品导向的方法，API 优先的公司正在授权个人开发者围绕为他们工作的 API 解决方案作出决定。一旦开发人员加入进来，与首席执行官的对话就变得容易多了。

为开发人员提供一种快速且经济的方法来测试 API，意味着他们可以用它来试验并证明这个概念。试用计划中负担得起的产品意味着在经理的信用卡上弹出一些东西，而不是通过繁琐的采购和法律审查过程。API 优先的公司，如果定价和 swift 集成正确，可以极大地减少产品上市过程中的摩擦。

这并不是完全绕过采购。远非如此。它是为开发者提供一个了解产品的简单机会——直接体验它，看看它对业务有多适合。给他们点击率高的服务条款、快速集成和他们可以用经理的信用卡支付的价格，你就为一个小规模的概念验证试验奠定了基础，这个试验有可能带来未来销量的突然飙升。随着所有相关的采购活动的进行，法律的束缚在后来的阶段自然地跳过了。

这种以产品为导向的增长方式需要围绕你的计费模式进行一些思考。这就是基于使用的计费发挥作用的地方。开发人员可以支付象征性的费用来开始使用该产品，并在他们完成概念验证的同时在他们的测试帐户中试用该产品。之后，当开发人员将产品投入生产时，基于使用量的计费模型需要随着客户使用量的增长而扩展。

API 非常适合这种现收现付的计费方式，因为有多种方法可以跟踪它们的使用。请确保您使用了正确的指标！从广义上讲，价值指标可以集中在以下几个方面:

• 交易量 API 调用次数、发送的消息数
• 收入/成本份额–收入百分比、交易费
• 数据量–发送的千兆字节，生成的分钟数
• 用户–每月活跃的独立用户
• 资源–计算单位、活动时间

这些例子暗示了可以嵌入基于使用的计费的巨大多样性。他们还强调了正确计费的复杂性。

以电子邮件自动化 API 为例，它允许客户创建电子邮件模板并向潜在客户发送电子邮件。以模板数量为中心的基于使用情况的定价可以让客户存储 1，000 个模板，并且发送零封电子邮件。客户将从产品中获得零价值，同时收到巨额账单，这使他们成为高风险客户。然而，基于发送的电子邮件数量或联系的不同联系人的账单，将与客户从产品中获得的真正价值密切相关，因此更有可能继续使用该产品。这就是实施正确的价值指标如此重要的原因。

使用数据推动销售是这里的关键。您的客户成功团队的支持需要在客户使用量不断增长的适当时机，无缝地融入与销售人员的对话中。为此，API 至上的公司需要数据。

通过跟踪客户健康状况和使用增长，销售团队可以在恰当的时候与客户展开讨论，以确保客户从其产品中获得更多价值。他们可以创建一个考虑当前使用情况和未来增长计划的计划。

这就是 Moesif 发挥作用的地方，它提供了一个可扩展的解决方案，该解决方案具有自动资源，可以标记使用量的增加，并建议(例如)进行讨论，以确保客户仍然采用最有价值的计划来满足他们的需求。

但是追踪使用数据不仅仅是为了找到合适的销售时机。这也是为了确保客户不会在使用量增加后收到巨额意外账单，然后由于成本意外上涨而取消。相反，销售人员适时打电话讨论更合适的计划可以确保客户觉得他们仍然物有所值，即使他们的账单增加了。

希望自己的产品引领发展的 API 优先公司不必坐等开发者发现它们。他们需要主动推销产品，以确保开发人员听说过它，并看到它有足够的潜力来试用它。

这意味着对开发人员体验的大量投资需要投入到鼓励与产品的初始接触中，并使开发人员更容易进行第一次概念验证。这可以通过教程、演示、技术文档、博客帖子、网络研讨会等方式实现。这种性质的内容成为销售漏斗不可或缺的一部分，因为它支持开发者首先试用产品。

在这种以产品为导向的模式下，易用性成为重中之重。从注册指南到集成演练，入职需要超级简单，因为每个绊脚石都会降低产品成功的可能性。与此同时，入职和试用流程需要尽可能实现自助服务，否则将无法轻松或快速地扩展。

同样，定价和包装模式在这里也很重要。许多公司都可以使用自助服务试用版，因此计费选项需要围绕各种各样的需求来构建。然而，每种模式的核心都需要低价来最初激活客户，并支持他们参与产品。在那之后，一旦他们意识到产品对他们的业务有多么有价值，是时候让 API 优先的公司让他们的销售团队施展他们的魔法了。

原文：https://www.moesif.com/blog/api-product-management/retention-analysis/What-Is-Product-Retention-And-How-Can-You-Improve-It/

产品保持率是检查企业健康状况的一个极其重要的指标。计算你的企业的保留率将返回给定时间段内继续使用你的产品或服务的用户的百分比。保留率实际上可以被视为衡量客户忠诚度的一个标准，也是您与新客户或现有客户关系质量的一个很好的反映。如何提高客户保持率是许多企业非常关心的问题，制定一个伟大的客户保持战略是解决这个问题的最佳途径。如果你能设法保持低客户流失率并继续留住客户，那么在获取客户方面做得很好才有意义。

客户保持率低可能是你的产品有问题的主要标志，包括产品价值的价格过高。高客户保持率意味着你当前的客户重视你的产品，产品的持续使用带来了可持续的收入来源。保持力分析很容易执行，但是使用像 Moesif 这样的平台来创建保持力分析是随着时间的推移跟踪客户保持力的最佳方式。让我们来看看保留报告每个部分的细节，以及如何在 Moesif 中创建和解释它们。

如果你的业务是 API，那么衡量产品留存率就有点不同了。衡量开发人员门户的登录情况可能不准确，因为开发人员通常不会每天或每周登录管理门户。衡量原料药产品保留率的最佳方法是通过一致的原料药活动。然而，并不是所有的 API 流量都是相等的。使用 API 流量作为保留报告的基础，需要考虑为客户创造价值的流量，而不仅仅包括任何 API 调用。如果您采用基于使用量的计费模式，为客户带来价值的流量可能与您收取的费用相同。API 业务的客户可能使用不同的 API 来满足不同的需求，这意味着您可能需要一种方法来过滤客户可能发送的特定字段或数量。例如，不应在保留报告中考虑 4xx 或 5xx HTTP 错误响应代码，因为这些通常是错误情况，会扭曲保留分析。

当我们考虑客户保留时，有两个重要事件用于确定用户是否被保留。初始事件被称为“第一个事件”，这将是您的保留报告开始的地方。第一事件可以通过确定用户何时第一次从产品接收价值来确定。对于电子商务平台，这可能是用户第一次实际创建采购订单。如果你是一个通信平台，第一个事件可能是用户通过该平台发送一条短信。您也可以将其推广为任何 API 调用。

保留分析的第二部分是当用户执行一个返回事件时，表明他们是一个回头客。返回事件是指客户返回平台，并执行一项活动，从产品中获得价值。通常，这是在第一个事件中执行的相同类型的事件，但也可能是完全不同的事情。每次用户执行返回事件时，他们都被视为保留用户。当用户不再执行返回事件时，用户不再被保留并且可能不再使用该产品。

在 Moesif 中创建保留报告很容易。第一步是导航到用户屏幕。一旦进入屏幕，接下来你要做的就是从屏幕左上方的下拉菜单中选择保留。

现在在保留屏幕上，您可以指定第一事件和返回事件。在本例中，我们将着眼于创建一个简单的保留分析，其中当用户在平台上进行购买和重复购买时，第一个事件和返回事件。我们还将通过指定响应状态代码等于 200 或 201 来确保仅包括成功的结账，表示成功的调用。下面是它在 Moesif 中的样子。

在 Moesif 中，如果未指定事件，Moesif 将根据为该用户接收的任何事件来计算保留时间。这有时很有用，但通常更准确地选择特定的第一个和返回事件。正如你所看到的，Moesif 自动创建了一个图表，描绘出客户保持曲线。

为了进一步细分保留报告，我们还可以考虑向数据添加分段和分组。

对于细分，我们可能希望只包括执行了某项活动的客户或属于我们客户群中某个细分市场的客户。例如，在我们之前构建的示例的基础上，我们可以添加一个细分子句，以查看企业和非企业客户在保留率方面的差异。为此，我们将添加细分市场，以区分这两种类型的客户。下面是一些例子。

另一个观察分析的角度是使用按分组的功能。这使我们能够看到不同用户群的保留情况。例如，我们可以将前面的示例改为只查看非企业客户，并添加一个 Group By ，以便按照 UTM Source 对该细分市场内的客户进行分组。这将向我们展示，根据用户来自哪个 UTM 来源，他们的客户保持率是什么样的。这可以帮助我们了解在创造忠诚客户时，哪些策略有效，哪些策略无效。这就是它的样子。

有了这两个额外的特性，我们可以真正深入挖掘客户维系的各个方面，并得出比没有细分和分组更深入、更具体的见解。

当实际查看保留报告时，了解您正在查看的内容非常重要。有几个场景显示了健康的保留，其他场景显示了不健康的保留或需要改进的保留。

保持力高/最佳

最佳保留率因行业而异，因此很难说您希望您的保留率达到什么水平。也就是说，有很多研究显示了行业的平均保留率，包括 ProfitWell 在 2020 年完成的这项研究。在此报告中，我们可以看到以下按行业划分的平均保留率:

• 零售:63%
• 银行业:75%
• 电信:78%
• IT: 81%
• 保险:83%
• 专业服务:84%
• 媒体:84%

根据你所在的行业，你显然希望确保你的留存曲线开始快速变平，并大致保持在这些目标附近。同样重要的是，看看你在做什么来保持这么高的客户保留率，并继续这样做来留住忠诚的客户。如果随着你对入职、业务流程、市场营销和其他因素的改变，保留率开始下降，你可能要考虑恢复到保留率较高时的策略。很可能你的服务或应用程序的体验没有达到客户的期望。你的客户保持策略应该始终以尽可能保持高的客户保持率为目标。

张力迅速下降

如果留存率迅速下降到较低水平，这通常意味着客户对产品不满意，或者没有从产品中获得价值来证明退货的合理性。如果您按月查看留存率，到第二个月留存率显著下降，您可能希望查看更短时间段的留存率，例如每周甚至每天。在记忆力差的情况下，好的一面是小的变化可能会导致巨大的差异。当保留率很低时，你需要继续密切关注潜在的改进，因为低保留率会给许多企业带来灾难。

保留报告没有显示多少历史记录

如果您的业务仅开展了 4 周，或者您仅跟踪了 4 周的留存率，那么很难查看 12 个月的留存率，因为数据不存在。如果您发现您的保留报告比您预期的更快停止，您需要确保您有足够的数据来支持您正在尝试查看的时间跨度。如果您的数据有限，请考虑使用更短的时间单位，例如每天或每周查看保留时间，直到您的数据增长到足以每月或每年进行评估。

当然，每家公司对他们应该保留的员工都有不同的期望。你很可能属于上述三种类型中的一种，甚至可能是多种。一旦你评估了你的记忆力，下一步就是保持它，或者更有可能的是，提高它。接下来，让我们看看提高记忆力的一些方法。

保持能力可能有点难，但是跟踪保持能力的指标是提高保持能力的第一步。有很多方法可以提高记忆力，根据你所处的行业，有些方法可能比其他方法更适用。这里有一些留住客户的策略，你可以尝试一下，从更多的忠诚客户中建立你的客户群。

完善您的入职流程

没有什么比糟糕的客户入职流程更能迅速吓跑新客户了。如果客户从未充分参与进来并发现你的产品的价值，就很难留住他们。这就是为什么提高你的入职培训是提高用户保持率的最佳方式。出色的入职体验通常会带来出色的客户体验，从而快速交付满足客户需求的解决方案。要了解您的入职流程在当前状态下的情况，您可能需要查看以下指标:

• 有多少用户正在开始入职流程，但尚未完成？
• 大多数人都放弃了入职流程。
• 在入职流程的哪个阶段，用户更有可能坚持到底？

一个极其复杂和漫长的入职流程会很快扼杀员工的忠诚度。用户发现价值的时间越短，你的入职就越有影响力。要使用 Moesif 深入了解入职，您可能希望使用我们的用户渠道功能来查看入职流程中的每一步，有多少人转换到下一步，以及完成每一步需要多长时间。更好的入职体验可能是通过改善整体客户体验来真正提高保留率的秘诀。

通过客户反馈调查吸引客户

喜欢你的产品的优秀客户可以回答一些关于他们为什么继续使用你的产品的问题。放下你的产品的顾客也可以提供同样多的见解。通过对这两类客户的客户调查获得客户反馈，可以深入了解用户留下和离开的原因，这是保持方程的核心。使用客户调查来建立定性的客户数据可以帮助你了解客户建立品牌忠诚度的快乐程度。

对于留下来的用户来说，询问他们最喜欢产品的哪些方面、他们属于哪个人群以及产品的哪些部分可能会让他们离开是很重要的(这可能是关于功能、可靠性甚至价格的问题)。一旦你发现是什么留住了用户，并发现了一些趋势，你就可以加倍努力，试图将这些好的氛围传播给新的和其他现有的客户。至于负面反馈，这可以优先考虑，以确保问题得到解决，从而提高保留率。

更重要的是，尤其是如果你的留存率已经很低的话，弄清楚为什么以前的用户会离开这个平台。在一个简短的调查中，你可以问这些客户他们为什么离开，怎样才能让他们回来。这将让你对问题和潜在的解决方案有更深入的了解，让你走上改进产品的正确道路，并有望提高客户保留率。一旦产品得到改进，你甚至可能会想联系这些以前的用户，让他们知道他们的反馈已经被听取，你很想让他们尝试你的新的和改进的体验。

客户反馈调查是一种非常有效的方式，可以获得对一些最大的客户体验和保留问题的简洁反馈，并可能帮助您发现影响客户满意度的问题，这些问题您甚至从来不知道。

一旦获得客户，不要停止营销

一旦有人注册、加入并使用了产品，许多公司就会停止营销。从逻辑上讲，这可能有道理，但实际上，这与事实相去甚远。你应该始终致力于吸引用户，让他们把你的产品和服务放在第一位。这可能包括时事通讯、产品发行说明和其他重要内容，以保持用户参与并发现产品的新价值。与客户保持联系并继续推广您的产品是让客户再次使用该产品并发现释放其价值的新途径的好方法。这应该是企业实施的几乎所有客户保留策略的基石。

对这种方法的一个很大的警告是，确保您使用智能自动化来持续向现有客户营销。使用包含与用户相关内容的个性化电子邮件，对于保持收到价值和被惹恼之间的界限至关重要。使用应用程序中的事件来驱动特定的电子邮件可能是一种很好的方式，例如当用户第一次使用某个功能时，您可以通过电子邮件向他们发送概述或文档链接，这样他们就可以根据需要深入了解。在 Moesif 中，可以通过使用行为电子邮件来进行这种类型的电子邮件营销，您可以根据应用程序的使用情况或应用程序中的特定事件或客户行为来触发特定的电子邮件。这可以作为一种方式来保持对现有客户的营销，同时也确保您提供良好的自动化客户支持。您还应该确保发送的电子邮件数量不会让用户不堪重负，从而有可能将您列入黑名单或退订名单。

现在，您已经知道了什么是客户保持率，为什么它很重要，以及一些关于如何提高客户保持率的技巧，您可以开始使用 Moesif 跟踪客户保持率指标。还没有使用 Moesif 吗？立即注册开始行动，在几分钟内开始跟踪和提高客户保持率和客户忠诚度。无论您是使用我们的保留分析来跟踪您的客户保留率，还是使用行为电子邮件或其他功能来帮助提高客户保留率，Moesif 都可以帮助您提高客户成功和保留率。让 Moesif 帮助您建立一个有效的客户保留策略，因为保留一个忠诚的客户是增加收入和增加客户终身价值的最有效的方法。

原文：https://www.moesif.com/blog/technical/cpu-arch/What-Is-The-Actual-Vulnerability-Behind-Meltdown/

Meltdown 无疑席卷了互联网。攻击看起来非常简单和优雅，然而白皮书遗漏了特定漏洞的关键细节。它主要依赖于缓存计时旁路和访问全局映射内核页面的推测性执行的组合。

这种深入探讨假设您对 CPU 架构和操作系统内核行为有所了解。首先阅读背景章节了解分页和内存保护的基础知识。

1. 推测性内存读取内核映射(管理程序)页面，然后对值执行计算。
2. 基于计算结果，有条件地从存储器向某个其他非缓存位置发出加载。
3. 虽然当出错异常退出时，第二次加载将从流水线中被核爆，但是它已经向 L2 发出了加载请求，并且除了确保未完成的存储器请求仍然像预取一样将线带入高速缓存层次结构之外。
4. 最后，一个单独的进程可以向这些相同的内存位置发出加载，并测量这些加载的时间。高速缓存命中将比高速缓存未命中快得多，高速缓存未命中可用于表示二进制 1(即命中)和二进制 0(即未命中)。

第 1 和第 2 部分。与指令的推测性执行有关，而第 3 部分和第 4 部分使微体系结构状态(即在高速缓存中或不在高速缓存中)能够提交给体系结构状态。

Meltdown 白皮书中没有规定的是，什么样的特定 x86 指令序列或 CPU 状态可以支持推测性地执行内存访问，并允许向量或整数单元消耗该值。或 L2 元。在现代英特尔 CPU 中，当发生错误(如页面错误)时，管道不会被挤压/核化，直到违规指令退役。然而，在加载甚至在 L1D$中查找或转到内存之前，在所谓的地址生成(AGU)阶段和 TLB 查找阶段完成了对页面保护、分段限制和规范检查的内存权限检查。以下是更多相关信息。

执行内存权限检查

英特尔 CPU 执行物理标记的 L1D需要将线性(虚拟)地址转换为物理地址，然后 L1D$才能通过标记匹配来确定它在缓存中是命中还是未命中。这意味着 CPU 将尝试在(翻译后备缓冲区)TLB 缓存中查找翻译。TLB 将这些转换与页表或页目录许可一起缓存(访问页所需的特权也与物理地址转换一起存储在页表中)。

TLB 条目可能包含以下内容:

• 有效的
• 物理地址减去页面偏移量。
• 读/写
• 用户/主管
• 进入
• 肮脏的
• Memtype

因此，即使推测加载已经知道访问该页所需的权限，也要与当前特权级别(CPL)和所需的 op 特权进行比较，因此可以阻止任何算术单元消耗推测加载。

此类权限检查包括:

• 分段限制检查
• 写入故障
• 用户/主管故障
• 页面不存在故障

这就是许多 x86 CPUs 实际上被设计用来做的事情。当 op 失效时，负载将被拒绝，直到故障被软件/uCode 处理。负载将在去往整数/向量单元的途中被清零。换句话说，用户/管理员保护故障类似于页面不存在故障或其他页面翻译问题，这意味着从 L1D$中读出的行应该立即丢弃，并且微操作简单地进入等待状态。

防止整数/浮点单元消耗故障负载不仅有利于防止这种泄漏，而且实际上可以提高性能。即，如果 L2，则故障加载不会用坏数据训练预取器、分配缓冲区来跟踪内存排序或分配填充缓冲区来从其获取数据。这些是现代 CPU 中有限的资源，不应该被那些不太好的负载消耗掉。

事实上，如果加载错过了 TLB，必须执行页面遍历，如果在遍历期间发生故障，一些英特尔 CPU 甚至会终止 PMH 中的页面遍历(页面错过处理程序)。页面遍历执行了大量的指针追踪，并且必须消耗宝贵的加载周期，所以如果它在以后被丢弃的话，取消它是有意义的。此外，PMH 有限状态机通常只能同时处理几个页面遍历。

换句话说，从性能角度来看，中止 L1D Load uOp 实际上是一件好事。媒体文章称英特尔下滑是因为他们试图以较低的安全性为代价获取尽可能多的性能，这是不真实的，除非他们想声称推测和缓存的基本概念被认为是折衷。

狐狸

虽然这并不意味着熔毁漏洞不存在。这个故事不仅仅是白皮书和大多数新闻帖子所讨论的。大多数帖子声称，只有投机性内存访问和高速缓存计时攻击的行为才能造成攻击，现在英特尔必须彻底重新设计其 CPU 或消除投机性执行。

Meltdown 更像是一个逃过英特尔 CPU 验证的逻辑错误，而不是像媒体目前所说的“现代 CPU 架构的根本崩溃”。它可能可以通过硬件中的一些门变化来修复。

事实上，错误修复可能是一些门的改变，在 L1D缓存命中之前，必须完成地址生成和 TLB 查找阶段。

导致漏洞的所有场景都是未知的。是某些 CPU 设计错过了对这种架构行为的验证吗？是绕过这些检查的特殊 x86 指令序列，还是设置 CPU 状态以确保实际执行加载的一些附加步骤？Project Zero 认为，只有在 L1D$中出现故障负载时，攻击才会发生。也许英特尔在未命中路径上有逻辑，但在命中路径上有逻辑错误？如果某些英特尔 OoO 设计对崩溃免疫，我不会感到惊讶，因为这是一个特定的 CPU 设计和验证问题，而不是一般的 CPU 架构问题。

不幸的是，x86 在内存执行单元中有许多不同的流程。例如，某些指令(如 MOVNTDQA)在 L1D$中的内存顺序和流程与标准的可缓存加载不同。Haswell 事务同步扩展和锁增加了验证正确性的复杂性。指令提取通过与 D 端加载不同的路径进行。验证状态空间非常大。算上所有的旁路网络，你就能看到有多少不同的地方需要验证故障检查。

有一点是肯定的，缓存和投机不会很快消失。如果是逻辑上的 bug，对于未来的英特尔 CPU 来说可能是一个简单的修复。

假设有一条指令即使在有错误的情况下也能使加载命中并消耗，或者我在上面的 catch 中是错的，为什么它现在才发生而不是几十年前才被发现。

1. 今天的 CPU 有更深的管道咳普雷斯科特咳这在推测性内存访问和那些出错访问的实际核/挤压之间提供了更宽的窗口。出错指令不被处理，直到该指令退出/提交给处理器架构状态。只有在退役时，管道才会被拆除。长流水线允许在出错指令的执行和它的退出之间有一个大的窗口，允许其他推测性指令跑在前面。
2. 与高速缓存命中/整数运算等仅针对 CPU 的快速运算相比，高速缓存层次结构更大，内存结构速度更慢，这在高速缓存命中和高速缓存未命中/内存之间提供了更大的周期时间差，从而支持更强大的高速缓存计时攻击。今天的大型多核服务器 CPU 使用精心制作的网状结构来连接数十或数百个内核，这一点被夸大了。
3. x86 CLFLUSH 和 PREFETx 等细粒度缓存控制的性能增强特性为缓存计时攻击提供了更多控制。
4. 更广泛的处理器，可同时支持并行整数、浮点和内存操作。人们可以将长浮点操作(如 divide 或 sqrt)放在出错指令之前，以保持内核忙碌，但仍然保持整数和内存管道不受攻击。由于出错的指令在退役之前不会核化流水线，所以它必须等到指令序列中任何更早的指令被提交，包括长时间运行的浮点运算。
5. 虚拟化和 PaaS。许多网络规模的公司现在都在运行工作负载云提供商，如 AWS 和 Azure。在云计算出现之前，财富 500 强公司会在自己的硬件上运行自己的可信应用。因此，不同公司的应用程序在物理上是分离的，这与今天不同。虽然 Meltdown 是否允许来宾操作系统侵入虚拟机管理程序或主机操作系统尚不清楚，但已知的是许多虚拟化技术比成熟的 VT-x 更轻量级。例如，Heroku、AWS Beanstalk 或 Azure Web 应用程序中的多个应用程序以及 Docker 容器都在同一个虚拟机中运行。公司不再为每个应用程序配置单独的虚拟机。这可能允许恶意应用程序读取特定虚拟机的内核内存。在 90 年代，随着 Pentium Pro/Pentium III 的出现，OoO 执行成为主流，共享资源不再是一个问题。
6. 在 x86 分页条目中使用全局位和用户/管理员位，这使得内核内存空间能够映射到每个用户进程(但受到保护，不会执行 Ring3 代码),从而降低 TLB 的压力，并减缓上下文切换到独立内核进程的速度。这种性能优化从 20 世纪 90 年代就开始了

首先，缓存计时攻击和推测性执行并不是英特尔或 x86 CPUs 所特有的。大多数现代 CPU 在你的手表或微波炉的几个嵌入式微处理器之外实现多级缓存和大量的推测。

这不是英特尔或 x86 的特定问题，而是一般 CPU 架构的基本问题。现在有人声称，特定的 OoO ARM CPUs，如 iPhones 和智能手机中的 CPU，也存在这一缺陷。乱序执行自从被 Tomasulo 算法引入以来已经完成。与此同时，缓存计时攻击几十年来一直为人所知，因为众所周知，数据可能会在不应该的时候被加载到缓存中。然而，缓存计时攻击传统上被用来寻找内核内存的位置，而不是实际读取它的能力。这更像是一种竞争条件和窗口，具体取决于微体系结构。一些 CPU 的管道比其他 CPU 浅，导致核爆发生得更快。像 x86 这样的现代桌面/服务器 CPU 具有从 CLFLUSH 到 PREFETCHTx 的更精细的功能，这些功能可以作为附加工具来使连接更加健壮。

自从在 386 和 Windows 3.0 中引入分页以来，操作系统就一直使用这一功能来将一个进程的内存空间与另一个进程的内存空间隔离开来。一个进程将被映射到它自己独立的虚拟地址空间，该空间独立于另一个正在运行的进程的地址空间。这些虚拟地址空间由物理内存支持(页面可以换出到磁盘，但这超出了本文的范围)。

例如，假设进程 1 需要 4KB 内存，因此操作系统分配了 4KB 的虚拟内存空间，其字节可寻址范围从 0x0 到 0xFFF。该范围由从位置 0x1000 开始的物理内存支持。这意味着进程 1 的被“安装”在物理位置。如果有另一个进程正在运行，它也需要 4KB，因此操作系统将为这个进程 2 映射第二个虚拟地址空间，范围为 0x0 到 0xFFF。这个虚拟内存空间也需要物理内存的支持。由于进程 1 已经在使用 0x1000-0x1FFF，操作系统将决定为进程 2 分配下一块物理内存[0x2000-0x2FFF]。

在这种设置下，如果进程 1 从内存向线性地址 0x0 发出加载请求，操作系统会将其转换为物理位置 0x1000。而如果进程 2 从内存向线性地址 0x0 发出加载，操作系统会将其转换为物理位置 0x2000。注意这里需要一个翻译。这是页表的工作。

网络世界中的一个类比是，在一台主机上运行的两个不同的 Docker 容器如何将容器内的同一个 dir 挂载到主机上的两个不同的物理位置和。

一系列映射内存被称为一个页面。CPU 架构有一个定义的页面大小，如 4KB。分页允许内存在物理内存空间中分段。在上面的例子中，我们假设页面大小为 4KB，因此每个进程只映射一个页面。现在，让我们假设进程 1 执行一个 malloc()并强制内核映射第二个 4KB 的区域。由于物理内存的下一页[0x2000-0x2FFF]已经被进程 2 使用，操作系统需要分配一个空闲的物理内存块[0x3000-0x3FFF]给进程 1 (注意:现代操作系统使用延迟/惰性内存分配，这意味着虚拟内存可以在被任何物理内存支持之前被创建，直到页面被实际访问，但这超出了本文的范围。请参阅 x86 页面访问/脏位了解详情)。

地址空间看起来与进程相邻，但实际上是跨物理内存空间的碎片:

流程 1

流程 2

在此之前还有一个额外的转换步骤，使用 x86 分段将逻辑地址转换为线性地址。然而，今天大多数操作系统不使用传统意义上的分段，所以我们现在忽略它。

除了创建虚拟地址空间，分页也是一种保护形式。上述翻译存储在一个名为页表的结构中。每个 4KB 页面可以有特定的属性和访问权限，与翻译数据本身一起存储。例如，可以将页面定义为只读。如果对内存的只读页面执行内存存储，则 CPU 会触发一个故障。

直接来自 x86 参考手册，下面的非穷举属性位列表(其行为类似于布尔真/假)与每个页表条目一起存储:

最小化上下文切换成本

我们展示了每个进程如何拥有自己的虚拟地址映射。内核进程和其他进程一样，也有一个虚拟内存映射。

当 CPU 将上下文从一个进程切换到另一个进程时，切换成本很高，因为许多体系结构状态需要保存到内存中，以便挂起的旧进程在再次开始执行时可以使用保存的状态继续执行。

然而，许多系统调用需要由内核来执行，如 I/O、中断等。这意味着 CPU 会不断地在用户进程和内核进程之间切换，以处理这些系统调用。

为了最小化这个成本，内核工程师和计算机架构师将内核页面映射到用户虚拟内存空间中，以避免上下文切换。这是通过用户/管理员访问权限位完成的。操作系统映射内核空间，但只将其指定为管理员(也称为 Ring0)访问，因此任何用户代码都不能访问这些页面。因此，这些页面对于任何在用户权限级别运行的代码来说都是不可见的

在用户模式下运行时，如果 CPU 发现指令访问需要管理员权限的页面，则触发页面错误。在 x86 中，页面访问权限是能够触发 #PF(页面错误)的分页相关原因之一。

全球位

我们展示了每个进程如何拥有自己的虚拟地址映射。内核进程和其他进程一样，也有一个虚拟内存映射。大多数翻译都是进程私有的。这确保了进程 1 不能访问进程 2 的数据，因为不会有从进程 1 到【0x2000-0x2FFF】物理内存的任何映射。然而，许多系统调用由许多进程共享，以处理发出 I/O 调用、中断等的进程。

通常，这意味着每个进程将复制内核映射，这给缓存这些翻译带来了压力，并增加了进程间上下文切换的成本。全局位使这些特定的转换(即内核内存空间)在所有进程中可见。

探究安全问题总是很有趣的。与 20 世纪 90 年代不同，现在的系统被认为是安全的，并且随着加密、生物识别验证、移动支付和数字医疗的发展，系统变得更加重要。对于今天的消费者和企业来说，大臀位比 90 年代更可怕。同时，我们也需要继续讨论新的报告。

引发熔毁漏洞的步骤已被各方证明。然而，导致崩溃的可能不仅仅是投机和缓存计时攻击的行为，也不是 CPU 架构的根本故障，而是一个逃过验证的逻辑错误。这意味着，猜测和缓存不会很快消失，英特尔也不会需要一个全新的架构来修复崩溃。相反，未来 x86 CPUs 中唯一需要的变化是对组合逻辑进行一些小的门更改，这些更改会影响确定 L1D$(或任何临时缓冲区)中的命中是否是好的。

原文：https://www.moesif.com/blog/api-engineering/api-observability/What-is-the-Difference-Between-API-Observability-vs-API-Monitoring/

API 监控的传统定义在 SmartBear、APIMetrics 和 Runscope 等公司已经存在多年，对于检查 API 的正确性和性能非常有用。API 监控工具针对您选择的端点启动 API 调用，然后记录收到的响应。可以添加额外的检查，例如在 500 错误或超时时创建松弛警报。测试可以在触发时启动(例如当您的 CI/CD 管道部署了新版本时)，也可以按循环时间表启动(例如每 1 分钟)。API 监控测试可以是简单的，比如简单的健康和正常运行时间检查，也可以是非常复杂的，通过一长串 API 调用运行，并检查特定的状态代码、主体字段等等。

虽然 API 监控使您能够检查正常运行时间，并在 API 超时或响应 500 个错误时采取措施，但它也有局限性，因为它是一种黑盒形式的监控，具有提前创建的断言检查。测试或探测已经提前知道，这意味着 API 监控无法回答关于你的 API 如何运行的任意问题。相反，API 监控只能检查它生成的流量，而不是实际的客户 API 流量。随着越来越多的 API 暴露在互联网上，有了新的需求来探索和发现未知的未知，以防止 API 威胁，解决客户问题，并了解 API 的使用。这些需求导致了 API 可观察性的出现。

与黑盒测试和监控不同，API 可观察性是一种形式的白盒监控，需要代理或 SDK 被动地将 API 流量记录到可观察性服务中。这种数据收集可以在应用程序中完成，也可以添加一个不同的点，例如使用像 Kong 或 NGINX 这样的 API 网关。

监控客户体验

API 可观察性可以跟踪用户或客户与您的 API 的每一次交互，这使您能够描绘不同的端到端流，并了解热点可能存在于何处。大多数提供 API 的团队不能完全控制他们的消费者如何使用 API。这些消费者可能来自一个大型组织的另一个部门或产品，也可能来自不同的公司。作为开发人员，我们喜欢假设客户会以特定的方式使用我们的产品，但是 API 集成工作可能会很混乱或者充满错误。例如，您的 API 消费者可能会忽略您关于分页和过滤的建议，从而导致过多的数据被轮询。API 可观察性的目标是主动发现这些未知的未知，并补救它们，无论是您自己的代码还是 API 消费者的代码有问题。

API 问题疑难解答

因为 API 可观察性工具记录了 API 上发生的所有事情，所以您能够探索未知的未知情况，例如客户可能遇到的您以前从未见过的问题。您不需要提前创建一个测试来观察发生了什么。会出现各种各样的 API 问题，有些问题比较容易调查，比如缺少 API 键或 HTTP 头，但其他问题可能要复杂得多，需要跟踪 API 调用的历史和它们的计时。

检测并防范 API 威胁

一个设计良好的 API 可观察性平台不仅可以跟踪 API 上发生的事情，还可以跟踪谁在发出 API 请求，从而实现复杂的用户行为分析(UBA)以及用户和实体行为分析(UEBA)。通过跟踪复杂的用户流，您可以识别可能抓取您的 API 或访问未授权数据的可疑用户。

不像 web 应用程序可以结合像 Capctha 和浏览器指纹这样的技术，API 公开了对数据的原始访问。一些 API 甚至可能让客户以编程方式访问，这使得区分真正的 API 调用和恶意的 API 调用变得极其困难。这使得传统的基于规则的 Web 应用防火墙(WAF)如 ModSecurity 对 API 无用。相反，采用以用户为中心的方法的现代 API 可观测性解决方案可以使用高级异常检测来检测未知的未知。

了解客户 API 的使用

组织构建 API 是为了给 API 的客户或用户创造有价值的东西，而不仅仅是为了构建东西。与 API 安全性一样，这需要一种机制来将 API 调用归因于个人客户及其收入，并且是 API 的用户行为分析(UBA)的另一个用例。寻找 API 分析的常见团队包括产品组织，但也包括跟踪试点使用、试验和扩展机会的销售和增长团队。直到 2015 年，Twilio 的估值才达到 5 亿美元。据 Akamai 称，现在它是一家价值 300 亿美元的公司，所有 HTTP 流量的 83%来自 API 调用。API 不再仅仅是一种“后端技术”，而是一种关键的业务驱动力。

然而，API 调用只讲述了故事的一半(参与)，一个好的 API 可观察性工具还提供了存储客户人口统计和收入(用于货币化和细分)的能力，以及跟踪 API 外部发生的事情，如注册和计划购买。

API 指标

API 指标使您能够监控工程和业务 KPI，例如性能和客户使用情况。一些指标跟踪工具只能监控单值指标，如每分钟请求数。然而，可观察性的一个关键主题是能够回答任何关于您的 API 和服务的问题，而无需提前计划哪些指标需要进行监控。在这种情况下，高基数、高维度的指标和数据存储可以方便地探索和回答未知的未知问题，并能够立即切片和切片。

API 日志

像 API 度量一样，API 可观察性平台也能够实时检查 API 调用，以便进行调试和审计。API 日志向您显示即时的准确调用。因为根据定义，API 的结构不同于传统的日志记录，所以 API 日志还可以用于生成聚合和指标，同时维护上下文。然而，API 调用可以有大量的 HTTP 头、主体键和属性。这意味着您的 API 可观察性工具应该能够通过它们进行过滤和聚合，而不需要依赖于对数据存储的全面扫描(这可能需要很长时间)。

GDPR 和 CCPA 要求对 API 日志之类的东西采用新的程序，这些程序在整个公司从安全团队到业务团队都在使用。您不能再简单地将 API 日志转储到日志管理解决方案中。相反，API 企业需要一种方法来导出和删除(或匿名化)特定于单个客户的所有相关日志和事件。这意味着 API 日志必须绑定到某个永久的用户标识符上(而不仅仅是轮换的 API 键)。

API 分析

API 可观察性的第三个支柱是 API 分析。与侧重于回答工程特定问题的 API 度量和日志不同，API 分析侧重于回答产品和业务相关的问题。简单地说，API 分析是 API 指标与关于客户是谁以及他们如何使用您的 API 的数据的融合。很多时候，API 分析工具可以从 CRM 或营销自动化工具等其他系统中提取数据，以便您能够绘制出客户旅程。API 分析可以包括漏斗指标，如有多少人激活和使用您的 API，以了解哪些端点产生的收入或增长最多。

API 跟踪

由于本质上是事务性的，API 包含关于何时发起请求、服务需要多长时间响应等时间的计时信息。不同的计时会产生难以重现的竞争条件和错误。API 跟踪可以很容易地理解不同的服务需要多长时间来响应，以及哪里会出现计时错误。跟踪使您能够进一步探索特定会话或相关 API 调用集要查看的日志。

任何希望快速自信地发布 API 的人都应该寻找一个 API 可观察性系统。API 为您公司基础设施的其余部分提供了窗口，并实现了全新的数字体验，但传统的监控只能回答已知的问题，如“我的 API 是否停机了”，而不能回答数据驱动的工程和业务团队所需的任意问题，也不能报告安全性和产品分析所需的实际客户 API 使用情况。

原文：https://www.moesif.com/blog/business/compliance/What-Is-the-Difference-Between-Data-Compliance-and-Data-Privacy/

在部署任何保存客户或用户数据的应用程序时，数据合规性和数据隐私都是需要考虑的重要方面。然而，数据管理的这两个领域有时会被误解。这篇博文将阐明数据合规性和数据隐私之间的区别。

数据合规性是指在数据的收集、处理和存储方面满足特定法律义务的要求。

例如，在欧洲拥有客户的公司必须遵守通用数据保护条例(GDPR) 。这是一个法律框架，让消费者有权查看公司掌握的关于他们的数据，反对公司对这些数据的处理，并要求公司删除这些数据。同样，在加州拥有客户的公司必须遵守加州消费者隐私法案(CCPA) 。

除了 GDPR/CCPA，其他合规框架的例子还包括健康保险流通与责任法案(HIPAA)、SOC 2 审计框架(T0)和 ISO/IEC 27001 标准(T3)。这可能包括公司为确保数据合规性而建立的一套政策、程序和审计。

数据隐私涉及保持敏感数据的私密性和机密性。在数据合规性是数据管理的法律方面的情况下，保持数据私密性是一个实际/技术问题。隐私计划的目标是倡导数据隐私，并确保只有授权用户才能在需要知道的基础上查看数据。它包含了典型合规计划之外的元素。

数据隐私通常适用于任何个人身份信息(PII)，即任何可用于识别某人的数据。社会安全号码、电子邮件地址、IP 地址等等都可以被认为是 PII。努力保护数据隐私的公司需要采取措施来保护这些数据的机密性，即使这不是合规性所要求的，因此倡导保护与数据相关的个人的隐私。数据隐私确保机制到位，以确保只有获得授权的人才能访问数据。

关于数据合规性和数据隐私的一个误解是，公司不能用任何第三方工具存储其数据，因此必须求助于“内部”解决方案。事实并非如此。第三方工具可能具有强大的访问控制和安全性，并在 SOC 2 和 ISO/IEC 27001 等第三方框架下经过严格审核。然而,“内部”数据存储可能允许许多员工通过一个通用的根密码进行访问，而没有任何健壮的审计日志记录，这可能远远不符合标准。

相反，工程师必须评估工具(无论是内部的还是外部的)，以确保有正确的机制来满足安全性和数据合规性标准。如果公司不像对待外部工具那样对内部工具应用严格的安全措施，数据泄露的可能性就会增加。

GDPR、SOC 2 和其他框架是法律和操作框架。虽然这些框架对工程设计有很大影响，但它们会影响公司从法律、销售到支持的整个运营。如果一家公司需要与另一家公司合作，法律文书工作将为他们这样做铺平道路。在 AWS 中设置一个“安全”的环境并不意味着你符合 SOC 2。将您的数据存储在“内部”数据库中并不意味着您符合 GDPR，因为支持和销售等团队需要一些操作程序。

为了遵守 GDPR 法案，两家公司可能会签署一份通常称为“数据处理附录”的法律文件，该文件定义了不同方之间如何处理和保护数据。它将定义谁是数据控制者，谁是数据处理者，如何处理数据，服务级别协议和违规期间的程序，等等。该协议应涵盖可归类为 PII 的所有数据，并确保其符合相关合规立法的要求。

以 GDPR 为例，这意味着需要有一个适当的流程来满足个人访问、反对和要求删除其数据(无论数据存储在何处)的要求。

仅仅因为您遵守 GDPR 或 SOC 2，并不一定意味着数据是私有的，无论数据是存储在第三方工具中还是您的内部解决方案中。数据隐私是一种“超越”合规框架的艺术，尽一切努力确保客户数据的隐私。

有几种不同的方法来确保数据隐私。例如，Moesif 平台有一个名为隐私规则的特性，它使您能够使用基于角色的访问控制(RBAC)在需要知道的基础上限制对某些字段的访问。例如，您可以创建一个隐私规则，确保技术支持人员不能查看或检查敏感的 HTTP 头或 PHI(受保护的健康信息)。然而，出于报告目的，分析师可能需要额外的访问字段。这超出了合规性通常要求的范围，以真正确保数据尽可能保密。

保持数据隐私的第二种方法是通过客户端加密，这是降低数据泄露风险和改善数据隐私状况的最新趋势。客户端加密使您能够使用一组轮换加密密钥来加密数据，只有极少数员工能够访问这些密钥。维护底层数据基础设施和处理管道，但没有查看实际数据的业务需求的工程师，只要他们没有访问加密密钥的权限，就无法查看实际数据。

这也是 Moesif 平台的一个功能，它确保只有贵公司一小部分授权团队成员可以检查敏感数据。Moesif 员工将无法检查数据，因为他们无法访问客户管理的加密密钥

数据合规性和数据隐私是重要而严肃的话题，会影响组织中接触敏感数据或客户数据的任何人。法律、运营和工程部门应通力合作，确保法规遵从性。此外，除了合规性框架的要求之外，公司还应努力实现更高的数据隐私。这可以是为了数据道德，也可以是为了减少数据泄露事件的风险。理解两者之间的区别是减轻整个主题压力的第一步——希望这篇文章能帮助你做到这一点！

如果您想了解更多信息，为什么不阅读 Moesif 如何简化 GDPR 合规性并确保数据保密？您还可以与我们乐于助人的团队聊天，他们将很乐意回答您所有的数据合规性和数据隐私问题。

原文：https://www.moesif.com/blog/technical/api-product-management/What-is-TTFHW/

TTFHW 不是你在技术和产品领域听到的最常见的缩写。尽管它并不常见，但可以说它是公司试图挖掘并向新用户提供价值的最重要的缩写之一。

TTFHW，或第一次你好世界的时间，可能是你已经想到的事情。许多产品导向的爱好者称之为顾客的“啊哈！”瞬间。这是客户第一次从你的平台获得价值的时候。许多编程语言和程序员工具称之为“Hello World”时刻。这是一个成败的里程碑，也是一个你显然希望每个客户都经历的里程碑。TTFHW 简单来说就是到达“啊哈！”瞬间。

“第一次你好世界的时间”这个术语来源于很多软件开发人员都知道的事情:第一次运行一个用新语言构建的程序(以及到达那里所需要的时间)。许多语言都有 Hello World 指南，许多开发人员通过将“Hello World”打印到控制台或屏幕上，用一种新的语言创建了他们的第一个程序。

没有这些时刻，编程语言和框架就不会给我们带来价值。一个 Hello World 程序往往是一个小而简单的程序，开发者用特定的编码语言编写。这个程序通常为他们将要编码的后续程序构成构件。

当把这个应用到产品上时，“你好，世界”或“啊哈！”时刻可能看起来有点不同。可能很简单，比如一个用户第一次调用一个 API，收到一个响应。一旦他们达到 Hello World 里程碑，他们就会继续玩和使用这个产品。最理想的结果是，他们有望成为付费客户。

在更复杂的流程中，Hello World 事件可能有多个步骤。例如，如果我们正在运行一个电子商务平台，我们的 Hello World moment 可能只有在用户注册、登录并成功完成第一次购买后才会发生。当然，其他应用和产品可能有无限复杂的 Hello World 时刻。

你的产品的 Hello World moment 只能由你来定义。这是因为每个产品都是不同的。只有你能决定用户从你的平台或产品获得价值的第一瞬间。有几种方法可以描绘出你的 Hello World 时刻，我再举几个例子:

• 如果你已经创建了一种新的编程语言，这可能是用户编译他们的代码并运行他们的第一个程序的时候。
• 如果您已经创建了一个投资应用程序，这可能是用户第一次将资金存入帐户并进行第一笔交易的时刻。
• 如果你已经创建了一个 API 平台(特别是货币化的)，这可能是用户第一次调用 API 的时候，这时就要收费了。

你的应用程序很可能不属于这些类别，或者它确实属于。无论如何，您可能需要真正深入了解您认为的 Hello World 事件(或多个事件)。

如果你有一个多步骤的 Hello World，跟踪每一步是很重要的，因为你可以识别流程中的瓶颈。例如，如果您有一个 3 步流程，而第 1 步花费了用户 90%的时间来完成，这很可能也是您失去许多用户的地方。通过定义所有 3 个步骤，而不仅仅是最后一个，它给了我们一个真实的画面，我们的问题在哪里，哪里需要优化。

为你的产品定义 Hello world moment 只是 TTFHW 等式的一小部分。最大的因素是到达那个点实际需要的时间。就需要多长时间而言，没有“一刀切”，但根据新产品的趋势和现代人对入职的态度，应该会很快。

顾客或用户到达 Hello World 时刻的时间越长，他们离开并完全放弃产品的可能性就越大。这意味着创造一个精益流程来实现第一个 Hello World 时刻至关重要。特别是对于多步骤流程，每个输入和点击都应该仔细管理。在“你好，世界时刻”到来之后能做的任何事情都应该推迟到那时。

通过跟踪第一个 Hello world 的时间，您可以开始收集关于哪些部分花费时间最长以及大多数用户在哪里下车的真实指标。您将能够看到趋势和阈值，例如当用户“花费超过 X 分钟来完成 Hello World 标准时，他们通常会放弃该产品”。这意味着您可以改进流程和跟踪，看看这些改进是否产生了影响。

除了简单地改进产品之外，还有第二种补救方法。这种方法可能包括当客户超过 TTFHW 的估计阈值时通知您的客户成功团队。更好的是，你可以在应用程序中通知他们进一步的资源，或者给他们发一封自动邮件，告诉他们如何更接近 Hello World 时刻。

降低你的 TTFHW 很重要，因为这能让顾客进门，让他们兴奋地使用产品。尽可能缩短用户获得价值的时间，这对用户和你的产品都是双赢的。当测量 TTFHW 时，优化用户体验是最容易衡量的。

由于 Moesif 能够以高粒度跟踪用户指标，这使得它成为一个定义、跟踪和改进你的产品的伟大平台。

默认情况下，Moesif 在用户的配置文件中为 TTFHW 创建一个变量。这个高层次的 TTFHW 被计算为用户第一次被添加到 Moesif 时和他们第一次执行 API 调用时之间的差异。对于某些场景，这可能是准确确定产品 TTFHW 所需的所有复杂性。

对于更复杂的流程，我们的用户转向用户漏斗来创建多步漏斗，它跟踪 Hello World 旅程的每一步，并记录每一步之间花费的时间。正如您在上文中回忆的那样，这意味着我们可以确定哪些步骤在整个流程中花费的时间最长，而不是只关注单个事件。有了 Moesif，可以向用户漏斗添加无限数量的步骤。以下是 Moesif 中用户漏斗的一个示例:

这个用户漏斗反映了一个场景，其中有 3 个步骤来完成漏斗。第一步是用户注册时，第二步是用户第一次购买/支付时，最后一步是用户完成第 100 次购买/支付时。您还会注意到，您可以看到每个步骤的转换率以及每个步骤的转换时间。

一个额外的好处是，如果你的应用程序支持不同的配置文件和用户类型，一些产品可能会根据用户类型有不同的 Hello World 时刻。为此，可以为每个场景建立一个用户漏斗，以便准确地跟踪每个流量。

使用 Moesif 来确定您的产品 TTFHW 并改进它很简单。Moesif 很容易与许多平台集成，包括最常见的 API 框架和 API 网关。一旦整合，您的指标可以很容易地用于确定上述所有因素。

从高层次开始，你可以很容易地定义你的用户漏斗中的一些关键步骤。从商业角度来看，进入第一个 Hello World 的结果是以后为用户带来实现的价值。下面是一个漏斗的例子，它跟踪用户对页面的初次访问，直到他们(和企业)获得实现的价值。您可以看到漏斗中每个步骤之间的平均时间以及每个步骤的转化率。

在 Moesif 中跟踪这些事件时，重要的是要记住 Moesid 可以在前端和后端跟踪事件。我们所说的“Web 动作”被认为是前端事件。“API/平台动作”是发生在应用后端的那些事件。您可能希望使用一种或两种类型的操作来定义您的用户漏斗。下面是一个示例，说明如何根据前面的示例拆分这些事件。

不管到达第一个“你好世界”或“啊哈！”有多复杂时刻，跟踪每一步都是吸引客户，留住客户的重要一环。TTFHW 是计算交付该价值需要多长时间。普遍的共识是 TTFHW 越快，你获得新客户的机会就越大。这是因为价值是提前交付的，确保更多的客户到达那个时刻，而不是放弃你的产品。

想走上快车道吗？只需注册 Moesif 并查看我们的指南，了解如何在几分钟内建立用户渠道来跟踪你的 TTFHW。

原文：https://www.moesif.com/blog/api-monetization/api-strategy/What-You-Need-to-Know-When-Pricing-APIs/

为 API 正确定价是 API 货币化策略的关键部分。这意味着了解您应该如何对使用收费，是按月还是按季度定价更好，是数据层还是按使用量付费的 API 定价模式效果最好，以及一系列其他因素。在本帖中，我们将涵盖 API 定价时你需要知道的所有内容。

谁为 API 买单？

在最基本的层面上，询问谁真正为 API 付费是很重要的。当你将你的 API 货币化时，你是通过向最终用户——利用你的 API 提供商业价值的公司——收费来实现的。因此，通过了解您的 API 提供的价值，您将能够更好地建立一个有利的定价策略。

当把你的 API 当作一个产品时，一个基本原则是理解你的客户。通过了解他们如何使用你的产品，你不仅可以更好地为你的服务定价，还可以让你对什么可行、什么不可行以及你的路线图上应该有什么有不可或缺的见解。关于将 API 视为产品的更多信息请查看我们丰富的库。

你如何计算 API 价格？

有几种方法可以确定 API 的价值。根据 API 调用的数量收费是一种常见的定价标准，但当涉及到您的定价模型时，这肯定不是唯一的选择。在制定 API 策略时，要考虑不同的基于使用的计费方法，包括:

• 交易量——基于 API 调用的数量。它非常适合 API 和基于事件的平台，例如在 communications Twilio 或 analytics[moes if]https://www . moes if . com/price？UTM _ campaign = Int-site&UTM _ source = blog&UTM _ medium = body-CTA&UTM _ content = pricing-your-APIs){:target = " _ blank " }。
• 收入/成本份额–您向最终用户收取一定比例的收入或交易费用。这非常适合金融平台，比如那些专注于支付条纹或费用报告的平台。
• 数据量–基于发送的千兆字节或处理的分钟数。对于专注于数据的平台来说，这是一个很好的方法，比如日志或存储 AWS 。
• 以用户为中心–基于每月活跃独立用户数量定价。这是现代版的按用户或座位收费。资源–基于计算单位或活动时间。非常适合数据库或虚拟机等计算基础架构。

你提供的产品将在你的定价策略中发挥关键作用。从 SaaS 价格点方法中可以学到很多东西，因为许多 API 定价策略都植根于更广泛的 SaaS 定价解决方案。SaaS 定价的主导思想强调需要根据三个主要因素来定价:交付产品的成本、竞争对手的定价和你的价值指标。也就是说，你的客户将如何支付。从你的第一批付费客户那里获得反馈也很关键，因为他们会有很多关于哪些定价模式适合他们，哪些不适合他们的想法。

内部与外部 API

面向外部的 API 通常是收费的，这些 API 可供组织外的其他公司使用。内部 API，您可以用来在您的组织内互连不同的服务，通常不收费，因此不需要定价策略。

现收现付计费模式意味着客户只为他们消费的东西付费。这可以通过一系列指标来衡量，比如发送的消息数量。这种基于消费的定价模型非常适合 API，API 自然是基于事务的。

使用随用随付 API 计费，您可以根据客户的使用情况选择收费标准。你也可以实现批量折扣，这取决于你如何将你的 API 货币化。

随用随付模式易于实现，这使得它成为许多公司设计其第一个 API 货币化策略的流行选择。一个示例云架构说明了这种实现的简单性。

从客户的角度来看，实施现收现付计费成本较低。然而，从长远来看，如果不限制使用量，对他们来说成本会更高。你还需要实现一个系统，提醒你的用户配额限制，以避免他们收到意外账单。这样一个系统将会对你的信用有所帮助，因为它将会避免意外账单促使你的顾客货比三家寻找更便宜的替代品。

API 调用是如何计算的？

有许多不同的方法来计算你如何为你的 API 收费。这是 Moesif 真正的亮点，因为我们的平台可以基于 API 中的任何参数进行计费。这意味着您可以围绕客户的精确需求来制定您的 API 货币化策略。如果您决定基于使用计费，可能的消耗指标包括 API 调用次数、发送的千兆字节数、用时数、每月活跃用户数、活跃小时数等等。

一个 API 能赚多少？

不考虑定价策略，另一个关键问题是你的 API 能产生多少。API 是 SaaS 的一个子集，一次又一次地被证明能够以超高速扩展。

绘制两个 API 成功典范 Twilio 和 Stripe 的快速崛起的图表很有启发性。两家公司都基于 API 优先的模型——通过 API 提供服务。在 2011 年推出产品后，Stripe 的收入从 2016 年的 4000 万美元增长到 18 个月后的 4.5 亿美元，并在 2020 年增长到 70 亿美元。同样，Twilio 的收入从 2013 年的 5000 万美元增长到了 2021 年的近 4000 万美元。

API 或企业软件含义？

如果您可以选择提供 API 产品或企业软件解决方案，那么这个决定将对您创收的速度产生重大影响。一个策略是专注于向最终用户提供你的 API。这意味着您可以更快地进入市场，并将所有的工程人才集中在 API 提供的业务逻辑上。相反，如果你想构建一个企业软件解决方案，你也需要投资创建一个前端。通过将您的所有资源集中在您的差异化业务功能上，您可以为您的解决方案收取更多费用。

在开发分层定价模型时，由您来决定价格点并相应地包装您的层。采用“免费增值”的定价策略变得越来越普遍，即初始层是免费的，后面的层是付费的。在 Moesif 的案例中，我们有四个层次:免费、增长、专业和企业。

正如我们在最近的一篇文章中讨论分层定价时提到的，在交易和分层产品定价模型之间存在权衡。如果您使用分层方法，您需要定义每层包含哪些功能和使用配额。您还需要解决客户对此模型的主要担忧:

如果我达到了 API 计划的限额，会发生什么？

以 Moesif 为例，每一层都定义了用途、用户数量和功能。如果客户需要更多，他们可以选择升级到下一层，作为其计划增长的一部分。这是一个简单的模型，使客户可以轻松地进行预算和管理，因此当然可以考虑将其作为 API 定价策略的一部分。

什么是高级 API 商业模式？

从 Moesif 模型中可以看出，分层定价的另一个好处是可以引入溢价元素。什么是高级 API 商业模式？在这种情况下，顶层客户可以从任何其他层都无法获得的某些功能中受益。在 Moesif 的情况下，高级扩展包括将 API 使用数据同步到内部仓库、Salesforce 集成、MarTech 工具等的能力。您可以提供的高级 API 元素将基于您独特的业务模型。

API 定价的最后一个要素与你的产品提供的价值有关。问问你自己:这个 API 解决了一个独特的需求吗？如果是这样的话，那么你在定价方面就有了更大的自由，如果你的 API 满足了许多竞争对手的 API 也能满足的需求。

易用性也很重要，所以您还需要考虑 API 的易用性。是 REST API 还是另一种格式？它是基于云的 web API 还是在本地运行的？用户需要一个 API 密匙吗？如果需要，获取它的过程是否顺利？

API 的例子是什么？

本质上，你让客户访问你的 API 越容易，就越好。例如，佛蒙特州立法机构 API 使用 HTTP basic auth 进行认证，用户必须向佛蒙特州立法机构发送电子邮件才能获得 API 密钥。这就带来了摩擦和延迟，因为潜在用户在使用电子邮件之前必须等待回复。记住:客户更愿意为易于使用的 API 付费，而不是让他们头疼的 API。

命名 API 和 API 安全性

最后要考虑的几点是如何正确命名 API，这应该在设计决策中加以考虑，以及如何解决 API 安全性问题。API 安全性需要什么？这本身就是一个巨大的话题。一旦您制定了自己的 API 定价策略，请查看我们的 API 安全特性,以确保您尽全力降低自己和客户的安全风险。

将上述所有因素纳入你的 API 定价策略，意味着你将能够有效地将你的产品货币化。越早考虑货币化越好。

今天就放手一搏吧。尝试我们的货币化解决方案，并把你在这里学到的一切付诸实践。

原文：https://www.moesif.com/blog/developer-platforms/embedded-frameworks/Whats-Next-For-Developer-Platforms-Embedded-Integrations-And-APIs/

这是 Jeremy Glassenberg 在 2020 年 3 月旧金山 API 和 IPA Meetup 上演讲的姊妹篇。他演讲的完整视频在 Moesif 的 YouTube 频道上。

https://www.youtube.com/embed/XhCRkmabQl0

随着流行的 web 服务扩展其开发者平台，让合作伙伴直接集成到它们的界面中，设计趋势正在从嵌入式集成领域的经验中形成。随着 Google Drive 连接 Balsamiq 和 ShiftEdit 等工具，Gmail 在其 web 和移动用户界面中支持 Docusign，以及 Trello 等服务在其自己的界面中提供插件，由第三方提供的定制体验正在证明自己是改进产品和发展业务的一种很好的方式。

让我们看看什么是成功的和不成功的，什么趋势在起作用，以及启动成功的嵌入式集成计划需要哪些 UX 和技术考虑。

对嵌入式集成框架的第一次尝试，让第三方的东西出现在你的界面中，变得有点混乱。早期的解决方案包括 iGoogle、OpenSocial，甚至是一家 YC 公司 youOS，它让网页像操作系统一样运行。

回到 2008 - 2010 年，令人困惑的问题仅仅是用例没有被考虑清楚。消费者不一定想让网络像操作系统一样，或者将第三方的内容整合到他们的社交网络个人资料中。没有市场需求。

雪上加霜的是，iGoogle 和其他平台不仅面向开发者，而且当这些产品失败时，它们在消费者面前也失败了。这对企业来说很不利，所以它们被悄悄地关闭了。平台提供商变得畏首畏尾。

随着 web 服务的增长和用户群的扩大，大公司看到了开发人员拼凑解决方案来构建他们想要的特性和服务。确实有一群人试图在 Gmail 之外增强 Gmail。Trello，Shopify，Wix，twitch 和许多其他公司也是如此。

通过与客户群积极互动，这些公司可以确定他们需要什么，并构建真正的用例。他们看着:

• 他们在实验什么
• 他们是如何开始的
• 他们学到了什么

他们只有在拥有足够多的用户基础时才推出平台，他们可以看到他们的产品中缺少一些东西，用户正在要求，并且他们不想自己构建和维护。

成功的嵌入式框架确实遵循市场模型。因为已经有了一个庞大的用户群，所以最重要的是留住客户，而不是采用客户或客户增长。

实际上，将开发人员平台实现为嵌入式框架有很多选择。突出前三名:

iFrames

让另一个网站嵌入您的网站。被许多人使用，包括 Intercom 和 Google Docs。

卡片

像物体一样形成。由 Slack 和 Gmail 使用。

扳机

打开一个新窗口并调用 API。iFrames 使用供应商特定的 API“编程语言”调用客户端 javascript。

最佳实践要求为开发人员提供一些 UI 组件，以便界面看起来一致。一个很好的例子是 Shopify，他们正在激励和简化开发者的体验；他们只是给出了更多的代码，也就是说，组件的样式就在他们的库中，而不是推出一个特定的 UI；这样就可以更快地编写应用程序，并拥有一致的用户界面。

更进一步，帮助您的开发人员在清单、表格(脸书)或开发门户(Trello)中轻松管理他们的应用。

嵌入式框架使第三方能够在您自己的界面中，在您自己的用户体验中深入工作。我们已经介绍了如何超越 API，以及如何理解服务如何与您的产品相联系，并为您的用户创造有意义的体验。

建立框架，让这些第三方应用成为体验的一部分，是留住客户的基础。

原文：https://www.moesif.com/blog/product-management/api-analytics/Whats-The-Best-Way-To-Determine-The-Price-Of-An-API/

作为一个 API 提供者，一旦你决定从你的 API 中获得收入，下一步就是弄清楚你将如何为使用定价。和任何商业决策一样，有很多方法可以为 API 定价。有许多短期策略可以建立初始定价，然后反复寻找最适合您客户的定价模式和价位。从长期来看，还可以采取一些措施来确保您的定价保持相关性，并平衡保留和收入。

在本文中，我们将深入探讨 API 定价的所有相关问题。我的目标是给你一些想法和一些最佳实践。希望在本文结束时，您将对 API 定价以及如何将下面的技术应用于您组织的货币化 API 有更好的理解。最后，我们将看看 Moesif 如何帮助你弄清楚哪些 API 可以赚钱，如何定价，以及如何实际向用户收取使用费。让我们跳进来吧！

与大多数产品定价一样，API 定价包含两个主要问题:将收取什么指标的费用，以及将实施什么定价模型？例如，您可以选择对每个 API 调用计费，并对每个调用收取固定的费用。当使用量超过一定数量时，您还可以享受每次通话的折扣率。也许您会决定只对每个用户或用于访问 API 的 API 密钥收费。

每家公司可能有不同的衡量标准，他们希望根据这些标准计费，并且可能希望实施不同的定价模型。这些选择都非常依赖于你正在货币化的 API 和你的业务需求。

什么是收费的通用指标？

有无限多的度量标准可供选择。不过，一般来说，我会想到一些常见的场景。以下是一些用于衡量 API 使用情况的最常用指标:

每个事件

这个指标适用于进入 API 的每个调用。每次通话都被记录下来，并计入计费周期的总数。例如，如果您希望对每个 API 调用收取 0.10 美元的费用。如果用户调用 API 5 次，他们将在账单上收到 0.50 美元的费用。这是最受欢迎的指标之一，因为它最容易实现。

每个请求/响应的主体计数

在某些情况下，您可能希望计算 API 请求或响应主体中的元素数量。如果您想根据进出 API 的有效负载向用户收费，这是非常好的。例如，如果我们希望对请求体中的每个元素收费 0.10 美元(因为每个元素都将由我们的服务处理)。在这种情况下，如果开发人员发送一个请求，请求体中有 3 个要处理的元素，他们的 API 调用将被收取 0.30 美元。

每个唯一用户

当您希望根据访问 API 的唯一用户来收取使用费时，这种方法非常有用。与使用 API 密匙不同，在 API 密匙中，一个用户可能有几个密匙，相反，您在用户级别收费。举个例子，如果你想对每个用户每月收费 10 美元。在这种情况下，不管用户使用多少 API 键，可能每个环境或应用一个，他们访问平台的 API 只需支付 10 美元。

每个 API 密钥

与每个唯一用户类似，费用将基于用于访问 API 的唯一 API 键的数量。在计费期结束时，总 API 密钥使用量将被累加并计费。例如，如果每个 API 键每月的成本为 5 美元。在这种情况下，如果一个开发人员有 3 个 API 键，他们使用这些键来访问 API，那么这个月他们将被收取 15 美元的使用费。

除了这里讨论的指标，还有很多其他指标。其中一些可能提供了一个很好的起点，随着您的扩展，您可能会发现需要测量更复杂的指标来适应您未来的用例。

定价模式千差万别，尽管许多公司都使用一些主要的定价模式。下面让我们快速了解一些更标准的定价模型，这些模型可以在对 API 使用收费时使用。

标准定价

当您希望对每个 API 调用或每个唯一用户收取相同的价格时，可以使用这种定价模型。本质上，每一个被记录的使用单位都将在相同的价格点上被收费。这是现存的最简单的定价模型，如果你不想一开始就变得太复杂，这可能是一个很好的起点。

包裹

当您希望按包或一组单元对 API 使用收费时，可以使用这种定价模型。例如，您可以将其设置为每 1000 次 API 调用收取 10 美元。每当用户超过 1000 个 API 调用阈值时，他们就要再支付 10 美元。

分等级的

如果您想使用定价等级来收取使用费，分级定价是可行的。例如，在分级定价方案中，您可能对前 100 个单位收取$10.00，然后对接下来的 50 个单位收取$5.00。

卷

使用基于数量的定价可用于根据售出的单位总数对每个单位收取相同的价格。例如，您可以对 50 个单位收取$10.00，或对 100 个单位收取$7.00。在计费期结束时，使用量总计，总使用量将决定应用于每个使用单位的价格。

当然，这并不是一个详尽的列表。根据客户或产品的不同，您也可以对每种产品使用不同的定价模式。选择对您的特定 API 最有意义的定价模型应该在推动客户使用和确保收入最大化之间取得平衡。

一旦你决定了衡量标准和定价模式，你就必须决定你将向客户收取多少费用。当然，这可能非常复杂，取决于您使用的指标和定价模型等因素。下面的建议旨在指导您在考虑 API 价格时的一些重要考虑事项。

为您的业务计算 API 的成本

你需要考虑的一件事是你的 API 给你的业务带来的成本。这种成本可能是持续的支持成本、新特性的开发成本，甚至是 API 利用的第三方 API 或服务增加的成本。

最容易确定的成本是您的 API 使用的其他服务以及与它们相关的成本。目标应该是至少涵盖这些将直接导致您的业务支出的成本。您可能会考虑第三方 API 成本，可能是您的 API 用来提供其功能的其他服务，或者甚至是您的基础设施成本，如果 API 调用量会使成本增加或减少的话。

创造一个产品也需要花费时间和金钱来支持和持续的工程努力。这也应该被计算到你的 API 的拥有成本中。如果用于支持和维护的资源将大部分时间花在货币化的 API 上，这一点尤其正确。计算出 API 的基础成本或总拥有成本，可以帮助您了解价格应该从哪里开始。

你通过你的 API 增加了多少价值？

你的 API 给潜在用户带来了很多价值吗？例如，价值可能有许多不同的形式，但最常想到的一种形式是公司从使用您的 API 中节省了多少成本。这种节省通常表现为他们在内部开发类似服务的成本。如果这项服务需要他们 2 天的时间来创建和部署，也许你需要给你的产品增加一点深度，以获得更高的使用价值。另一方面，如果他们需要几个月的时间和大量的预算来建立你已经创造的东西，那么你可能处于一个非常好的位置。

可能很难量化确切的价值，但你应该很清楚在内部构建一个同等的服务需要什么，以及为了使用你的服务和构建他们自己的服务，公司可能愿意支付多少。另一种衡量价值的方法可能是，如果你通过你的 API 提供一项服务，而这超出了你的潜在市场的专业范围。这意味着他们可能需要雇佣一整套员工来创造你已经有的东西。使用您添加的值来给出您的定价范围，并最终确定您的 API 的价格。

你应该使用什么样的定价模式？

一般来说，在这方面你有两个重大的决定:你会收取订阅费还是根据实际使用情况收费？两者都有优点和缺点，也有结合两种范例的方法。例如，您可以收取每月 1000 次 API 调用的订阅费，然后以超额费的形式收取超额使用费。如果你决定对超额收费，除了定价模型之外，你还需要考虑你的超额模型。

一旦您确定了上述更高层次的定价问题，您就可以决定是否实施任何基于数量的定价、分层定价和其他可用的潜在定价方案。一些公司努力提供简单的定价策略，而其他公司则有大量的灵活性和选择。根据您的客户，以及他们可能使用的其他产品，您可能会感觉到哪种定价模式最有意义。

您是否应该将 SLA 和支持纳入使用成本？

除了按使用量收费之外，一些公司还对不同级别的支持收取额外费用。这可能是为你的 API 增加收入的另一种方式，可以计入你向客户收取的总价格中。你仍然可以根据一个严格的定价方案对你的 API 收费，但是对需要这样一个协议的公司的升级收费，比如一个改进的支持包。

你的价格点不必永远一成不变。与大多数产品和服务一样，随着时间的推移，成本往往会增加。客户通常期望在某个时候有所增长，只要价值仍然以同等或超过的方式交付，他们就不会因为成本而流失。

您应该何时评估您当前的定价模式？

这个问题的答案很大程度上取决于你的商业模式。如果你做的是按月或按使用付费的模式，价格点在技术上可以随时改变。显然，你要确保客户意识到保护自己免受任何负面影响，并给客户一个适应新费率的机会。然而，如果你有一个按年付费的企业计划或更严格的基于时间的合同，你可能只能在续约时增加价格。

与竞争对手比较评估你的价格总是好的。如果您的服务更贵，您可能希望深入挖掘差异化优势，并从这方面推动，以确保您向消费者展示了成本的价值。

总的来说，应该经常评估和重新评估定价。这应包括查看您的收费、客户可以使用的定价模式，以及新功能是否保证整个定价方案的价格上涨，或者是否应在购买选项中添加新的产品包或附加产品。

推出价格变化的最佳方式是什么？

推出价格变化的最佳方式是确保你有准确的反馈回路。当价格发生变化时，您需要进行监控，以便客户成功和销售团队能够尝试带回流失的客户。这更像是一种被动的方法，并不是每个客户都会回来，有些人可能担心未来价格会进一步上涨。

你也要确保任何价格变化都得到很好的沟通。如果客户要续约，尽早开始谈判。如果顾客每月用信用卡付款，试着在下一个账单周期开始前让他们提前知道，这样他们就不会感到惊讶。需要注意的一点是，不要过度传达价格变化的“原因”。您可以简单介绍新功能、改进的 SLA 或其他高层次的增值，以证明增加的合理性。然而，通过列出你改进的所有特性，这可能会给客户一个机会说“我不使用它，为什么我要为它付费？”以及其他可能反对涨价的理由。

最后，你也可以在客户调查中添加一个关于价格的问题，以检查他们对当前价格是否满意，或者他们是否认为价格过高或过低。询问顾客“你愿意为我们的服务支付的上限是多少？”实际上是一种很好的方式，可以看到客户的感知价值，并在不试验实际价格的情况下测试上限可能是多少。

免费试用，免费层，还是什么都没有？

评估你的试用期价格也是你可以玩的东西。如果你有一个免费的试用版，试试它的长度也可能会吸引更多的付费用户。你可能会发现你的免费层“太好了”,许多客户会继续使用它。这可以防止客户跳到付费计划，因为免费计划已经涵盖了他们需要的一切。或许取消任何审判对你的生意有利？

试用可能是采用的主要驱动力，评估你的试用期优惠对你和你的客户如何起作用是定价策略的一部分。如果你在产品中尝试试用产品，确保有大量的分析输入，这样你就可以跟踪变化的真实价值。

有了 Moesif，使用 API 分析来帮助确定哪些 API 可以赚钱以及收取什么价格成为了一门更精确的科学。当然，你可以猜测所有这些因素，通过反复试验，找到有效的方法。这带来了巨大的风险，也浪费了从一开始就增加收入的机会。

使用 Moesif 平台可以帮助您为 API 找到合适的价格，引导价格变化，并优化入职。该平台可以通过使用 SDK 的现有 API 代码或利用我们的插件通过 API 网关轻松集成。

研究 API 端点的 API 使用情况以盈利

您熟悉哪些 API 的流量最大吗？你知道流量来自哪些公司吗？通过询问和回答 API 使用中的关键问题，您可以快速确定利用哪些终端赚钱。你甚至可以准确地预测 API 何时开始货币化。Moesif 可以帮助生成报告，以您可能从未见过的方式显示 API 使用情况。

Moesif 的一个条形图，展示了每个客户的用户在哪里生成了最多数量的 API 事件

通过使用 Moesif 深入挖掘您的 API 使用情况，您可以发现许多问题的答案，这有助于确定 API 的价值以及潜在的收费标准。实施货币化后，这些报告可以帮助您查看用户和公司层面的收入，以推动长期组织目标，并为您的 API 产品路线图提供信息。

用户漏斗和留存

Moesif 的用户漏斗报告，显示完成三个集成阶段的用户百分比

在你实施或改变你的定价后，你需要确保客户仍然在转化为付费客户。这可以通过 Moesif 中的用户漏斗来跟踪。用户漏斗将允许您概述您的转化漏斗中的每个步骤，并查看在每个步骤中用户转化的百分比以及需要多长时间。

API 保留图表显示了哪些用户在不同的集成阶段使用了哪种语言。语言包括 node.js，python，go，ruby，php

留住顾客也很重要，尤其是在价格变化之后。通过留存报告，您可以查看产品的历史留存率，并确保最近的定价策略变化有利于您的业务，而不是降低留存率。

计费仪表

流程图显示数据从您的应用或 API 转移到 Moesif，然后再转移到支付处理器 Recurly、Stripe 或 Chargebee

Moesif 还可以帮助在您的 API 上实现货币化。通过使用计费表，您可以建立您想要货币化的终端和定价模式，并将使用总量发送给计费提供商，如 Stripe、Recurly 或 Chargebee。Moesif 的计费仪表以最少的工程工作量提供了端到端的货币化能力。如果您需要一个解决方案来轻松、安全、快速地将您的 API 货币化，那么 Moesif 的计费计量功能正是您所需要的。

最适合您业务的定价方案总是需要量身定制。对 API 调用进行定价可能非常困难，但是遵循上面的指导方针可以帮助您找到使它变得更容易和更精确的方法。确保您决定货币化的任何终端都能为开发人员及其组织带来价值，这对您的企业和他们的企业来说都是双赢的局面。

使用 Moesif 可以在 API 货币化的许多方面提供帮助，包括帮助您做出明智的定价决策，确定货币化的终端，以及在整个过程中跟踪客户保持率。首先，立即注册,亲自体验 Moesif 的 API 分析和货币化功能。

原文：https://www.moesif.com/blog/api-strategy/monetization/When-Should-you-Consider-Metered-Billing/

你曾经支付过电费、网络费或水费吗？该账单是基于您使用的资源量吗？如果是这样，您的提供商使用的定价模式是“计量计费”

如果你熟悉软件工具，你可能听说过这种模式的不同名称:“按需付费”、“基于使用的计费”、“基于消费的计费”、“PAYG”简而言之，这种支付模式允许客户只为提供的服务付费。不仅仅是公用事业。这种基于价值的定价模式与客户驱动的增长战略非常匹配，例如产品驱动的增长。此外，这种收入模式可以实时扩展。

SaaS 公司注意到了这一点。计量计费降低了新客户的准入门槛，在软件行业也越来越普遍。对于医疗创新平台提供商 NexHealth 来说，Moesif 基于使用量的计费使能够立即开始向客户计费，并帮助他们的 API 产品迅速成为收入来源。

那么，您应该考虑采用计量计费模式吗？

如果你正在建立一个 SaaS 平台，而你的客户是…

…开发人员，或者是高度技术性的人员

…您服务的早期采用者

…付费使用您的 API 产品

然后，计量计费可能会加速你的增长。

对于你的潜在客户来说，购买任何软件服务或功能，尤其是一种新的软件，都不是一个简单的决定。这是一个大多数人只有在他们组织的技术领导的认可下才会做出的决定。顺畅、透明的计费体验有助于赢得客户和忠诚度。这对于你想转化为客户的开发者主导的 B2B SaaS 公司来说尤其如此。

计量计费迎合了软件专业人员的自主文化。让技术决策者完全控制他们的发现过程，使他们能够更快地集成。即便如此，任何 SaaS 定价模式的成功都取决于你如何衡量你的核心业务。

如果您可以跟踪价值指标，例如…

API 调用的次数

…唯一用户

…独特的会话

…API 密钥

那么计量计费绝对可以扩大你的客户群。

跟踪服务的关键价值指标将确保您和您的客户从您的产品中获得最大收益。例如，专门从事 SMS 的 API 产品在每次发送文本消息时都提供价值。假设 API 在一次 API 调用中平均发送 100 条消息，作为一个批处理。在这种情况下，服务的值映射到发送的 API 调用数的倍数。通过将这一价值指标附加到客户的账单上，他们为服务的真实价值付费。

该平台现在可以自动向发送更多短信的用户收费，而不会惩罚那些使用率较低的用户。这种定价的透明度可以提高收入，并建立现有客户的忠诚度。

值得注意的是，计量计费有被滥用的风险。一些客户会产生他们不打算支付的费用。您可以通过使用 Moesif 实现速率限制来缓解这个问题。或者，您可以自己构建这样的功能，尽管这样做通常很耗时且成本很高。

尽管存在这一缺陷，计量计费模式可能意味着增长和停滞之间的差异。

如果您正在考虑为您的企业建立基于使用量的计费模式，请点击此处查看我们的完整实施指南。在那里，您可以彻底确定这种计费模式是否适合您的企业。

如果您有更具体的问题，我们也可以提供帮助。

• 我如何使用 Moesif 和 Stripe 进行现收现付？
• 计量计费如何帮助我将 API 货币化？
• 什么是产品导向型增长？

或者，参考我们的计量计费页。无论您选择哪种定价模式，我们都希望这是您的制胜策略。

原文：https://www.moesif.com/blog/financial/procurement/When-to-Build-vs-Buy-an-API-Analytics-Solution/

如果您以前从未购买过软件，购买新的企业分析解决方案会是一种很好的体验，但也可能是一项艰巨的任务。对于特定的用例，可能会有许多具有重叠功能的分析供应商，但每个供应商都有自己的优势和劣势。除了购买现成的 SaaS，你还可以在 Spark、Druid 和 Elasticsearch 等开源软件上构建自己的内部 API 分析基础设施。本文深入探讨了何时构建与购买现成的分析解决方案是有意义的，并提供了一个基于点的框架，用于在执行尽职调查时评估 API 分析解决方案。

公司应该做出的第一个决定是，他们是想要构建基础架构还是购买现成的解决方案。两者都有好处和风险。总的来说，采购缩短了精心设计的分析解决方案的交付时间，与自主开发相比，时间和资金成本更低，但自主开发可以让您更好地控制被跟踪和呈现的内容。

从 0 分开始回答以下问题。

如果您对以下任何一项回答是，则加 1 分:

您的资源有限吗？

购买现成的分析解决方案几乎总是比自己构建和维护一个自主开发的解决方案更便宜。供应商可以分摊 R&D 成本来构建高性能基础设施，该基础设施可以扩展到许多客户的数十亿次 API 调用。此外，现成的 SaaS 解决方案几乎没有维护开销，而本土解决方案由于工程师更替、产品忽视和不断变化的业务需求，随着时间的推移会产生技术债务。根据 SAP 的数据，78%的本土企业应用在首次使用后就被抛弃了。由于工程资源的重新分配，功能和缺陷修复(甚至是关键的安全修复)在最初交付后仍然没有解决。如果您没有专门维护您的自主解决方案的数据基础架构团队，购买几乎总是有意义的。

你时间有限吗？

由于功能蔓延和意外的洋葱皮，构建一个可用的分析解决方案可能会拖上几个月或几年，即使对于快速移动的团队来说也是如此。完全托管的 SaaS 解决方案不到一天就可以启动并投入运行。您的团队在构建分析基础架构的每一天，都没有花费时间来构建客户要求的功能，从而推动您的底线增长。购买可以让你将精力投入到核心竞争力上，而不是报告基础设施。如果您的分析解决方案的第一次迭代需要六个月的时间，那么在数据收集和访问适当的数据方面会有六个月的延迟，从而导致次优的规划和执行。

实时性能重要吗？

您是否关心第二天是否会出现新数据，或者您是否在寻求实时监控和异常检测功能？供应商可以投入大量资源来使他们的解决方案具有高性能和实时性，如果您希望获得关于 API 和帐户级别运行状况的实时警报，这是必要的。为了缩短时间表，自制系统通常构建在 SQL 和 Hadoop 等现有技术上，供应商可以将更多资源投入到定制的数据存储和基础设施中。

许多团队需要访问数据吗？

公司范围内的工具需要强大的访问控制、审计日志、数据管理以及易于使用的界面，以便非技术用户可以访问现成解决方案已经内置的数据。自行开发的 API 分析解决方案通常是由工程师为工程师设计的，迫使非技术用户依赖于向已经超负荷的数据团队提出请求。这大大降低了洞察时间。

此外，由于急于快速构建，自制解决方案通常没有任何安全功能。大多数安全事故是由内部人员而不是第三方造成的，有时是由于员工共享密码、员工不了解适当的 IT 安全政策以及没有自动检测本土系统的威胁而无意造成的。仅仅因为它在公司防火墙后面并不意味着它是免疫的。

您的团队是否不熟悉隐私和合规法律？

随着 GDPR、CCPA 等法规以及即将出台的电子隐私法规的出台，企业现在不得不应对比以往更多的法规。本土的分析系统很少有适当的框架和功能来处理像 GDPR 的删除权这样的事情，以及停止收集特定用户或公司数据的方法。来自第三方供应商的现成 API 分析解决方案通常已经有了额外的特性和框架，可以让他们的客户更加轻松地完成这项工作。毕竟，他们的主要业务是销售合规的 API 分析软件。

您需要特定的集成吗？

您的 API 分析解决方案是仅由工程部门使用，还是您希望其他团队(如产品、营销和客户成功)也利用您组织的 API 数据？如果是这样，每个团队可能都有自己的工作流和工具选择。例如，工程可能使用 PagerDuty 和吉拉，产品使用振幅和细分，客户成功使用 Zendesk 和 Salesforce，最后财务使用 Tableau 和 Slack 机器人。您会与这些产品中的每一个产品建立集成吗？否则，您可能会有数据孤岛，这降低了 API 分析的有用性，并降低了您组织的生产力。现成的解决方案通常有一个插件和集成的生态系统。

需要数据科学和创建正确的 API 指标方面的专业知识吗？

由于他们有帮助许多公司利用 API 分析的经验，供应商通常拥有深厚的专业知识，可以与他们的客户分享在您的组织中利用 API 分析的最佳实践和方法。他们能够提供一个框架来构建一个更好的平台，并可以向您提供教程和其他知识来帮助您的组织。自行开发的系统通常是在没有任何专家参与的情况下构建的，包括不断发展的 API 平台和要测量的内容。在 API 分析方面拥有深厚专业知识的合作伙伴可以帮助您开始跟踪 TTFHW (Time to First Hello World)等核心指标，并指导您了解 API 群组保持率分析的最佳实践，同时了解哪些自定义指标对您的业务非常重要。

如果您对以下任何一个问题的回答为是，则减 1 分:

你在一个高度管制的行业吗？

某些高度管控的行业(如医疗保健和银行业)对数据的保存位置和可以收集的数据类型有非常具体的要求，例如 HIPAA 合规性。在这些情况下，构建自己的系统来完全控制数据而不依赖第三方供应商是有意义的。虽然大多数第三方供应商已经遵循了 SOC 2 和 ISO 合规性的一般最佳实践，并强化了基础架构，但可能没有 HIPAA 这样的行业特定合规性。如果他们这样做了，可能需要一个特殊的计划，不管怎样，你自己开发的系统也必须是兼容的。不要陷入假设内部系统对法规遵从性免疫的陷阱。

您想完全控制信息的外观吗？

构建分析解决方案可让您完全控制如何将信息呈现给最终用户。虽然许多现成的解决方案确实提供了为面向客户的门户定制仪表板和白标的方法，但如果您有非常具体的需求，则需要在内部构建。

你有具体的分析功能和指标路线图来跟踪吗？

您的组织是否有明确定义的路线图，说明哪些分析功能现在和将来都很重要。你认为供应商不能继续增加更多的高级功能吗？你的团队是否有某些其他公司没有跟踪的商业秘密指标？如果你不确定衡量的最佳方式是什么，read-made 解决方案将提供一个定义良好的框架，因此你不必考虑哪些分析功能是重要的，但这可能会限制你衡量非常具体的事情。

您有专门的数据工程资源吗？

您是否有专门的数据工程团队和数据科学团队来构建和维护这一平台？他们以前在您的组织中是否已经构建并支持过分析基础架构？一个专门的团队不会不断地在功能开发和构建分析基础设施之间进行上下文切换。这让他们有更多的时间花在维护和改进上。

拥有内部分析能力会给你带来竞争优势吗？

如果你正在构建和销售一个支付 API，而你的主要竞争优势是支付可以用全球每种货币进行，甚至可以在没有互联网服务的情况下离线进行，那么在内部构建你的支付基础设施是有意义的。另一方面，除非你从事销售分析解决方案的业务，否则与在分析领域拥有深厚专业知识的供应商合作是有意义的，这样可以补充你自己的工程专业知识，而不是另起炉灶。供应商不仅可以带来他们的基础设施，还知道如何跟踪最佳指标以及如何更好地跟踪它们。

你想开源你的分析基础设施吗？

构建自己的分析基础设施的一个被忽视的好处是，你也可以开源它。如果你的公司对开源内部工具有友好的政策，这可能是一个促进招聘工作的好方法，特别是如果你想招聘更多的数据工程师。既然你完全控制了分析平台，你可以随心所欲。如果你计划开源，确保你尽早做出决定。开源项目对代码的整洁性有更高的要求，并且还需要能够作为一个单独的容器运行，而不需要建立许多依赖的服务。如果您的分析基础设施依赖于许多组件，如 SQL 数据库、Hadoop、Spark 和 Kafka，那么开源可能会更加困难。

你有一个非常狭窄的用例吗？

如果您有非常具体的用例，并且不打算从那里扩展，构建有时是有意义的，因为您可以在计算和磁盘空间上过度优化。这是最难决定的问题之一，因为很难为未知做计划。如果您想跟踪一个指标，并且知道这就是您所需要的，那么购买解决方案可能没有意义。然而，要小心今天的用例似乎特定的谬论，因为随着更多的团队开始使用你自己开发的解决方案，你会发现在你的组织中利用 API 数据的新方法。

构建与购买一个 API 分析解决方案可能是一个压倒性的过程，但是最好的公司在像上面那样应用一个方法时获得最大的 ROI。有时建议你两者都试试。毕竟，构建一个解决方案可能需要 6 或 12 个月，而购买的解决方案可能只需要几个小时就可以设置好。在这种情况下，首先购买是有意义的，即使是较短的合同，以便在您的公司研究需要什么来构建时启动并运行某些东西。今天基于 SaaS 的解决方案的了不起之处在于，你不需要承诺使用一个产品多年。购买一个解决方案，了解产品是如何工作的，然后在看到你的团队最常用的功能和他们不用的功能后去构建它。

原文：https://www.moesif.com/blog/technical/api-design/Which-HTTP-Status-Code-To-Use-For-Every-CRUD-App/

HTTP 规范定义了许多我们在响应客户时可以使用的状态代码。有些 API 只使用最基本的代码，并在其上定义自己的错误信号机制；其他人希望充分利用 HTTPs 代码集合来告诉他们的客户端发生了什么。如果你属于后者，这篇文章适合你。本指南介绍了各种 CRUD 操作，以及在干净的 API 设计中应该使用哪些状态代码。

状态代码是一个大于 100 小于 600 的数字，是 HTTP 响应的一部分。第一个数字定义了状态的类别。状态代码带有一个原因短语。代码是为了程序识别，短语是为了让人们理解发生了什么。

每个状态代码都必须遵循这两条规则，甚至是自定义规则(是的，状态代码是可扩展的)。

如果我们了解 a 类状态代码，我们可以更快地定位问题。

100 - 199

这些是信息状态代码；它们通常告诉客户端，请求的报头部分已经收到，服务器将尝试遵从客户端的传输要求。比如使用不同的协议，或者在开始发送消息体之前告诉客户端它的请求会失败。

200 - 299

这些是成功的密码。他们告诉客户它的请求被接受了。在异步处理请求(202)的情况下，这并不意味着请求被成功处理，只是说它满足发送时的所有验证要求。

300 - 399

这些是重定向代码。他们告诉客户端，他们请求的资源在预期的位置不再可用。这可能有多种原因，可能是暂时的，也可能是永久的，但客户端必须向新位置发出请求。

400 - 499

这些是客户端错误代码。它们都是关于客户端发送给服务器的无效请求。这有几个原因，超时，错误的 URI，错过认证等。客户端正在发送不正确的输入，应在重试请求之前确认输入参数是否正确。

500 - 599

这些是服务器错误代码。它们通常表示服务器过载或代理后面的服务器不可达的问题，但有时它们可能与触发服务器上错误异常的客户端请求直接相关。这些错误可能是暂时的，也可能是永久的。通常，客户端最好重试相同的请求。

自定义类别

自定义类，即 599 以上的类是不允许的，但仍被一些服务使用。对于 API 设计者来说，它们是相关的坏例子。然而，API 客户机创建者必须处理它们。

因此，虽然通常不允许，但要做好在野外遇见它们的准备。

CRUD 模型为持久存储定义了最基本的 API 动作。创建、读取、更新和删除。它们构成了 API 端点的最大部分。让我们看看哪些状态代码符合他们的要求。

创建动作通常通过 HTTPs 方法实现。在 RESTful APIs 中，这些端点用于创建新资源或访问令牌。

状态代码

• 这是告诉客户一切顺利的基本状态代码。因为我们在创建访问令牌时没有创建端点可访问资源，所以我们可以使用 200 作为该操作的状态。
• 201 创建了——最适合创建操作。这段代码应该发出后端资源创建的信号，并附带一个头，为新创建的资源定义最具体的 URL。在响应体中包含资源的适当表示或者至少一个或多个资源的 URL 也是一个好主意。
• 202 已接受 -常用于异步处理。这段代码告诉客户端请求是有效的，但是它的处理将在未来的某个时候完成。响应体应该包含一个指向已完成资源的 URL，其中包含一些关于资源何时可用的信息，或者包含一个指向某个监控端点的 URL，该端点会告知客户端资源何时可用。
• 303 参见其他——类似于 202 代码，但是使用头字段来响应通知客户端关于所创建的资源的位置或端点，该端点允许客户端检查创建过程的状态。一些客户端会自动跟踪重定向类的状态代码。这个代码通常只用于请求。

read 动作通过 HTTPs 方法实现，并用于获取资源表示。异步响应在这里并不重要，因为异步处理的原因通常是资源还不存在，需要创建，所以无论如何这是一个创建操作。

状态代码

• 200 OK -大部分读取动作将会以 200 OK 状态回答。
• 206 部分内容——这个代码对于太大而无法在一次响应中交付的内容列表非常有用。它必须与请求中的头字段一起使用。通常，这个头字段定义了后端应该发送给客户端的字节范围，但是只要双方都理解，这个单位可以自由分配。
• 300 多项选择——如果一个资源有多个表示，并且客户端(或其用户)必须选择其中一个，那么就使用这个重定向。
• 308 永久重定向——这告诉客户端使用另一个 URL 来访问资源，并且不再使用当前的 URL。当一个资源有多个端点，但不想实现从所有端点读取时，这很有帮助。
• 304 未修改——像 200 一样使用，但没有主体，所以客户端将从先前的读取被重定向到其本地缓存的表示。
• 307 临时重定向——当资源的 URL 在未来可能改变时，客户端应该在访问真实的 URL 之前询问当前的 URL。

可以用 HTTP 或方法实现更新。区别在于客户端必须发送到后端的数据量。

要求客户端发送一个完整的资源表示来更新它。(用新的替换旧的)

要求客户端只发送资源的部分表示来更新它。(在旧版本中添加、更新或删除这些部分)

状态代码

• 200 OK -这是最适合大多数用例的代码。
• 204 无内容(No Content)204 无内容(No Content)204 无内容更新(No Content)204 无内容更新(No Content)204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 无内容更新 204 客户端，例如当保存当前编辑的文档时。
• 202 接受 -如果更新是异步完成的，可以使用这个代码。它应该包括一个访问更新资源的 URL 或一个检查更新是否成功的 URL。它还可以包括对更新所需时间的估计。

删除操作可以用 HTTP 方法实现。

状态代码

• 有些人认为任何类型的删除函数都应该返回被删除的元素，所以被删除元素的表示可以包含在响应体中。
• 204 无内容 -最适合这种情况的状态代码。最好是减少流量，简单地告诉客户端删除完成，不返回响应体(因为资源已经被删除)。
• 202 Accepted——如果删除是异步的，并且需要一些时间，这是分布式系统的情况，适当的做法是返回这个带有一些信息或 URL 的代码，告诉客户端它什么时候会被删除。

如果我们的 API 存在足够长的时间，它迟早会改变它的结构。最好的做法是避免中断更改，状态代码的重定向类可以对此有所帮助，因为一些客户端会自动跟随它们的头。

状态代码

• 307 临时重定向(Temporary Redirect)——如果将来资源可以在不同的 URL 上使用，这是正确的代码，但是我们希望当前的端点控制客户端重定向到哪里。这个状态代码将让客户端为每个请求返回到当前的 URL。
• 308 永久重定向 -如果资源现在可以在新的 URL 上使用，并且客户端将来应该通过新的 URL 直接访问它，那么这就是正确的代码。当前端点无法控制请求后的客户端行为，如果资源 URL 再次更改，则必须从新的 URL 发出后续重定向。

一个资源有多个端点

如果我们选择在我们的 API 中使用嵌套或子资源，那么只从根(非嵌套)资源交付表示将有助于保持实现的干燥。重定向状态代码对此有所帮助。

状态代码

• 308 永久重定向——如果我们有嵌套资源和；和根资源它可以使事情变得更容易，只需在嵌套资源中发出 308 重定向，其中头字段指向根资源，因此不是每个端点都需要交付实现。这应该只针对的请求。

API 的下一个重要部分是它的错误。许多 API 框架在出错时默认使用 500 和 404 状态代码，但是根据具体情况，通常会有更多的描述性代码。

500 表示内部服务器错误，这可能是后端访问时没有检查其存在而丢失的头字段，也可能是后端想要调用的无法到达的第三方服务。

因此，可能是客户端做错了什么，我们会期待一个 400-499 的状态代码，但后端从来没有尝试验证请求，并试图处理它，即使它是无效的，我们最终与服务器错误。

404 表示未找到。这可能是因为客户端使用了一个错误的 URL 指向一些没有在后端正确设置的端点。

正如我们看到的，404 是一个客户端错误状态代码，但它很可能是我们在后端做错了什么。

错误的 URL

当客户端发送一个 URL 时，我们不知道。这可能有多种不同的原因，因此我们必须检查哪一种原因适用于此处。

状态代码

• 404 未找到 -这是最自然的反应，应该在客户端 URL 错误的情况下使用。
• 不允许使用 405 方法——在许多框架中，我们在 HTTP 方法旁边定义了 URL，因此删除其中一个定义会使一个 URL 的所有方法保持不变，只留下一个。响应必须包括一个列出允许做什么的头字段。
• 501 没有实现——像 405 一样，但是后端的所有资源都缺少该方法。
• 406 不可接受-URL 存在，但后端无法发送客户端将接受的表示。因此，对于特定的客户端，URL 的行为类似于 404，但是他们现在知道他们需要更新客户端。
• 410 消失了，这就像 404，但是我们知道资源在过去存在，但是它被删除了或者不知何故被移动了，我们不知道它在哪里。
• 414 请求-URI 太长 -当端点是正确的，并且资源存在，但是查询使 URL 太长而无法解释时，有时会出现这种情况。
• 308 永久重定向(Permanent Redirect)——如果我们知道一个资源已经移动到了一个不同的 URL，并且我们可以告诉客户端，那么这将是正确的代码。
• 307 临时重定向——和 308 一样，但是我们不知道将来资源是会回到原来的 URL 还是另一个不同的 URL。

没有权限

通常客户端不能访问后端的所有资源，所以我们需要一种方式来告诉他们。

状态代码

• 401 未授权 -客户端还没有授权自己访问后端，服务器可能会在授权之后授予它访问权限。
• 403 禁止 -客户端已经授权或者不需要授权自己，但是仍然没有访问资源的权限。
• 404 未找到 -如果 401 或 403 是这种情况，但后端出于安全原因不想告诉客户端该资源存在。

HTTP 的创建者在设计它的时候考虑了许多状态代码，甚至在过去的几年里添加了许多新的状态代码。如果正确使用它们，它们可以通过利用客户端的自动重定向跟踪和更清楚地解释发生了什么来帮助极大地改善开发人员的体验。

有时我们可以为一个特定的情况使用多个代码，重要的是我们在整个 API 表面上保持使用的一致性。

原文：https://www.moesif.com/blog/developer-marketing/inbound-content/Why-Content-Is-the-Key-to-Unlocking-Your-Developer-First-Marketing-Strategy/

创立一家以开发者为先的创业公司和创办一家普通公司不太一样。当你的主要焦点是创造产品卖给开发者时，你需要围绕这些开发者的需求建立一个销售策略。偶尔发一封带有“点击此处观看演示”按钮的邮件是不行的。相反，是时候制定你的内容策略了。

为什么要相信我们的话？因为内容是 Moesif 在与开发者联系时的头号策略。如果你正在读这篇博客，这个策略正在起作用。

向开发者受众销售是关于建立你的可信度。他们需要知道他们可以相信你的产品能够可靠高效地交付。这意味着你必须证明你知道你在说什么。

但事实远不止如此。总的来说，开发人员是一群好奇的人——他们喜欢进行自己的研究，深入主题，从不同的角度发现产品。这意味着你需要为他们提供多种途径来获得你的产品，并满足他们的输入需求。

一旦你建立了自己的信誉，确立了自己在特定领域的思想领袖地位，那么是时候考虑销售分层了。如果你有正确的内容策略，销售部分将很容易到位。

当然不是。一个强健的内容策略有多个方面。你可以举办面对面的活动，记录下来，然后转化成网络研讨会。然后，您可以将这些网络研讨会转录成文章——用于您自己的博客和您的开发人员受众经常访问的其他网站。当你把所有这些形式的内容结合在一起时，你就能从你的策略中获得最大的价值。

在每一点上，你的内容必须是有教育意义和有帮助的。它需要向读者传递价值，而不仅仅是营销信息。通过这些有价值的内容，你将有机会在开发者眼中成为你特定产品领域的思想领袖。成为某个特定主题的第一名文章可能非常有价值。

一个好的内容策略有几个层次。在漏斗的顶部是关于一般问题和解决方案的内容——十大综述、博客文章、信息图表等等。目的是为你的品牌建立一个初步的认知，把你自己放在开发者的雷达上。

接下来是向开发者展示如何使用你的产品/平台/工具来完成某件事情的内容。从本质上讲，它是如何让他们的生活变得更容易的。这是关于在不同的场景中展示你的产品的真实价值，当然是以一种温和的、非促销的方式。

一旦你的开发者准备好发现更多？此时，您可以分享您的漏斗底部内容——您的深入案例研究、比较指南、白皮书等。

这项工作不仅仅是创造你的内容。事实上，许多内容创作者犯的最大错误是不愿意分享他们的内容并获得反向链接。这些可爱的，有价值的反向链接，将说明你的专业知识，并展示你的内容作为开发人员需要的资源。

与许多人的想法相反，内容不是一个数量游戏。这是关于专业知识和可分享性。在 DZone 上创建一篇文章，你就能立刻吸引开发者的眼球。在 Stack Overflow 或 InfoQ 上，当开发人员寻找解决方案时，你就站在了最前面。这同样适用于任何吸引你的目标开发人员的网站。

清晰和信息图是你的朋友。你的内容越易读、越有用，人们就越有可能分享它。圣杯是让开发者在他们之间分享你的内容，在 Reddit 线程和社区论坛中使用它来回答彼此的问题。这时你就知道你已经搞定了。

在创建可共享内容方面，也有一些立竿见影的方法。举例来说，十大综合报道是在社交媒体上分享 10 个简单分享的好方法，你可以给你提到的 10 家公司都打上标签。请记住，你制作的每一个内容都要向读者传递价值。

当使用你的内容与开发者联系时，数据也很重要。你越了解哪些主题和哪些角度让开发者注册你的工具，或者积极参与你的平台，就越好。然后，你就可以很好地创建补充内容，为开发人员发现非常有价值的相同主题提供内容。

一旦你创建了这个杰出的、互联的内容网络，下一步是什么？那么，是时候让您的销售团队参与进来了，而且是以一种有意义的方式参与进来。真正关心开发人员的痛点并理解他们消费内容的意图的销售人员将会把潜在客户变成付费客户。

一个开发者至上的公司如果做得好，将最有可能吸引人们注册其平台/产品，并最终提高其底线。

原文：https://www.moesif.com/blog/customer-success/monitoring/Why-Data-Driven-Customer-Success-is-Essential-in-Today-s-COVID-19-World/

在今天史无前例的经济衰退中，寻找和接近新客户比以往任何时候都更加困难。现在的责任是保持现有的客户成为你产品的有效用户。通过密切监控 API 度量标准，客户成功管理(CSM)团队可以获得关于那些存在混乱风险的早期警告，并在为时已晚之前纠正事情。

根据不同的 调查，获得一个新客户的平均成本在 5X 和留住一个现有客户的 25 倍之间。那是在前 COVID 时代。在当今世界，可能更多。

CSM 的使命是帮助客户通过你的产品实现价值。客户价值实现是让客户不断回头客的飞轮。CSM 是加速飞轮的动力。

通过像 Moesif 这样以用户为中心的分析，可以密切关注您的客户在做什么，并在他们努力集成或使用您的产品和 API 时伸出援手。让我们看看您需要跟踪的重要指标是什么，这样您就可以达到您的保留目标

通过监控客户的活动，您将能够:

• 了解他们的使用行为
• 需要时提供更好的帮助
• 尽早发现客户流失
• 了解他们是否会续约

API 调用和保留的次数

通过跟踪客户何时开始和何时停止发送流量，了解他们何时参与(如下图所示)。将您的参数绑定到波段，这样如果值移动到预定义的波段，您会得到通知。使用实时警报主动识别并联系面临风险的客户。在 Moseif 中， alerts 可以通过 Slack、SMS、Email 和 PagerDuty 发送。有一级岗位懈怠，然后二级开火到 PagerDuty。如果需要，升级到工程或该系统的任何待命人员。

为类似的活动创建群组可以实现对大量客户的高效监控，无论他们是个人用户还是公司。按最活跃的公司分组，有 5 个以上 API 错误的新用户和许多其他类型的字段(上图)。

错误事件和流失

快速发现错误的有效负载，并与客户一起进行分类以确定问题。发现失败的系统并避免流失。如果您的客户集成了您的 API，但一直收到 400 或 500 错误，请在错误发生时立即得到通知，联系客户并控制它。按出现错误的每个用户的顶级 API、出现 4xx/5xx 错误的新用户、最大延迟(下图)等进行分组。

群组保持

随着时间的推移，准确测量产品保留率和粘性。产品保持率衡量的是一群用户中以某种方式与你的 API 交互，然后又回来与你的 API 交互的用户的百分比。按新用户、使用的 SDK 等分组(如下图)。

CSM 团队现在面临着更大的压力来达到保留指标。随着商业因冠状病毒和就地庇护而陷入低谷，数据驱动现在比以往任何时候都更重要。监控重要指标，以避免这些艰难的讨论，保持您的客户成功，并确保他们真正续约。

原文：https://www.moesif.com/blog/technical/logging/Why-I-Started-Another-Application-Logging-Company/

有许多日志记录和异常跟踪公司。从 Sumo Logic 到 Sentry，开发人员在应用程序日志记录和异常跟踪方面有了比以往更多的选择。为什么要在一个似乎有大玩家的领域创建一个新的伐木公司？

在创办 Moesif 之前，我是 Trove 公司的首席技术官，在此之前，我是英特尔公司的 CPU 架构师。在每个职位上，调试总是我日常活动的一大部分。在我们的项目生命周期中，我的大部分日常工作都涉及到调试。我会调试客户报告的问题，调试回归测试中出现的错误，在提交之前调试我自己的代码，等等。无法回避的事实是，大多数开发人员花在调试上的时间比花在编码和产品开发上的时间要多。

对于 Trove 栈，我们使用 Loggly 来存储来自后端 API 驱动服务的应用程序日志。这些是 Scala、C#和 NodeJS 服务的组合。对于我们的 web 应用程序，我们还使用 Sentry 来记录和跟踪异常。对于我们的移动应用，我们使用了 Crashlytics。

我们还使用 New Relic 进行了一些性能监控，尽管 New Relic 主要对操作和性能人员有用，但对应用程序调试没有用。

然而，即使有了所有这些服务，调试仍然是一个手动和缓慢的过程。在自动驾驶汽车的时代，为什么我们不能让调试更加自动化？

收集上下文

在 Trove，我收到了一些客户支持请求，客户在登录时会遇到错误。

要开始调试，我必须收集客户上下文，比如错误发生在什么设备上以及错误发生的时间。我通过从支持票据中搜索客户的电子邮件，在我们的用户数据库中查找了 user_id 。

在得到一个用户标识后，我进行了日志搜索，希望这个用户标识被记录为异常。

唉，我发现错误了！但问题是 Loggly 和 Sentry 中记录的异常非常普通:

缩小失败服务的范围

我们有相当多的微服务支持我们的后端利用工具，如 Docker。有些是 Node，有些是 Scala，等等。然后我们有了移动和网络应用。Loggly 中的错误只会告诉我错误发生在哪里。然而，我们都知道，通常错误是一些因果关系的结果，但原因可能是错误发生的上游。

为了缩小根本原因的范围，我继续进行我的手动日志搜索，寻找相关消息，试图追溯到源头。对于这个特殊的登录错误，我能够追溯到第三方 API，Google 认证 API。

消除过程

即使我们看到记录的错误，现在知道这是由于谷歌 API，它仍然是非常短暂的。即使在尝试完成谷歌登录步骤时，我自己也无法重现错误。

我开始收集更多的信息。

• 错误是否只发生在特定的数据中心？
• 它是通过 Google 登录 API 的特定参数发生的吗？
• 第一个出现这个错误的版本是什么？

对于任何开发人员来说，做这个排除过程的时间会非常长，是一种时间浪费。

结果呢

我们最终找到了导致错误的根源，在这种情况下，由于短暂的 HTTP 超时，移动客户端会调用 Google Auth API 以获得一次性使用授权代码(OTU)。这个 OTU 令牌被传递给我们自己的 API，然后它调用另一个 Google API 来验证授权代码，并交换一个访问和刷新令牌。由于授权码已被使用或过期，该最终端点将出错。

我们必须追溯到被调用两次的初始 auth 端点。谷歌将返回相同的 OTU 代码(可能是由于缓存)。

API 调用流程:

1.顾客必须告诉我

即使有始终连接的警报(Slack、PagerDuty、DataDog 等)，我仍然有客户告诉我有问题。为什么我们的测试没有发现这个？为什么 Sentry 或 Loggly 没有在客户之前提醒我这些问题？

一个提示:状态空间爆炸和 bug 的动态本质。

错误表现为特定的:

• 系统的状态
• 系统的输入(包括计时)

如果我可以精确地重新创建状态和输入，那么我就可以重新创建任何 bug。问题是现代网络应用的状态比几年前复杂了几个数量级。

国家分散在:

• 许多不同的 Pb 大小的数据存储
• 许多不同类型的设备和客户端也存储状态
• 构建工件和代码版本的状态
• 配置和环境状态
• 操作系统/虚拟机/容器状态

输入现在分散在数百个容器中，并且必须考虑网络延迟输入、用户对设备的输入等。

警报仍然是静态的(即，如果错误率在下一分钟翻倍，我必须设置警报来提醒我)。测试也是静态的。测试是人为设计的场景，很多时候是由开发人员编写的，他们也对特性进行编码。如果该特性由于跨服务交互的架构假设而存在缺陷，该怎么办？这些假设也可能被纳入测试，造成错误的通过。

2.日志搜索仍然非常手动

一旦我在日志记录或异常跟踪软件中发现错误，我仍然需要自己进行日志搜索。

从调试登录问题可以看出，从支持电子邮件中查找 user_id 需要时间。然后我必须找到该用户发生的异常。

调试就像尝试一堆小实验。您根据当前对错误场景的了解提出一个假设，然后研究日志，看它是否验证了您的假设。

你需要一遍又一遍地重复这一点，直到你有足够的证据断定根本原因是。

这个过程听起来不像是计算机能做得更快的事情吗？

3.日志必须手动编码

大多数开发人员会记录每个异常，或者至少记录他们认为的错误。如果您需要追溯到导致错误的服务，而消息没有被记录，该怎么办？就像人工测试一样，开发人员只能记录他们认为调试服务需要的东西。如果一个新的 bug 以不同于预期的方式强调服务，并且没有记录足够的上下文，该怎么办？

您必须添加更多的日志消息，然后看看是否可以重新创建该场景。发布一个包含更多信息的新版本来捕捉问题需要时间。

4.日志不能显示交互

大多数日志和异常跟踪工具将消息本身显示为问题单，或者类似于跟踪日志流。如果错误是跨多个服务的呢？如何用简洁的方式表现这一点？当您开始研究与跨多个系统的并发性相关的更复杂的错误时，仍然很难仅使用日志来查找根本原因。

调试可能是有趣和令人兴奋的，尤其是有时当我发现一个疯狂的竞争条件时，这很有趣。然而，大多数公司不会因为“好玩”而付钱给开发者。花在调试上的时间不是花在产品开发或增长上的时间，这可能会影响收入和底线。

moes if 如何让调试变得更简单？

了解更多

原文：https://www.moesif.com/blog/best-practices/api-product-management/Why-Twilio-Customers-Are-Not-Going-Anywhere/

众所周知:我们是像 Twilio 这样的 API first 公司的粉丝。超过 1000 万客户使用他们的平台，看来我们并不孤单。

长期以来，Twilio 一直是开发人员的宠儿，它平易近人的平台使得在几乎任何环境下发送语音、视频和 SMS 消息都很容易。

今天，我们将深入了解 Twilio 如何在客户参与方面提供最佳服务。

“建造还是购买”，这是个问题。就像经典的莎士比亚难题，“生存还是毁灭”，必须做出选择。对于 SaaS 公司来说，增加新功能的成本曾经意味着在内部构建这些功能，或者向外部供应商支付额外的功能。这两种选择都带来了严峻的挑战。

现在有了第三种选择。低代码/无代码(LC/NC)工具提供了额外的功能，无需编写复杂的代码。使用 LC/NC 工具，通常需要几个月才能构建的软件可以在几周内发布。自然，选项已经越来越受欢迎。

Twilio 没有错过这一趋势，他于 2017 年底推出了 Twilio Studio。Twilio Studio 让客户无需编写代码即可享受强大的通信基础设施。这对于非技术用户，以及希望快速构建的精益工程团队来说非常好。

Twilio 的界面既方便又易于控制。开发者和产品经理都不需要担心决策疲劳。像宾利一样，Twilio 驾驶起来很平稳，同时在引擎盖下提供了大量动力。

仅在 onboarding 中，就很容易看出是什么让 Twilio 的界面如此出色。

从一开始，Twilio 就让用户知道会发生什么。预计到有人可能会问，“Twilio 是多少钱”，Twilio 立即让用户知道没有预付到期。

这是对他们在平台的每个方面提供的透明度的一个温和的介绍。Twilio 也很快让用户知道他们可以用他们的产品做什么。请参见他们早期入职流程中的以下元素作为解释。

在入职的最初几分钟，你就已经知道 Twilio 不打算给你惊喜。在平台的更深处，他们继续以同样的方式呈现新的信息。

少即是多

“完美的实现，不是当没有更多可以添加的时候，而是当没有什么可以拿走的时候。”-安托万·德圣埃克苏佩里

如果用一个词来形容 Twilio 的界面，那就是“精确”整洁的菜单、恰当的工具提示和强烈的视觉设计创造了一个干净的用户界面。

呈现给用户的每一个选择都被有意简化，而不失去意义。一旦用户完成了上述步骤，他们就会提供有针对性的问题来定制用户的新帐户。措辞直接、明确、平易近人。同时，呈现给用户的选择数量提供了没有压倒性的定制。

在这几个步骤之后，初始入职就完成了。从这里，用户第一次被引导到他们的仪表板。

用户可以立即体验 Twilio 的全部功能。免费用户有机会设置一个 Twilio 电话号码，添加队友，并尝试使用 Twilio Studio 进行 LC/NC 体验。

同时，可访问的支持资源确保任何需要详细信息的人都能找到它们。这些资源可以通过多个周到的链接获得，确保所有用户都能获得他们需要的信息。

用户可以选择通过帮助文章、文档、导游，甚至游戏 Twilio Quest 来了解 Twilio。

总的来说，Twilio 的界面提供了它所需要的一切，而没有损害用户体验。

在 Twilio 成为上市后独角兽公司之前，他们并不以像典型的 SaaS 企业那样销售而闻名。他们经常根本不“卖”。然而，它们仍然在增长。

创始人杰夫·劳森的一个著名故事完美地说明了这一点。

在劳森和两个朋友于 2008 年创立 Twilio 大约一年后，劳森受邀在一个名为“旧金山新技术聚会”的流行社交聚会上介绍它。劳森决定让 Twilio 软件自己说话，而不是谈论一种本质上难以解释的技术。在 1000 人面前，劳森开始讲述他的故事，同时编写了一个 Twilio 应用程序——一个简单的会议线路。

仅仅几分钟后，他就开了一个账户，获得了一个电话号码，在写了几行房间里每个人都能理解的代码后，他的会议线路就开通了。劳森然后要求每个人都打电话进来，就这样一群开发人员开了一个大型电话会议。劳森随后添加了一些代码，他的应用程序给每个人打了电话，感谢他们的参与。随着整个房间的电话开始嗡嗡作响，人群狂热起来。”–米格尔·赫尔夫特，福布斯

Twilio 为开发人员提供了尝试他们产品的机会，而不期望购买。虽然与当时占主导地位的企业销售模式相反，但跳过前期成本赢得了开发人员社区的信任。很快，Twilio 就赢得了任何项目都可以使用的工具的声誉。

Twilio 不仅仅将开发者视为潜在客户，他们将开发者视为一个社区。有些人甚至认为 Twilio 推广了开发者福音。虽然他们的支付模式只是他们的开发者主导战略的一部分，但它仍然使他们的产品变得伟大。

任何创建 Twilio 账户的免费用户都会发现一套强大的功能。免费试用用户有权获得一个 Twilio 电话号码，允许他们尝试语音通话、视频会议和短信功能。因此，即使 Twilio 的免费功能也提供了他们付费计划的现实预览。

如果用户决定超过他们的 15.50 美元的试算表，提供免费注册，他们的账单无缝扩展到 PAYG 定价。要了解更多关于 PAYG 模式的信息，请看我们的另一篇文章。

当新用户想成为客户时，他们会找到适合任何情况的计划选项。这对于几乎任何类型的用户来说都是非常好的，无论他们是想实验性地构建项目，为了好玩，还是为了重要的基础设施。几乎可以适应任何用例。

如果说在软件世界中有什么是不变的，那就是变化。作为一个把未来寄托在我们的信念上的公司，每个公司都将成为 API 公司，我们期待看到其他 API 第一的公司成长。

Twilio 继续适应 SaaS 不断变化的现实——它以适应迎接每一个新的挑战。我们渴望在 Moesif 获得类似的弹性，这就是我们提供透明定价功能和简化入职流程的原因。

Moesif 提供四个计划层级，每个层级都有灵活的 PAYG 计费

我们的定价模式结合了按需付费的灵活性和订阅的可靠性。用户可以使用我们的四个价格等级中的一个来衡量他们每月的使用情况。但是，如果他们使用我们服务远少于或多于预期，那么他们每月的账单将反映实际的使用情况。

与 Twilio 类似，我们也致力于简化入职流程。对于大多数安装，Moesif 只需要几行代码来添加我们的 SDK。每个入职工作流都可以根据用户现有的技术体系轻松定制。像 Twilio 一样，我们的平台旨在通过提供有针对性的信息来减少决策疲劳。

像 Twilio 一样，我们也提供“先试后买”的模式。这样，Moesif 用户可以在做出决定之前体验我们产品的全部功能。任何人都可以通过在这里注册免费试用成为用户。

总的来说，我们有充分的理由认为 Twilio 是客户参与方面的“领导者”。它干净的用户体验、对开发者社区的承诺以及创新的速度无疑使它成为通信基础设施的绝佳选择。换句话说，这一千万顾客不会很快离开！

原文：https://www.moesif.com/blog/engineering/chrome-extensions/Working-Around-Content-Security-Policy-Issues-in-Chrome-Extensions/

之前，我们讨论了一个用例，一个 Chrome 扩展通过脚本标签将一个脚本注入到网页中。该脚本将在该网页的上下文中运行，以便扩展可以访问资源并与网页共享 javascript 对象。然而，一些网页有一个内容安全策略，阻止 AJAX 调用不属于白名单的域。这篇文章解释了我们解决这个问题的方法。

本质上有三个执行上下文，其中每一个都是几乎完全隔离的环境。

• 网页的执行环境，这些包括网站最初加载的任何脚本，或者添加到文档的 DOM 中的脚本标签所包含的任何内容。在此上下文中运行的任何脚本都受网页的原始内容安全策略的约束。此外，你不能直接访问任何 Chrome 扩展资源。(查看如何将脚本加载到这个环境中)
• 内容脚本的执行环境。它们是由启动的脚本。内容脚本可以操作主机网页的 DOM。在这个执行上下文中，您不能访问网页上的任何 javascript 对象或函数。但它仍然可以访问 chrome 扩展资源，如或。
• Chrome 扩展本身的执行环境。

创建了 APIRequest.io Ajax Capture Chrome 扩展，以捕获单页面应用程序的请求和响应(以使这些应用程序的协作和调试更加容易)。在这个扩展存在之前，据我们所知，由于 Chrome WebRequest API 的限制，没有可以捕捉响应的扩展。我们找到的解决方案包括使用一个脚本标签将一个脚本注入到网页的上下文中，如本文中所讨论的

但是，由于时间限制，最初的版本没有添加与内容安全策略的兼容性。因此，在网页的执行上下文中，如果原始网页的内容安全策略不允许我们与不属于原始白名单的域进行通信，我们就不能进行 AJAX 调用(需要将捕获的数据存储在持久化和可共享的链接中)。

为了与任意内容安全策略兼容，解决方案是将数据传递到另一个不受内容安全策略约束的执行上下文，执行 AJAX 调用，并处理结果。

网页上下文和内容脚本之间的消息传递。

这涉及到使用

发送消息

变量是消息将被发送到的网页。因为网页和内容脚本实际上是在同一页面上执行的，所以通过使用主机网页的同一域，消息将被传递给内容脚本，反之亦然。

虽然可以做，但是“*”暗示任何页面都可以读取消息，这可能是危险的。如果消息是敏感的，您不希望恶意网页(在其他选项卡中)看到这些消息。

1.接收消息并进行 AJAX 调用

在内容脚本上下文中，我们不受内容安全策略的约束，我们可以接收消息并进行 API 调用。

由于发送消息的是同一个窗口，我们应该在接受消息之前检查以确保它是相同的。这确保了我们知道消息来自哪里。

2.将 Ajax 的结果返回到原始上下文

没有回调方法。因此，要将 AJAX 结果传递回原始网页，我们必须再次使用。

通过这种方式，内容脚本就像是对不在内容安全策略中的域的 AJAX 调用的代理。

ContentScript 和扩展之间的消息传递

因为两者都可以访问 Chrome 扩展相关的对象，所以你可以使用这些资源

从内容脚本到扩展:

将消息从扩展传递到内容脚本更有趣，因为这取决于您执行内容脚本的选项卡。(chrome.tabs.executeScript 也需要一个，所以你只要记住就可以了。)

消息传递也有回叫，这使得处理起来容易了许多。

我们的重点不是构建 chrome 扩展，但作为我们自己使用的一个附带项目工具，这绝对是一个有趣的项目。对于这个内容安全策略问题，我曾搁置了一段时间，以代替时间限制，但是后来一个用户发消息给我说，他能够使用消息传递来解决这个问题。我们很高兴其他人也发现我们的附带项目很有用，因为我们经常为我们自己的单页应用程序使用 APIRequest.io Capture Chrome 扩展和我们非常受欢迎的 Moesif CORS 扩展。

原文：https://www.moesif.com/blog/api-management/customer-success/You-Are-Measuring-API-Active-Users-Wrong/

API 提供者需要了解他们的消费者如何使用他们的 API。使用指标是必不可少的，因为它们告诉你 API 的采用情况，你的 API 如何随时间增长，以及哪些端点看到更多(或更少)的使用。当您查看 API 使用指标时，您应该从与您的服务最密切相关的角度来衡量 API 上的活跃用户。这将告知您的组织在哪里分配计算资源，您决定开发哪些 API 端点，以及您记录哪些 API 端点。

什么是活跃用户？乍一看，这似乎只是简单地跟踪使用一个端点的用户数量。但是 API 用户不能像网站用户一样被追踪。相反，你需要看看你的用户在你的产品环境中是如何访问你的 API 的。

API 上的活跃用户是什么样子的？一个活跃的 API 用户是任何一个经常调用你的 API 来获得真实结果的用户。这并不意味着他们必须不断地进行 API 调用才能被认为是活跃的。API 消费者调用 API 的频率取决于 API 的上下文。如果一个活跃的用户需要从您的 API 中获得价值，他可能每天都会进行多次 API 调用，或者如果他需要从您的 API 中获得的只是每周的数据处理，他可能只需要每周进行一次 API 调用。一种常见的做法是将 API 使用指标分为每日活跃用户和每月活跃用户，以便更清楚地了解用户在不同时间段的活跃程度。

虽然采取一刀切的方法来衡量活跃的 API 用户可能很有诱惑力，但是在决定衡量什么时，您需要考虑 API 的上下文。您的度量应该反映您的 API 如何在现实世界中为用户创造价值。例如，允许您发送 SMS 消息的 API 应该跟踪用户发送的 SMS 消息的数量。压缩视频的 API 会跟踪为每个用户压缩和发送的数据文件的大小。这些指标应该与所提供服务的价值直接相关。

坏度量，好度量

虽然 API 提供商通常通过跟踪独立用户的数量来衡量活跃用户，但这是一种虚荣的衡量标准，它让事情看起来很好，但并没有真正传达多少信息。由于独立用户的数量通常会随着时间的推移而增加，这很容易让人想到这样的指标，因为它可以向内部利益相关者讲述一个积极的故事。不幸的是，对活跃的独立用户进行简单的计数是一个糟糕的指标，因为它没有给出用户使用 API 做什么的详细信息。如果你是一家百货商店，这与计算橱窗购物者的数量没有太大区别。有趣的是，它没有告诉你有多少人来买东西，他们买了什么，或者他们花了多少钱。相应地，您想知道用户是否继续以有意义的方式使用您的 API，为您的 API 消费者创造了多少价值，以及哪些 API 端点和功能对您的用户最有价值。没有关于 API 消费者的有意义的信息，您的组织就不能决定在哪里应用新的开发或者如何分配资源。

随着用户群的增长，扩展 API 指标非常重要，但这一点经常被忽视。当您有少量的 API 消费者和少量的使用模式时，衡量活跃用户可能很简单。但是，随着 API 变得越来越复杂，准确测量有意义的用户活动变得越来越困难。您需要一个前瞻性的度量策略，随着您的 API 的发展而发展。这有一个额外的好处，那就是确保您的组织不会随着 API 的增长而抛弃老用户。像您的组织已经创建的 API 键的唯一数量，或者对您的 API 端点的调用总数这样的指标，并不总是指示它们最初测量的内容。例如，一个开发者可以创建多个 API 键。

让我们看看什么是好的度量标准。好的度量应该给你关于 API 消费者如何与 API 交互的有意义的信息。您的指标应该能够回答以下问题:

• 在您的 API 响应中传递了多少数据？都有用吗？
• 每个用户与您的 API 保持连接的时间有多长？
• 哪些端点最活跃？
• 用户在进行 API 调用时有多成功？

好的指标不仅仅告诉你有多少开发人员使用了你的 API。上面的问题是考察你的 API 消费者对你的 API 的参与程度的不同方式。如果你的 API 专注于在不同设备之间传输数据，那么传输的数据量是你的用户参与度的一个很好的指标。另一方面，如果您的 API 提供实时服务，比如视频内容的实时字幕，那么连接的长度将是一个更好的参与度指标。 了解更多 关于 Moesif 如何帮助您跟踪参与度指标的信息。

API 活跃用户，真的

好的度量标准的一个好的起点是将您的 API 调用聚合成有意义的事件，而不是查看 API 调用的原始数量，这可能是一个嘈杂的信号。事件可以是对 API 调用的更详细的观察，结合了 API 调用及其结果。

测量事件而不是 API 调用还允许您查看不同类型的事件之间的比较，包括它们的共同点。观察失败的事件可以揭示失败的共同根源。例如，如果您的用户因为太多的流量流向您的 API 端点而遇到失败的事件，您的组织可以通过向您的 API 分配更多的资源来处理这个问题。或者，与您的开发人员入职相关的失败事件的模式可能指向您的用户在开始使用您的 API 时遇到的麻烦。这可能意味着需要更全面的文档，或者您的用户可能需要额外的支持来集成您的 API。

让我们看一些 API 事件度量的真实例子。执行双因素验证的 API 至少有四个基本的 API 事件。成功发送验证短信将是第一个 API 事件，并伴随着一个发送短信失败事件。另外两个事件是当验证代码被成功验证时，以及当验证代码未被验证时。这些事件一起显示了 API 消费者成功使用 API 实现其目标(在本例中，验证电话号码)的频率。通过将 API 交互分成事件来区分成功和失败的 API 交互，可以很容易地理解 API 的实际活动。

最佳实践

虽然我们已经讨论了如何通过事件来衡量活跃的 API 用户，从而更好地告知您的 API 消费者如何使用您的 API，但是还有其他好处。例如，您可以使用您的活动 API 使用指标，直接根据您的服务为用户创造的价值来为用户计费。您的组织可以对成功的活动进行计费，从而将计费与实际结果直接联系起来。例如，打电话的 API 可以根据通话时间计费，发送短信的 API 可以根据发送的短信数量计费。

依赖活跃用户指标时，实时报告至关重要。当你的用户使用你的 API 时，通过测量他们可以获得很多有价值的见解。例如，您可以在用户遇到失败事件时立即发现它们，使您的团队能够实时解决失败问题。如果用户的问题得到及时的支持，他们就不太可能离开你的服务。实时分析还允许您的组织查看在给定时刻(例如在重负载期间)成功事件的数量与失败事件的数量的对比情况。借助实时事件指标，您的团队可以快速响应用户需求，监控失败事件，并了解哪些终端为用户提供了最大价值。 打造更好的 API 产品moes if 提供的深刻见解。

实时成功

衡量 API 用户的总数可能会产生误导，因为它没有提供关于 API 消费者如何从 API 中获得价值的上下文信息。将您的 API 调用批处理到事件中，将为您的组织提供大量 API 信息。您将能够评估失败的事件，以便您的组织能够了解哪个 API 端点需要更多的关注和资源。您还将能够比较成功事件的模式，以便您的组织能够了解哪些端点为您的 API 消费者创造了最大的价值。

要真正了解你的用户，把你的衡量标准集中在他们用你的 API 做什么，以及他们是否真正达到了他们想要的结果。您的度量标准应该关注为您的用户创造最大价值的 API 事件，以便您了解应该将资源集中在哪里。通过实时测量用户的活动来了解他们，给自己最好的机会来满足他们的需求。如果你一直以来对 API 活跃用户的衡量都是错误的，现在是时候重新考虑你的策略了。你的内部利益相关者和你的客户都会为此感谢你。

原文：https://www.moesif.com/blog/announcements/features/Your-guide-to-Moesifs-new-in-app-navigation-upgrade/

我们已经对 Moesif 的应用内体验进行了重新设计，这是一次重大的重新设计！作为我们为用户提供最佳体验之旅的一部分，我们简化了应用内导航。这一更新使得在 Moesif 中找到关键功能变得更加容易，并且有望让现有用户看到一些他们以前没有使用过但可能有用的功能。

正如所有大大小小的变化一样，可能会有一个学习曲线。这就是为什么我们制作了一个简短的指南来概述如何在 Moesif 中导航到所有您喜欢的功能。

TL；博士:我们增加了一个创建新按钮，允许用户轻松创建他们喜欢的图表、分析和工作流程。所有导航都是通过左侧导航菜单完成的。动态采样功能现在可以通过设置访问。Moesif 中的应用程序可以通过位于 Moesif 仪表板左上角的下拉菜单进行切换。

您可能会注意到的第一件事是，只需单击 Create New 按钮，即可创建新的仪表板、图表、警报和工作流。该按钮位于左侧导航的顶部。

单击该按钮时，您将看到许多不同的选项，可以轻松创建新的图表、分析和工作流。将鼠标悬停在每个选项上还会给出每个选项用途的简要描述。

选择这些选项中的任何一个都会将您带到所选选项的相应屏幕。当然，您仍然可以单独导航到屏幕并从那里创建，但这提供了一种快速开始新内容的简化方法。此功能支持一键访问 Moesif 最常用的所有功能。

如果您对我们的新设计有任何反馈，请告诉我们！

动态采样是一个节省成本的特性，它使您能够根据客户或 API 行为控制将哪些 API 调用记录到 Moesif。因为 Moesif 从不接收跳过的 API 调用，所以它们不计入您的订阅的事件配额。此外，Moesif 自动推断和标准化指标，因此即使不同的客户和行为有不同的采样率，您的报告也是准确的。

在 Moesif 中配置动态采样的入口已经移到设置菜单下。从这里，您可以访问动态采样以前为您提供的所有相同功能。

您还可以在设置菜单中找到我们新发布的隐私规则和自定义角色功能。隐私规则使得基于团队成员的角色编辑字段变得容易，并有助于保持敏感数据的私密性

Moesif 中的导航现在通过左侧边栏菜单完成。我们设计它是为了让 Moesif 的功能更容易访问和导航。您保存的所有内容现在也可以从左侧边栏访问。在这里，您可以找到已保存的仪表板、群组、警报规则以及您或您的团队在 Moesif 中创建的其他工作流。

下面包括一些关于某些功能现在的位置以及对它们的任何改进的描述:

仪表板能够在单个屏幕上为您提供多个视图或图表。这是一种可定制的方式，您可以在一个地方查看所有想要的数据。

因此，您可以更快地开始，您的 Moesif 帐户将有预建的仪表板，每个部门一个:

• 产品
• 客户成功
• 工程
• 安全性
• 销售
• 营销

这些包含了基于我们所看到的效果最好的指标。这可以为你提供一个很好的修改起点，或者你可以从一张白纸开始。

要访问 Moesif 中的仪表板，在左侧导航中，您可以在保存的仪表板菜单项下选择您想要查看的仪表板。默认情况下，Moesif 有一些预填充的仪表板，涵盖一些关键的业务领域，包括产品、客户成功、工程和其他一些领域。这些以及您创建的任何其他仪表板将列在保存的仪表板菜单项下。

要创建新的仪表板，只需点击保存的仪表板菜单项旁边的 + 按钮。

您还可以在菜单中移动已保存仪表板的顺序，并创建一个子仪表板。当您将鼠标悬停在保存的仪表板下的各个项目上时，这些选项就会出现。

我们还对单个工作区内的功能进行了一些改进。为了更好的可访问性和可读性，工作区的注释现在显示在右边。现在你可以很容易地创建和发布评论(包括给你团队中的其他 Moesif 用户添加标签的能力)。

然后保存评论供以后查看。

另一个改进是重新定位了恢复搜索按钮，这样你可以很容易地恢复你过去保存的搜索。

事件屏幕允许用户在应用许多不同的过滤器配置时可视化他们的数据。事件屏幕中的视图和图表包括实时事件日志、时间序列、分段、地理热图和智能差异。

创建图表和查看事件日志可以在事件屏幕中完成。要导航到该屏幕，您需要在左侧菜单中选择事件。

要在不同的图表和视图之间进行选择，如时间序列或实时事件日志，您需要从下拉列表中选择所需的图表，并在那里使用它。

Moesif 中的用户功能允许您深入分析用户。这使得 Moesif 用户能够对基于用户的指标进行排序和过滤。有了这些数据，你就可以深入挖掘用户漏斗、留存率和用户构成分析，从而描绘出你的企业和用户群的完整图景。

用户指标和工作流也可以通过左侧导航访问。在导航中，您会看到用户菜单项以及到您创建的每个用户群的链接。

在用户屏幕上，您可以通过屏幕左上角的下拉菜单导航至不同的功能和工作流程。在这里，您将导航到诸如漏斗、保持和构成等功能。

创建用户群组后，它将显示在左侧导航中用户标题下的用户群组折叠菜单下。

与 Moesif 中的用户功能类似，公司功能允许您执行相同的功能，但基于公司数据进行过滤和排序。

公司指标和工作流程也可通过左侧导航访问。在导航中，您会看到公司菜单项以及到您创建的每个公司群组的链接。

在公司屏幕上，您可以通过屏幕左上角的下拉菜单导航到不同的功能和工作流程。在这里，您将导航到诸如漏斗、保持和构成等功能。

创建公司群组后，它将显示在左侧导航中公司标题下的公司群组折叠菜单下。

警报规则使您能够监控 API 中影响客户的问题，并更加主动地确保良好的客户体验。您还可以利用警报来跟踪每个客户级别的指标。例如，您可能希望在新客户的流量大幅下降或平均延迟大幅上升时收到警报。警报可以发送到您选择的渠道，包括电子邮件、短信、寻呼机、Slack 或使用自定义的 WebHook。

警报屏幕也进行了优化，更易于导航。要进入警报屏幕，您可以在左侧导航的警报菜单项下找到它。在标题下方，您还会看到一个到警报历史屏幕的链接。

警报频道视图也被移至屏幕右侧，为左侧的新导航菜单让路。

Moesif 中的行为电子邮件功能允许用户在其应用程序中根据用户行为设置自动电子邮件。根据客户与您的应用程序的交互，发送速率限制警告、入职指导、集成错误等事件的警报，或您希望发送的任何类型的自定义电子邮件。

行为电子邮件现在也可以在左侧导航中找到。以前它们嵌套在警报&治理屏幕中。现在，它们更容易看到，也更容易接近。

嵌入式模板使用户能够将他们喜欢的事件日志和图表嵌入到他们的应用程序中。这允许客户查看这些指标，而不需要任何定制代码。

嵌入式模板也出现在主导航中，而不是像以前的 UI 那样嵌套在仪表板屏幕中。您仍然需要像过去一样，通过指标屏幕创建嵌入式模板。

一旦创建了嵌入式模板，就可以通过嵌入式模板屏幕查看它们。

API 治理使您能够限制对 API 的访问，或者基于 API 的历史使用模式添加自定义头。适当的 API 治理为良好的 API 安全程序奠定了基础。例如，Moesif 的治理规则可以阻止恶意抓取您的 API 或访问异常大量项目的用户的访问。

除了 API 安全性，您还可以利用治理来满足业务需求和连续性。例如，您可以创建一个规则来阻止具有过期发票的客户访问，或者在客户访问旧版本的 API 时添加折旧警告标题。

最后，治理规则现在也可以通过主导航轻松访问。以前，治理规则可以通过旧的警报和治理屏幕访问。现在，在新的左侧导航中，治理规则菜单项位于底部。

我们的最新更新现已上线，随时可以使用！只需登录 Moesif，体验我们对应用程序外观和感觉的最新改进。我们非常期待您亲自体验我们最新的 Moesif 版本！

到此这篇hprof文件生成原因（hprof文件怎么产生的）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rfx/77269.html