このページは Cloud Translation API によって翻訳されました。

商品カタログを管理する

このガイドでは、Google Play Developer API を使用してコンテンツを作成し、 Play アプリの商品カタログの管理。

Google Play の課金システムを通じてアプリ内でアイテムを販売するには、以下が必要です。販売したいすべての商品を含むカタログを設定します確認できますこの操作は Google Play Console から行えます。また、 Google Play Developer API を使用してカタログ管理を自動化する。自動化によりカタログを常に最新の状態に保ち手動での調整は現実的ではありません。このガイドでは、Play Developer API を使用して、Play アプリの商品カタログを作成、管理する方法について説明します。設定方法については、準備するガイドをご確認ください。バックエンド統合のために Google Play Developer API をセットアップします。

Catalog Management API

Google Play の課金システム、読み取りアプリ内アイテムのタイプとカタログに関する考慮事項を理解する。 Google は、Play のカタログ管理用に主に 2 つの API セットを提供しています。 2 つの主要商品カテゴリに対応しています

1 回限りのアイテム
定期購入商品

1 回限りのアイテム

inappproducts エンドポイントを使用すると、1 回限りのバックエンドから抽出できますこれには、作成、更新、削除が含まれます。価格と在庫状況の管理などのタスクが含まれます 1 回限りのアイテムの購入を処理する方法に応じて、消費型アイテム（何度でも購入できる）または永続アイテム利用資格（同じユーザーが 2 回付与することはできません）。どちらを使用するかは、 1 回限りのアイテムは消費可能である必要があります。

定期購入商品

monetization.subscriptions エンドポイントはサブスクリプションの管理に役立ちます。開発することもできますユーザーはダッシュボードの作成、更新、サブスクリプションの削除、地域別の在庫状況と価格の制御が可能です。 monetization.subscriptions エンドポイントに加えて、 monetization.subscriptions.basePlans、 monetization.subscriptions.basePlans.offers をそれぞれ管理定期購入基本プランと特典を提供します

バッチ方式

inappproducts と monetization.subscriptions エンドポイントには多数のバッチメソッドが用意されており、最大 100 個までのエンティティを同時に適用できます。

バッチ方式は、許容されるレイテンシを有効にして使用すると、スループットが高く、特に、大規模なカタログのデベロッパーで、調整に多くの手間がかかります

更新伝播レイテンシとスループットの比較

商品の作成または変更のリクエストが完了した後は、ネットワークやバックエンドが原因で、エンドユーザーがデバイスで処理の遅れが生じますデフォルトでは、プロダクトの変更リクエストはすべてレイテンシの影響を受けます。つまりバックエンドシステムを介して高速に伝播するように最適化されています。エンドユーザーのデバイスに反映できます。ただし 1 時間あたりの上限は変更リクエストの数に応じて最適化されます。多数の商品の作成や更新を行う必要がある場合（例: 初期の大規模なカタログ作成など）では、 latencyToleranceフィールドの設定 PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT。これにより、更新スループットが大幅に向上します。レイテンシに耐える更新エンドユーザーのデバイスに反映されるまでに最長で 24 時間かかります。

割り当ての構成

Play デベロッパーを使用する際に注意すべき割り当て上限がいくつかあります。商品カタログを管理するための API:

Google Play Developer API のクエリにはデフォルトの上限（200,000 件）があります。できます。この割り当て上限は、すべてのエンドポイントの使用量の集計に適用されます。カタログ管理 API が含まれます
商品変更のエンドポイントには、サービスごとに 7,200 クエリの上限も適用されます。できます。この上限は、1 回限りのアイテムと定期購入の両方に適用されます。作成、更新、有効化、有効化削除します。一括変更のメソッド呼び出しは、この割り当ての 1 つのクエリとしてカウントされます。含まれる個々のリクエストの数やレイテンシはできます。
レイテンシの影響を受けやすい変更についても、上限は 7,200 件です。。バッチメソッドの場合、ネストされた変更リクエストがすべて個別に使用できます。この割り当てでは、レイテンシの影響を受けやすいバッチ API を使用する割り当て 2 が枯渇することがあります。これは、他のケースでは、この割り当てと同じ時間になります

ここでは、VM インスタンスの割り当て使用量を理解するための具体例をいくつか示します。異なるリクエストがあります。

1 つのアイテムを取得する 1 つの get リクエストで、割り当て 1 の 1 トークンが消費され、割り当て 2 と割り当て 3 のトークンはありません（変更エンドポイントにのみ関連するため）。
最大 100 個のアイテムを取得する get バッチリクエストも、次のトークンを 1 個消費します。割り当て 1 と割り当て 2 と 3 のトークンは割り当てられません。
1 つのアイテムに対する 1 回の modification リクエストで、割り当て 1 の 1 トークンが消費されます、割り当て 2 の 1 トークン。レイテンシの影響を受けやすいリクエストの場合は、割り当て 3 のトークンを 1 つ消費します。割り当て C には割り当て 2 と同じ上限があるため、 1 回の変更だけを使用するユーザーには実質的な影響がないあります。
レイテンシが許容されるアイテム 100 個に対して modification バッチリクエストを送信すると、割り当て 1 のトークン、割り当て 2 のトークン 1 です。このように割り当てを設定すると、カタログを最新の状態に保つためのマージンがありますが、アルゴリズムがこの割り当てを超えると、追加の呼び出しごとにエラーが発生する可能性があります。
レイテンシの影響を受けやすいアイテム 100 個のバッチ modification リクエストが消費されます割り当て 1 を 1 トークン、割り当て 2 を 1 トークン、割り当て 3 を 100 トークンとします。

Catalog Management API の使用に関する推奨事項

これらのガイドラインに準拠することで、API の使用を最適化できます。スムーズで効率的なカタログ管理が可能になります

使用状況をモニタリングする

使用率の高いプロセスに注意する必要があります。たとえば、冒頭のカタログ管理エンドポイントが消費する可能性が高くなる割り当てが増えるため、初期カタログ全体が作成されるため、購入ステータス API などの他のエンドポイントの本番環境の使用状況を全体的な使用量上限に近づきます。割り当ての消費量をモニタリングして、リソースの API 割り当てを超過しています使用状況をモニタリングする方法はいくつかあります。たとえば Google Cloud APIs の割り当てダッシュボードを使用することも、他の社内または任意のサードパーティ製 API モニタリングツールを使用できます。

API 割り当て使用量を最適化する

レートの消費を最適化することを強く推奨し、 API エラー。これを効果的に実装するには、次のことをおすすめします。

適切なカタログ管理戦略を選択する。API の理解が深まったところでその目標を達成するために、アプリケーションに適した戦略を選択する必要がある効率的に行うことができます
変更を反映するために必要な最小限の通話のみを行う。
冗長または不要な変更呼び出しを API に送信しないでください。このバックエンドカタログに変更履歴を残す必要があるかもしれません。
商品修正の時間あたりの上限である 7,200 クエリを超えないようにします。。多数のプロダクトを作成する必要がある同期プロセスを構築する場合変更（たとえば、最初のカタログファイル、作成など）。これらのプロセスが 1 時間あたりの上限を超えると予想される場合は、必要に応じて待機を実装して、使用を安全なレベルまで減らします。次を検討する: バッチメソッドを実装し、より高いスループットを実現します
予防的にスケーリングに備える。アプリケーションの成長に伴い、 API とさまざまなエンドポイントの使用量をスケールアップできます。Google Play Developer API の割り当てに関するドキュメントをご覧ください。最大使用量に近づいたら割り当てを増やしてください。
負荷の高いプロセスを戦略的にスケジュールする。大量のカタログをスケジュール設定する迅速に再実行できるため、たとえば、使用率が高い場合には週の売り上げのピーク時にカタログ全体を同期します。

割り当てのエラー処理ロジックを追加する

カタログ管理ロジックをどれほど効率的に構築しても、想定外の割り当て上限に対しても復元性を確保できます。たとえば、1 日あたりの割り当てが統合の独立したモジュールで使用されるエンドポイントで共有されます。確認事項エラー処理に割り当てスロットリングエラーを含め、適切に待機します Google Play Developer API が呼び出されるたびにレスポンスが生成されます。呼び出しが失敗した場合は、次の内容を含む失敗のレスポンスが返されます。詳細情報を提供する HTTP レスポンスステータスコードと errors オブジェクトエラードメインとデバッグメッセージを確認できます。たとえば、1 日の上限を超えるとエラーや次のようになります。

{
  "code" : 403,
  "errors" : [ {
    "domain" : "usageLimits",
    "message" : "Daily Limit Exceeded. The quota will be reset at midnight Pacific Time (PT). You may monitor your quota usage and adjust limits in the API
  Console: https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxxx",
  "reason" : "dailyLimitExceeded",
  "extendedHelp" : "https://console.developers.google.com/apis/api/androidpublisher.googleapis.com/quotas?project=xxxxxx"
  } ],
}

カタログ管理の実装

デベロッパーは、Google Play Developer API のプロダクト公開エンドポイントを使用して次のことを行います。バックエンドと Google Play の間でカタログの同期を維持する必要がある。作成 Google Play カタログがバックエンドのカタログに合わせて常に最新の状態に保たれるようにするユーザーエクスペリエンスの向上に役立ちます。例:

利用可能なオファーのリスト全体を参照したり、特典と基本プランのタグを使用して、自身の利用資格と特典の表示に反映させるできます。
ユーザーが使用しているさまざまな価格や商品の詳細を確認できます一貫性を持たせることができます
新しい商品を処理すると、バックエンドで商品の詳細を確認できますレイテンシを増加させたり、失敗するリスクをユーザークリティカルなフローにおける Google Play Developer API の追加呼び出し。

注意が必要な制限事項と考慮事項がある Google Play で商品カタログを作成する際のポイントです。このコースでは、カタログの構成方法がわかったら同期方法を決定します

カタログ同期戦略

Google Play Developer API の公開エンドポイントを使用すると、カタログ全体を管理できます。場合によっては更新アプローチを使用します。つまり、大量の変更をまとめて同じプロセスで送信できます。各異なる設計上の選択が必要になります。各同期戦略は、あるユースケースに他のユースケースよりも適しているユースケースがあり、状況に応じて両方が必要になります場合によっては、たとえばプロダクトの緊急更新を処理する（価格の誤りを修正して可能な限り早く設定してください）。また、定期的なバックグラウンド同期を使用して、バックエンドと Play カタログは常に整合性が保たれます。一般的な使用例を確認するさまざまなカタログ管理を実装することが必要になる場合があります説明します。

ローカルカタログの変更に合わせて更新を送信するタイミング

理想的には、更新はバックエンドの変更があった直後に行うべきです。差異を最小限に抑えることができます

このタイプの更新は、次のような場合に適しています。

商品は常に最新の状態にしておく必要があります。
毎日、商品にいくつかの変更を加える必要があります。
すでに本番環境で販売されている商品を更新する必要があります。

この方法は実装が簡単で、カタログを同期した状態を維持できます。最小単位とラベル値で示されます

定期的な更新を使用するタイミング

定期的な更新は、バックエンドのプロダクトエディションに対して非同期で実行されます。次のような場合に適しています

商品を短期間で更新する必要はありません。
一括更新または調整プロセスを計画する必要がある。
コンテンツ管理またはカタログ管理システムを使用してカタログを絶えず更新することで

カタログが大きい場合は、レイテンシを許容できるバッチ方式の使用を検討する更新する必要があります。

注: ただし、Google Play の商品カタログのアップデートは、その場合でも、変更が直ちに適用されるとは限りません。利用できるようにします処理にレイテンシが生じる可能性がまだあるネットワークやバックエンドの処理遅延によるエラーの解決に役立ちます同様に、定期的な更新はある程度遅れて実行されますが、カタログを更新するように設計することもできます。同様の機能を持つユーザーが変更を使用できるようにします。レイテンシを短縮できますまた、latencyTolerance フィールドは、バッチ方式では、更新の高速伝播を最適化するか、スループットが向上します結局のところ、これら 2 つのオプションのどちらを選ぶかは、

商品カタログを作成する

Google Play にアップロードするカタログが大きい場合は、初期読み込みが行われます。この種の負荷の高いプロセスは、定期的な戦略でレイテンシが許容されるバッチ方式との組み合わせです。

1 回限りのアイテムを作成する

1 回限りの商品の大規模なカタログを初めて作成する場合は、 allowMissing フィールドが以下に設定された inappproducts.batchUpdate メソッド true と latencyTolerance フィールドを次の値に設定: PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT。これにより、割り当て制限内でカタログの作成にかかる時間が最小限に抑えられます。

カタログのサイズが小さい場合は、inapp_products.insert メソッドを使用します。または、inappproducts.update メソッドを「サービスの更新情報」セクションに記載されている allowMissing パラメータを使用します。この方法の利点は、スクリプトの作成、更新、ステートフルなサービスであり、問題が発生した場合にはゼロから再起動できます。

定期購入商品を作成する

定期購入用の大規模なカタログを初めて作成する場合は、 monetization.subscriptions.batchUpdate メソッド allowMissing フィールドを true に設定し、latencyTolerance フィールドを設定 PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT へ。これにより、割り当て制限内でカタログの作成にかかる時間が最小限に抑えられます。

小規模な定期購入カタログの場合、Play Developer API は monetization.subscriptions.create メソッドを使用します。または、サービスアカウントキーを使用して monetization.subscriptions.update メソッド「サービスの更新情報」セクションに記載されている allowMissing パラメータを使用します。

前述のすべてのメソッドで、基本プランとともに定期購入が作成されます Subscription オブジェクト内で指定します。これらの基本プランは当初は非アクティブです。基本プランを管理するにはステータスを確認するには、 monetization.subscriptions.basePlans エンドポイント（有効化を含む）基本プランを購入できるようにする必要があります。また、monetization.subscriptions.basePlans.offers エンドポイントでは、オファーを作成、管理できます。

サービスの更新情報

以下の方法を使用すると、既存の商品を効率的に変更できます。提案内容が最新の調整内容と一致していることを確認します。

1 回限りのアイテムを更新する

既存の 1 回限りのアイテムを更新するには、次の 3 つの方法があります。

inappproducts.patch : パッチエンドポイントは、リソースを部分的に更新するために使用されます。つまり、リクエスト本文で指定した特定のフィールドを更新できます。パッチエンドポイントは、通常、データセットのいくつかのフィールドを更新するだけでリソースです。
inappproducts.update : 更新エンドポイントは、リソース全体を更新するために使用されます。つまりリクエスト本文でリソースオブジェクト全体を送信する必要があります。「更新エンドポイントは、通常、データセットのすべてのフィールドを更新する必要があるときにリソースです。allowMissing パラメータが true に設定され、指定された商品 ID が存在しない場合は、エンドポイントによって商品が挿入されます。重要な役割を果たします
inappproducts.batchUpdate : これは更新エンドポイントのバッチバージョンです。このエンドポイントを複数の商品をまとめて処理できます「latencyTolerance」フィールドを設定しました PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANT スループットが向上します

定期購入商品を更新する

既存の定期購入を更新するには、 monetization.subscriptions.patch メソッドを使用します。この方法はは、次の必須パラメータを受け取ります。

packageName: サブスクリプションが属するアプリのパッケージ名。
productId: 定期購入の一意のプロダクト ID。
regionsVersion: リージョン構成バージョン。

allowMissing パラメータを使用して新しいサブスクリプションを作成する場合を除きます。 updateMask パラメータを指定する必要があります。このパラメータは、更新するフィールドのカンマ区切りのリストです。

たとえば、定期購入商品のリスティングのみを更新したい場合、 updateMask パラメータに listings フィールドを指定します。

monetization.subscriptions.batchUpdate を使用すると、複数の定期購入を同時に更新できます。 latencyTolerance フィールドを次のように設定して使用します。 PRODUCT_UPDATE_LATENCY_TOLERANCE_LATENCY_TOLERANTでスループットが向上します

基本プランの有効化、無効化、削除、最新の基本プランの価格バージョンは、monetization.subscriptions.basePlans エンドポイントを使用します。

また、基本プランの価格をP-MAX では monetization.subscriptions.basePlans.offers.patch メソッドを呼び出します。

カタログの調整

バックエンドが更新されるたびに Google Play カタログを更新するかどうかカタログ管理システムや Cloud Identity を使用している場合は、 Google Play のカタログに含まれていないデータベースを使用している場合でもアプリが Play のアプリ設定のカタログと同期されていない状態です。これは、コンソールでの緊急の手動によるカタログ変更、サービス停止が原因である可能性があります。カタログ管理システムへのアップロードや最新データが失われた場合などです

カタログの調整プロセスを構築して、不一致の長期化を防ぐクリックします。

差分システムの考慮事項

不一致を検出して修正する差分システムを構築することをおすすめします。あります。差分のシステムを構築する際に考慮すべき点がいくつかあります。同期中のカタログ:

データモデルを理解する: 最初のステップは、データを理解することです。開発 CMS と Google Play Developer API です。例各システムに保存されている各種のデータについて異なるデータ要素が互いにマッピングされます。
差分ルールを定義する: データモデルを理解したら、次のことを行う必要があります。差分ルールを定義します。これらのルールによって、2 つのグループ内のデータがどのように比較されます。たとえば、2 つの SKU で商品 ID とサブスクリプションの主な属性とそれに関連する基本プランを比較する提供します
差分アルゴリズムを実装する: 差分ルールを定義したら、差分アルゴリズムを実装する必要がありますこのアルゴリズムは定義したルールに従って比較します。特典をカタログデータをダウンロードする場合は inappproducts.list inappproducts.batchGet, monetization.subscriptions.list および monetization.subscriptions.batchGet メソッドを使用します。
差分レポートを生成する: 差分アルゴリズムによって差分レポートが生成されます。このレポートでは、両方のシステムの違いを確認できます。
差異の調整: 差分レポートを生成すると、差異を解消できますCMS でのデータの更新や、 Developer API を使用して Google Play 側でデータを更新する場合もあります。カタログ管理エンドポイントへのデプロイも行います。これは、カタログです同期されていない商品を調整するには、 [サービスに関する更新情報] セクションに表示されます。

プロダクトのサポート終了

Google Play Developer API には、デベロッパーをプロダクトのサポート終了: inappproducts.delete、 inappproducts.batchDelete 1 回限りのアイテムや monetization.subscriptions.delete サポートしていますさまざまな状況でサービスのサポート終了が必要になる場合があるします。以下に例を示します。

誤って作成された。
機能またはサービスの提供を終了する。

商品のサポート終了をカタログ管理に組み込むことをおすすめします説明します。

1 回限りのアイテムのサポートを終了する

Google Play Developer API で 1 回限りのアイテムを削除するには、以下を使用する必要があります。 inappproducts.delete または inappproducts.batchDelete メソッドを呼び出します。

定期購入商品のサポート終了

サブスクリプションを削除するには、 monetization.subscriptions.delete メソッドを呼び出します。基本プランを 1 つ以上設定すると、定期購入は削除できませんアクティブになりました。