アプリでデジタル商品を販売する場合は、ユーザー エクスペリエンス全体に配慮する必要があります。アプリ内統合を使用すると、購入フローを開始して、ユーザー エクスペリエンスを管理できますが、ユーザーが購入している利用資格についてバックエンドで最新のステータスに保つことが重要となります。購入のトラッキングと、クロス プラットフォームでの利用資格など、ユーザー エクスペリエンスの別の側面の管理において、これは重要です。
購入ライフサイクル イベントをモニタリングし、ユーザーの利用資格の変更に迅速に対応するには、定期購入と 1 回だけの購入の両方について、購入ステータス管理システムをバックエンドに構築する必要があります。このシステムにより、デバイスのステータスに関係なく、迅速かつ安全に購入を処理でき、すべてのプラットフォームにおいて一貫性のあるユーザー利用資格を保持でき、バックエンドの購入履歴と利用資格データをコンサルトできるようになります。
Google Play には購入ライフサイクル イベントをモニタリングするリアルタイム デベロッパー通知（RTDN）が用意されています。また、定期購入とアプリ内購入用の Play Developer API を使用すると、このようなイベントに基づいて必要なアクションを実行できます。これらのツールを使用して強固な購入ライフサイクル管理システムを構築することにより、シームレスなユーザー エクスペリエンスを提供でき、購入と利用資格を効率的に管理できます。
リアルタイム デベロッパー通知クライアントを構築する
Google Play の課金システムで実行された購入は、そのライフサイクル全体を通して複数回にわたり利用資格の変更が行われる場合があります。このような変更をトリガーするアクションはさまざまで、次のようなものがあります。
- アプリ内でユーザーが行うアクション。
- Google Play ストア アプリからユーザーが行うアクション。
- バックエンド システムから直接行われるアクション。
- Google Play Console から自分が行うアクション。
次に例を示します。
- ユーザーが Google Play ストアの定期購入センターで定期購入を解約する。
- デベロッパーが Google Play Developer API を使用して定期購入の請求を延長する。
- デベロッパーが Google Play Console から購入の払い戻しと利用資格の取り消しを行う。
バックエンドで、購入がたどる可能性のあるさまざまなステータスを認識し、それに応じてタイムリーに利用資格を調整するために必要な処理を行うことが重要です。
Google Play Developer API を使用して手動で購入ステータスを確認することは可能ですが、定期的なチェックに依存することは、変更のトラッキング方法としては非常に非効率であり、エラーと遅延が発生しやすくなります。RTDN を使用すると、Google Play での購入のライフサイクル トラッキング ロジックを構築することなく、すぐに変更に対応できます。
このセクションでは、RTDN のクライアントを構築する方法について説明します。RTDN は Google Cloud Pub/Sub を使用して構築された機能で、ユーザーの利用資格のステータスが変更されると、バックエンドにインスタント通知を送信します。Pub/Sub システムは通知を送信するパブリッシャーと、その通知を受信するクライアントで構成されます。RTDN を実装すると、ユーザーの利用資格のステータスに対するすべての変更をリアルタイムでトラッキングして、迅速に対応できます。
RTDN パブリッシャー
Google Play のバックエンドは RTDN パブリッシャーとして機能します。アプリに RTDN をセットアップするには、準備するガイドの手順に沿って行います。この手順により、Google Play の課金システムがアプリの RTDN パブリッシャーとして機能できるようになります。このセットアップを完了するには、Google Cloud Platform Console をよく理解したうえで、基本的な Pub/Sub 構成を設定する必要があります。
RTDN サブスクライバー
パブリッシャーをセットアップ後に、RTDN に対応できるようバックエンドを準備する必要があります。そのために、Google Cloud Pub/Sub メッセージを受信するクライアントを構築する必要があります。RTDN クライアントの基本機能は、登録されたエンドポイントでの HTTPS リクエスト経由、または Cloud Pub/Sub クライアント ライブラリを使って、PubSubMessage のインスタンスを受信することです。Pub/Sub のドキュメントで、push または pull 戦略についての詳細、RTDN 設定に関するドキュメントで、ニーズに合った最適な戦略を選択するためのガイドラインをご確認ください。
受信したメッセージごとに、バックエンドは次のことを行う必要があります。
- RTDN オブジェクトを含む、base-64 でエンコードされた
dataフィールドを展開する。 - RTDN イベントが通知した利用資格の変更に関連して必要とされるバックエンド プロセスをトリガーする。
購入ステータスの遷移を処理する
1 回だけの購入と定期購入は、影響を及ぼす可能性があるさまざまなステータスとイベントにより、ライフサイクルが異なります。RTDN を使用すると、ステータス遷移を確認するロジックを構築する必要がなくなります。バックエンドがそれぞれの通知を受信したときに実行することを定義するだけで済みます。
この 2 つのシナリオについて詳細は、次のガイドをご覧ください。