在采用基于使用的定价之前要问的问题
基于用法的定价（基于消费的价格）是一种流行的定价策略，尤其是以开发者为中心的初始启动。亚马逊AWS，Twilio和DataDog是此模型的三个伟大的例子。
基于用法的定价是流行的，因为这是双方的双赢：客户避免致力于大量购买可能或可能不起作用，而产品可以有快速的土地和真正的扩展。
如果基于使用的定价足够好，对于AWS，雪花和条纹，你也应该采用吗？这取决于。在这篇文章中，我分享了决定您是否应该使用基于使用的定价的框架。
此框架基于我的经验不成功地部署基于使用的使用基础的定价，以开发者为中心的公司。虽然该模型对分裂不起作用，但其学会应该对他人有价值。
基于用法的定价的重要部分是定价轴。良好的轴将具有以下属性：
____如果客户节流使用，它不应该反对公司的增长战略。
___轴应具有足够大的规模，优选成千上万的单位。
定价应始终与业务价值保持一致。换句话说，如果他们今天从昨天获得更多的利益，客户将乐意为您的产品支付更多费用。
选择用于基于使用的定价轴的定价轴时，请询问自己遇到产品增加的客户是否会反映在该轴上的增加的使用情况？
例如，让我们来看看每个主机的价格。如果客户将其基础架构占用脚印加倍，它会在监视每个主机进行性能时遇到DataDog的值。
或者，如果DataDog为每次监控事件和监控事件收取费用，而监控事件是双重的，而主机的数量保持不变 - 如果客户遇到两倍的价值，则不清楚。由于数据更新到DataDog代理或奇怪的流量模式，监视事件可能会增加一倍。
因此，DataDog对主机充电的是有道理的，而不是由事件充电。
开发人员通过API调用使用拆分，用于计算功能是否打开或关闭。由于API呼叫的增加反映了客户价值的增加，我由API调用充电。
但是，我的思想有一个缺陷。客户可以暂时缓存内存中API调用的结果，限制它们的拆分，而不会降低拆分值。这使得API调用拆分的错误使用轴。
让我们看看Twilio相反。客户可以节流他们在没有减少价值的情况下使用二折吗？不，如果他们希望他们的短信向客户提供，他们别无选择，只能使用Twilio。因此，Twilio可以通过短信充电。
通常，如果客户可以沿轴沿着轴的速度使用而不会降低值，则您没有基于良好的使用基于价值轴。
这是一项公理，无论您征税，它都不会以其习惯的速度增长。价格也是如此。
公司通常通过主要实体充电使用：DataDog的主机，MailChimp的联系人，或Confluent的Kafka消息。在拆分时，主要实体是一个特征标志或实验。
我认为分裂的一个想法是通过实验价格使用。这个想法的问题是，战略性地，我从不希望我的客户问：“这一功能值得落后于分裂吗？”我希望每个功能都落后于分裂，所以我可以培养每个工程师和产品经理以新的方式考虑产品开发;分裂方式。我不想征税实验的增长。
同样，Salesforce不收取机会，因为它符合Salesforce在Salesforce中追踪的每一个机会都有兴趣。 Salesforce不想税收机会增长。
因此，在选择使用定价轴时，请问自己对公司的长期战略更为重要，让轴比为其收费而生长。
基于用法的定价的好处是您可以将客户降低并观察它们随着时间的推移而增长。客户可以接受这种增长，只要他们可以预测增长率即可。最低限度，他们需要预测明年您的产品的使用和价格进行预算拟计目的。如果产品使用情况发生意外增加，您的买方将不得不在预算周期内多次回到金融队伍，因此您的买家会不满意。如果您的产品在买方预算中的前5项费用中，则需要可预测性更高的需求。
这种可预测性的需求也延长了销售周期。斯普利特的客户会尝试预测使用;但是，这是一个复杂的运动，需要多个利益相关者来模拟几个变量。这种摩擦伸长了销售周期，也导致了一些损失。
缺乏可预测性是我在分裂中远离基于使用的定价的主要原因。
相比之下，每成功卡充电条纹费用。如果他们想使用条纹，任何电子商务网站都可以预测其卡收费的增长，使其成为基于使用的使用的好轴
这是一个人的关注，但有些客户将估计每单位充电多少钱。如果您的定价轴使您只有几百单位，每单位的价格可能很大，这可能是一些客户的心理障碍。或者，它可以将帽子放在最多可以为您的产品收费。
基于用法的定价中最大的名称 - AWS，Snowflake和Twilio - 沿着大型轴线的所有充电。
工程是一个买方档案，非常适合基于使用的定价。但是，如果您销售到销售或金融队伍，则可能不习惯购买这种方式。虽然总有机会教育您的买家，但请问自己这是否是您愿意采取的风险。
基于用法的定价是一个梦幻般的土地和膨胀的司机。 完成后，它会减少销售周期，并让您在今天满足您的客户。 它还建立了未来增长的承诺。 但是，在采用此模型之前，请查看我提出的问题。 任何问题的“否”应该帮助您在致力于使用基于使用的定价之前更深入。 我相信我没有涵盖其他重要的考虑因素。 如果你觉得我错过了一些东西，请分享你的想法。