使用這些基本 REST API 最佳實踐構建出色的 API
一旦您的客戶已經支付了自助服務計劃并滿足某些使用標準，您的銷售團隊就可以參與其中。由于客戶已經看到了 API 的初始價值，銷售團隊采取了咨詢方式，使討論更像是“追加銷售”討論。銷售人員指導客戶如何從 API 中獲得更多價值或滿足客戶可能擁有的某些業務需求。客戶可能會因為使用量增加、新用例或有高級要求而考慮升級。
這意味著您的銷售團隊應該了解客戶的使用情況，以確定何時讓客戶參與銷售流程。為此，您應該設置一個 API 分析工具，該工具可以通過以下方式跟蹤每個客戶的 API 使用情況基于賬戶的儀表板。這為銷售和客戶成功提供了了解每個客戶和試點使用情況的單一窗口。建議在客戶的使用趨勢發生變化時設置自動通知，例如通過 Slack。例如，當一個帳戶的 API 使用量每周增加超過 10% 時，他們可能已經準備好進行銷售討論。其他指標包括邀請其他團隊成員訂閱或使用他們以前沒有使用過的其他 API。
對于基于使用量的定價，選擇正確的收費標準和計費方式非常重要，這樣才能與獲得的業務價值相關聯。簡單地對每個 API 調用收費可能不是一個好選擇，因為有些 API 沒有任何價值（例如狀態探測），它們可能會出錯、不返回結果等。同樣，您可以同時提供批處理和非批處理 API。如果您正在構建 SMS API 產品，那么單個 API 調用會批量發送 100 條 SMS 消息，然后轉錄它們，從而為客戶創造比僅發送一條 SMS 消息的 API 調用更大的價值。在這種情況下，基于發送的 SMS 數量計費將是一個比基于 API 調用次數計費更好的指標。
再舉個例子，假設您的 API 負責發送營銷電子郵件，但也提供在平臺中存儲電子郵件模板的功能。如果您根據存儲的模板數量計費，這可能是一個糟糕的指標，因為客戶不太可能僅僅通過在工具中存儲額外的模板就獲得價值。如果客戶起草了大量的電子郵件模板，但從未通過 API 發送過一封電子郵件，他們的賬單仍然會很高。另一方面，客戶會做出奇怪的行為，比如在發送舊電子郵件模板后不斷刪除它，盡管將電子郵件模板保留在工具中會更好。在這種情況下，客戶通過自動化發送營銷電子郵件的過程獲得價值。因此，與客戶價值相一致的更好指標是每月發送電子郵件的唯一聯系人數量或每月發送的電子郵件數量。
| 姓名 | 例子 | 何時使用 | 示例公司 |
|---|---|---|---|
| 交易量 | 采集的事件數、發送的消息數 | API 和基于事件的平臺，例如 SMS 和分析 | 辛奇 |
| 收入/成本份額 | 收入百分比，交易費 | 專注于支付或費用報告等資金的平臺 | 條紋 |
| 數據量 | 發送千兆字節，創建分鐘數 | 專注于日志記錄或存儲等數據的平臺 | 數據狗 |
| 以用戶為中心 | 每月活躍的獨立用戶數 | 按座位或按用戶收費的現代版本 | 部分 |
| 資源 | 計算單元、活躍小時數 | 計算基礎設施，例如數據庫或虛擬機 | AWS Redshift |
即使您能夠讓開發人員使用 API，這也不一定意味著 API 能夠創造商業價值。開發人員采用 API 可能只是為了嘗試新技術、創建業余項目、學習新技能等。然而，企業并不關心簡單的“Hello World”API。相反，企業購買 API 是因為他們認為它能為組織增加價值。就商業價值而言，有三種類型：
如果您要出售 API，則可以根據業務目標采用多種方式打包 API。由于 API 具有交易性質，因此許多 API 都采用基于使用量的計費模式（也稱為按用量付費或基于消費的計費）來促進收入增長，但您可以采用多種不同的方法。您在定價策略中應考慮的方面包括：
計費策略對采用和客戶激活影響最大，通常由產品部門推動。預付費計費是指客戶在使用服務之前預先支付服務費用。另一方面，后付費計費是指客戶在使用服務后付款。
預付費是一種常見的計費模式，尤其適用于傳統的 SaaS 和企業軟件公司。由于 API 提供商在提供任何服務之前都會預先獲得現金，因此預付費模式可以大幅增加企業的現金流，因為您可以讓客戶承諾并幫助資助您的研發。如果您的收購或設置成本很高，這一點尤其重要，因為這樣您就可以進一步投資于產品和增長。預付費對客戶也有好處，因為他們知道自己預先承諾了什么，這可以提供更多的支出可預測性。由于在付款之前使用量是未知的，因此您可以通過承諾的支出來處理基于使用量的計費。這可能包括批量折扣。但是，預付費可能會迫使客戶在獲得真實數據之前進行數學估算。
另一方面，后付費是指在客戶使用您的平臺期間，您向他們提供信用額度，直到他們付款為止。后付費可以減少入職摩擦，因為客戶不需要估計他們需要多少錢。相反，他們只需輸入信用卡，稍后處理賬單，看看損失有多大（比如在餐廳或酒吧用餐）。后付費計費已在基于消費的模式（如數字廣告行業，以及最近的云行業）中流行起來。后付費的一個好處是，客戶無需提前承諾即可看到任何價值。
然而，這也有缺點。由于您提供信用額度，因此客戶可能會根據您提供的服務濫用信用額度（例如，吃完飯就走的情況）。制定良好的保障措施和限額對于確保客戶在購買前不會積累“過多信用額度”非常重要。后付費的取消率也可能更高。客戶可能會使用比預期更多的昂貴服務，然后后悔莫及。
| 預付費賬單 | 后付費賬單 | |
|---|---|---|
| 描述 | 客戶提前購買積分/配額，然后稍后使用 | 客戶只需在用完后付費 |
| 優點 | 更好的現金流更熟悉傳統合同 | 減少入職摩擦讓現收現付 (PAYG) 更加簡單 |
| 缺點 | 入職過程中的摩擦PAYG 更加困難 | 額外信用風險可能被濫用 |
包裝策略對初始合同價值和擴展收入的影響最大。由于并非每個客戶都會獲得相同的價值并支付相同的金額，因此包裝是指向客戶呈現不同 SKU 和產品的方式。您可以使用不同的功能或使用組件來實現客戶細分。
分級定價是 SaaS 中常見的一種打包技術，用于創建“好”、“更好”和“最佳”計劃，每個計劃都有一組預定義的功能和配額。按用量付費 (PAYG) 是另一種打包技術，也稱為基于使用量的定價或基于消費的定價，其中客戶購買一定數量或容量，例如 API 交易的數量。PAYG 可以成為開發人員優先或產品優先組織的收入加速器。
傳統的分級定價讓客戶更容易了解成本，并使定價更具可預測性，這對購買軟件的大公司來說是一個優勢。它在 SaaS 行業中很常見且廣為人知，減少了計費的復雜性。此外，它非常容易實施。您不需要任何計量或分析來跟蹤使用情況。您只需實施訂閱計費軟件即可。
分級定價的問題在于價格與感知價值之間的脫節。當客戶接近其計劃的限制時，他們自然應該升級計劃。但是，升級到下一個計劃的價格可能會大幅上漲，這可能會導致客戶“感覺還沒準備好”升級到下一個計劃。如果分級使用太多變量，這種情況可能會被夸大。客戶超出計劃的所有限制而只超出一個配額限制的情況并不常見。但是，下一個計劃有“太多額外項目”，客戶不需要（例如附加功能）。同樣，您也不希望有超過三到四個計劃。如果計劃太多，會導致分析癱瘓
由于分級定價存在這些問題，人們開始采用一種更現代的方法，即客戶按使用量付費。消費者已經使用物理計量計劃很長時間了，比如天然氣和電力公用事業。這種計量概念可以應用于具有基于使用量組件的數字產品。常見的計量指標包括交易量、發送的千兆字節數或唯一用戶數。
基于使用量的定價的一個好處是，由于客戶只需支付他們需要的費用，因此價格與感知價值之間的差距會大大縮小。PAYG 是產品主導型增長或以開發人員為先的企業的絕佳催化劑。您可以設計一個“吸引客戶”的自助服務計劃，然后允許他們隨著時間的推移增加使用量。換句話說，您的定價模型具有內置的擴展收入。但是，如果不知道客戶使用水平的情況，PAYG 可能會很有挑戰性。
| 分層 | 隨用隨付 (PAYG) | |
|---|---|---|
| 描述 | 具有預定義功能集和配額的傳統 SaaS 層。 | 根據單價基于使用情況或消費量的定價。 |
| 優點 | 強制最低消費可預測客戶易于實施 | 為客戶提高效率膨脹時摩擦更小可以“看起來”更便宜 |
| 缺點 | 膨脹摩擦僵化，不符合價值觀 | 賬單意外而導致客戶不滿實施起來很復雜 |
開票策略會影響現金流，通常由財務團隊主導。一旦您決定了計費模式和產品包裝方式，您就需要確定何時觸發和生成發票。與對產品和擴展收入有影響的計費和包裝不同，開票策略對單位經濟的影響更大。使用定期開票，您可以按計劃（例如每月或每年）向客戶開具發票。另一方面，您也可以在客戶達到閾值（例如當他們達到一定配額或未付支出時）時向客戶開具發票。這種類型的開票稱為基于閾值的開票。
定期開票是兩種方式中更受歡迎的一種，客戶也容易理解。您可以以預付費方式（通常是固定價格）向他們開具發票，也可以向他們發送上一個結算期客戶使用情況的賬單。對于企業軟件的購買者來說，定期開票通常是首選，因為它是可預測的，也更容易規劃。有幾個缺點，通常與極端的按用量付費模式有關。如果你有一些客戶，他們的交易量非常小，他們每月只支付幾美分或幾美元，那么交易費將超過服務成本。同樣，如果客戶可以在一個結算期內快速積累大量信用，或者收到的價值非常具有交易性，這可能會在結算期之間產生大量的應收賬款余額，即使服務已經提供。這在數字廣告行業很常見，因為大筆支出可以迅速積累。
為了應對重復開票帶來的不良單位經濟效益，可以利用基于閾值的開票。使用基于閾值的開票，只有在達到某個閾值時才會生成發票。如果是預付費，這意味著客戶正在購買可以使用的信用額度（可能在很遠的將來）。如果是后付費，則在達到某個閾值（例如 1,000 美元的廣告支出）后生成發票。這可確保您每次最多只為客戶支付 1,000 美元，無論他們每月的支出是多少。基于閾值的定價并非沒有缺點。由于支出不可預測，并且與季度或年度等結算期不完全一致，因此它可能使會計工作變得非常復雜。時間可能是開放的，沒有明確的定義。
| 再次發生的 | 臨界點 | |
|---|---|---|
| 描述 | 客戶按月、季度或年度等計劃開具發票 | 僅當達到信用額度后才向客戶開具發票（也可以預付） |
| 優點 | 更容易實現收入確認/GAAP更加可預測 | 降低交易成本讓預付費更加簡單 |
| 缺點 | 低成本 SaaS 的單位經濟效益不佳如果預付費則很復雜 | 財務部門更難確認收入公司責任 |
實施基于使用量的計費會比典型的分級定價帶來更多復雜性。您需要一種準確的機制來以可靠的方式計量客戶使用量，并大規模地進行計量。使用量必須可審計，并且可以依靠它來解決爭議。與日志記錄或監控工具不同，這些數據必須準確。您不希望出現這樣的情況：您認為客戶使用了 X，但他們有證據表明并非如此。
您可以在 Snowflake 等平臺上構建自己的數據倉庫，也可以使用專門為 API 構建的基于使用情況的計費產品，例如莫伊西夫。此解決方案連接到您選擇的 API 網關（如 Kong 或 Tyk），然后將其與 Stripe 等計費提供商集成，以便 yiy 可以輕松設置計量規則。有關如何使用 Kong 和 Stripe 執行此操作的詳細教程，請查看使用 Kong、Stripe 和 Moesif 實現端到端 API 貨幣化。示例項目也可在GitHub
除了實施數據管道來處理基于使用量的定價之外，在管理客戶期望方面還存在許多其他挑戰。一個常見的問題是，客戶使用量比預期的要快得多，從而產生了一筆他們沒有預料到的巨額賬單。在具有數據量組件的 API 和工具中，這種情況尤其如此。
重要的是要聯系客戶，讓他們了解這一點。實現這一點的一種方法是通過電子郵件自動發送提醒，一旦達到某些預定義的閾值，就會提醒客戶他們的用量。在這種情況下，即使配額不是硬性限制，你也會讓客戶知道他們當月使用了多少。
讓客戶控制這些閾值也很有幫助。沒有人愿意每月收到 10 封有關使用情況的電子郵件，即使這是可預測的賬單。為客戶提供調整這些閾值的 UI 有助于確保他們只在需要時收到警報。
