以前の記事「API の収益化: どうやって始めるのか？」では、API 収益化戦略を策定し、最小の製品構成で運用を開始する際の一般的な落とし穴を回避する方法を説明しました。この記事では、成長を促進し、顧客満足度を高める API 製品の収益化を実現する、技術的要素と API 収益化のベスト プラクティスに注目します。
API 収益化を成功に導くには、テクノロジ スタックを構築する際に以下の 4 つの重要な要素を考慮します。
1. スピード
選択肢があれば、API 利用者は遅い API ではなく、速い API を望みます。e コマースのエンドユーザー エクスペリエンスにかかわる API では、1 ミリ秒も無駄にできません。
IoT、ストリーミング、ゲーム、その他の時間的制約のあるアプリケーションにかかわる API も低レイテンシを必要とします。低速な API が好ましいとされる状況は考えにくいです。したがって、予測可能なパフォーマンスを念頭に置いて API を構築すると良いでしょう。
レイテンシは、スピードに関連するパフォーマンス指標の 1 つであり、スループットはスケールに関連するもう 1 つの指標です。したがって、スループットは API のスケーラビリティの関数です。キャッシングによりレイテンシとスループットを改善できますが、常に可能というわけではありません。
スケーラブルな API を計画することが理想です。スケーラブルでなくなった API については、エンドユーザーの予測可能性を確保するため、レート制限を使用する必要があります。
API を収益化する場合、高いレート制限や低いレイテンシによりサービス品質を向上することで、より高額なプランへのアップグレードを促し、顧客がユース ケースに適したパフォーマンス レベルを自己選択できるようなります。
たとえば、無償版の API にはスロットリング制限がありますが、ブロンズ、シルバー、ゴールド、プラチナ レベルではしきい値が高く設定されているか、しきい値がありません。
スケーラビリティはフォールト トレランスを招きます。複数の展開地域で API に対応できるようにすれば、問題が発生しても、ある地域から別の地域へフェイル オーバーさせることが可能です。
API がオフラインになると、その間の収益を失うだけでなく、ユーザーがサービスの信頼性を疑問視して代替手段を探すことで、将来の収益を失う可能性もあります。
場合によっては、地域間の互換性がない可能性があることに注意してください。たとえば、GDPR に準拠する必要がある EMEA の展開について考えてみます。この場合、米国に展開があったとしても、フェイル オーバーできない可能性があります。そのため、最低でも 4 つの展開が必要であり、互換性のある地域ごとに少なくとも 1 ペアの展開が必要です。
要するに、API にはユーザーが信頼できる SLA が必要です。
2. セキュリティ
製品化された API は、無償で有償のリソースにアクセスしようとする攻撃にさらされます。収益化された API も市場に出回る可能性が高く、注目されるため、より積極的なセキュリティ対策が必要です。
API 利用者は、送受信されるデータの保護について期待を持っています。情報セキュリティは広範で複雑なテーマですが、API に関しては、以下の重要な領域が検討に値します。詳しくは、https://konghq.com/webinars/success/Top-3-Strategies-to-Secure-and-Govern-Your-Microservices にあるウェビナーをご覧ください。
- 機密性と完全性: API を確実に暗号化し、必要に応じてペイロードを検証します。
- 認証と権限付与: 利用者を確実に識別し、利用者に権限が付与されている API とデータへのアクセスのみを許可します。
- 可用性: 有害事象を想定し、適切な緩和策を講じます。
API を取り巻く情報セキュリティに対する顧客の期待は常に高く、顧客がアクセスの対価を直接支払っている場合は、そのハードルはさらに高くなります。
API ベースの製品を迅速に採用し、セキュリティ レビューに費やす時間を最小限に抑えるには、API 利用者が購入する製品を信頼できるように、以下の原則を念頭に置いて一から設計します。
3. 可視性
優れた遠隔測定は、API を改善するための重要な要素です。新しい API の設計にも役立ちます。言い換えれば、「測定しないものを改善することはできません」。
そのため、API 製品マネージャーは、優れた API メトリックの構成要素を理解する必要があります。
それは、レイテンシ目標、利用率目標、スループット目標、コスト構造 (計算)、あるいはエンドユーザーの満足度かもしれません。収集すべき遠隔測定について、以下のような要素を含め考慮することが重要です。
- 利用パターン: スパイク、季節性、実行順序
- レイテンシのパターン
- エラー率
- 疑わしい利用パターン
- ユーザーによる利用上限超過の頻度
- (現場レベルの) 具体的なリクエストの性質
内部 API や収益化されていない API では、これらの要因を監視すれば十分ですが、API を収益化する場合、ビジネス価値のレポートを含む分析が必要になります。具体的には、以下のような機能を持つことがベスト プラクティスとされています。
- 顧客別の SLA パフォーマンス (最低でも成功率と応答時間) の報告
- API 製品バンドルまたは個別に収益化された API ごとに発生した収益の分析
- 上限に近づいている顧客にアラートを通知し、営業チームにアップセルの機会を提供
- フリーミアム API 製品からプレミアム API バンドルへのコンバージョン率の監視
- 新規に採用した顧客の API 利用状況を監視し、メトリックが問題を示した場合、カスタマー サクセス チームを早期に紹介
- 顧客の利用状況が急激に変化 (減少または増加) した場合、顧客の解約を予測したり、顧客が多額の請求を受け取る前に予期しない需要の急増を通知
収益化戦略を策定する際に重要なのは、従来は IT やエンジニアリングの役割であったものを、製品管理、マーケティング、営業の領域へ移行していることを忘れないことです。
これにより、従来の API 管理メトリックの能力が拡張されるため、プロセスの早い段階でビジネス価値レポートの要件を定義し、これらの領域すべてにわたって可視性を提供するプラットフォームを確実に選択することを推奨します。
4. 使用法
最後に、何が API の利便性を高め、収益化された API バンドルごとにターゲットとする顧客層に適した API とは何かについて見ていきましょう。
API を商品化する場合、最初に各商品のターゲット顧客を定義することが重要です。顧客を特定したら、その顧客層が解決しようとしている問題の詳しいユーザー ストーリーを文書化して、ユース ケースを満たし、顧客ができるだけ直感的に使用できるように各 API を設計する必要があります。
ターゲットとする顧客を考慮する際、まず見直すべきはユース ケースです。ターゲット顧客のユース ケースに合わせて API の粒度を設計することが重要です。細粒度の API は、非常に特殊で小さな機能を実行する場合に適していますが、大量の操作を行うには非効率的であるため、ターゲット顧客が何を求めているかを知ることは非常に重要です。
次に、API のプロトコルとペイロードは、目的に合わせて計画する必要があります。REST、gRPC、GraphQL、WebSocket、そして生の TCP には、それぞれのユース ケースがあります。優れた API 設計は、ターゲットとする API 利用者のニーズ、好み、ユース ケースを考慮しなければなりません (詳細は、こちらの記事を参照してください)。
最後に、API が実際に使用されるためには、よく文書化されている必要があります。優れた文書は、簡潔で包括的であり、理解しやすく、見つけやすく、例や一般的な質問に対する答えを提供します。この要件を満たす最も一般的かつ開発者フレンドリーな方法は、DevPortal を使用することです。
まとめ
以前の記事「API の収益化: どうやって始めるのか？」では、理想的な API 収益化戦略チームの選び方や最初の製品に関するアイデアの収集について説明しました。これらの戦略と、ここで紹介したテクノロジ スタックの構築方法を理解することで、成功のチャンスを最大化できます。
現在、API の収益化に取り組んでいますか? Kong と HyperCurrent は、成功する戦略の策定と実行を支援します。世界最速で抜群の採用実績を誇る API ゲートウェイ、Kong Gateway を確認して、API 収益化を成功させる基盤を確立しましょう。
Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。
参照記事: 2022 年 5 月 19 日
Ahmed Koshok
この記事は、API およびデータ収益化プラットフォーム HyperCurrent の CPO 兼共同設立者 Jason Cumberland 氏の協力を得て執筆されました。
© Kong Inc. 2022
「API monetization: Technical best practices」
