ホワイトラベル デベロッパー向けのベスト プラクティス

ホワイトラベル アプリのデベロッパー(サードパーティ クライアント向けにテンプレートベースのアプリを制作しているデベロッパー)は、このベスト プラクティス ガイドを使用することで Google Play での公開プロセスを効率化できます。このガイドでは、以下の 4 点に絞って解説します。

  • アカウント管理: アカウントの構造について説明し、2 種類のアカウント管理モデルの違いや利点について解説します。
  • ストアでの表示の質を高める: ストアの掲載情報は、アプリごとに固有のものを作成する必要があります。ポリシーに準拠して、ユーザーにわかりやすい魅力的な掲載情報を作成するためのヒントを紹介します。
  • ポリシーへの準拠: アカウントの強制停止や閉鎖を防ぐため、ポリシーを理解して準拠するためのヒントを紹介します。
  • アプリの審査と公開: 審査プロセスをスムーズに進める方法、リリースを効果的に管理する方法について説明します。

アカウント管理

ホワイトラベル アプリのデベロッパーは、2 種類のアカウント管理モデルのどちらを使用するかを選択できますが、アカウント分散管理モデルを使用することを強く推奨します。

管理モデル アカウント分散管理(推奨)

アカウント一元管理

説明

クライアントごと(またはクライアント グループごと)に別々のデベロッパー アカウントを割り当てます。アプリ アップデートとコンテンツの管理は、基本的にクライアント自身が行います。この管理モデルには、以下の 2 つのサブモデルがあります。

  • 管理対象外アカウント: クライアント自身が、アカウントを管理するための完全な権限と責任を保持します。
  • 管理対象アカウント: ホワイトラベル デベロッパーが、クライアントのアカウントを管理するための管理者権限を保持します。このサブモデルは、たとえばクライアントが個別のデベロッパー アカウントを必要としているものの、技術的な保守作業を一定程度ホワイトラベル デベロッパーに任せたいと考えている場合に選択します。
すべてのアプリを 1 つのデベロッパー アカウントで管理できます。アプリ アップデートとコンテンツの管理は、すべてホワイトラベル アプリ デベロッパーが担います。
利点

管理対象外: このサブモデルは、クライアントが自身でアプリを保守する場合に適しています。

管理対象: このサブモデルは、規制要件への準拠が求められる場合(たとえば金融機関)に適しています。

アカウント分散管理モデルであれば、管理対象と管理対象外のどちらを選択してもホワイトラベル デベロッパーからリスクを分離でき、クライアント固有のデベロッパー名を使用して完全に独立したブランディングを展開できます。

Google としては、アカウント一元管理モデルではなく、アカウント分散管理モデルを使用することを強く推奨します。アカウント一元管理モデルは、単一のデベロッパー アカウントでアプリ アップデートを管理できるため一見シンプルですが、いずれか 1 つのアプリでポリシーの問題が発生したとき、同じアカウント内のすべてのアプリに影響が及ぶ可能性があります。アカウント内のすべてのアプリに影響するような重大な問題が発生した場合は、アカウントの強制停止や閉鎖につながる恐れもあります。
考慮事項 クライアントがポリシーを理解して準拠できるようにするため、緊密なコミュニケーションと強力なサポートが必要となります。

アプリの保守に積極的に関与する必要があり、これがボトルネックとなる可能性があります。1 つのアプリでポリシー違反が発生した場合、同じアカウントのすべてのアプリに影響が及ぶ可能性があります。

また、アカウント一元管理モデルの場合、Google Play に表示されるデベロッパー アカウント情報はすべてのアプリで共通となります。クライアントの希望によりホワイトラベル デベロッパーのブランディングを完全に排除する必要がある場合は、アカウント分散管理モデルを選択することを推奨します。

概要

ホワイトラベル アプリのデベロッパーにアカウント分散管理モデルを推奨する理由は以下のとおりです。

  • クライアントが自身でアプリを管理し、独自のデベロッパー名でアプリを公開できる。
  • 潜在的なポリシー違反の影響を隔離できる。
  • クライアントに包括的なガイダンスとサポートを提供できる。

ホワイトラベル アプリのデベロッパーには、アカウント分散管理アプローチを選択することを強く推奨します。アカウント一元管理モデルは、以下の理由からごく限られた状況においてのみ選択することをおすすめします。

複数の組織(または個人)の複数のアプリを 1 つのアカウントで管理することには特有のリスクがある。
1 つのアカウントでポリシー違反が発生すると関連するすべてのアプリが削除される可能性があり、パートナー、顧客、クライアントにまで影響が及ぶ恐れがある。

度重なるポリシー違反または重大なポリシー違反が判明すると、アカウントが停止されて関連するすべてのアプリが削除され、それ以降は送信を行えなくなる可能性があります。どちらのアカウント管理モデルを選択した場合でも、ホワイトラベル アプリを長期的に成功させるには Google Play ポリシーに準拠することが不可欠です。

ストアでの表示の質を高める

ホワイトラベル アプリのデベロッパーが効率を重視する場合、複数のアプリでメタデータを再利用するのが一般的です。ただし、ユーザー エクスペリエンスを高めて Google Play ポリシーに準拠するには、各ストアの掲載情報を固有のものにし、コンテンツの繰り返しや誤解を招くコンテンツを避けることが重要になります。以下に、ストアでの表示の質を高めるためのヒントを示します。

  • ストアの掲載情報をアプリ固有にする: テンプレートベースのブランドアプリであっても、ストアの掲載情報はアプリごとに異なるものにする必要があります。固有の説明、アイコン、グラフィック、スクリーンショットを使用して、魅力的な掲載情報にしてください。ストアの掲載情報をアプリ固有にすることで、見た目が同じアプリが大量に表示されるのを防ぐことができ、Google Play の高品質なユーザー エクスペリエンスを維持できます。コンテンツの繰り返しに関するポリシーでは、アプリは独自のコンテンツやサービスを生み出すことによって、ユーザーに価値を提供するものでなければならないと定められています。ユーザーの誤解を招く恐れのある、既存のプロダクトやサービスと同一または類似の画像および映像を使わないでください。たとえば、アプリが特定の地域を対象としたものであれば、アプリアイコンにその地名を含めます(たとえば、アプリ 1 - ニューヨーク、アプリ 2 - ロサンジェルス)。以下に一般的な違反の例を示します。

各セクションをクリックすると、開いたり閉じたりできます。

  • アプリについて正確に説明する: 虚偽の振る舞いに関するポリシーに準拠するため、アプリの機能やコンテンツについての説明が正確であることを確認します。特定の機能を紹介する場合は、その機能がアプリで利用可能であることを確認してください。リリースされていない機能については言及しないようにしてください。新しい機能をリリースした場合にはアプリの説明を更新できます。

以下に一般的な違反の例を示します。

  • スクリーンショットがアプリと合致していることを確認する: スクリーンショットは、アプリの機能を正確に表し、アプリ エクスペリエンスに合致している必要があります。審査プロセスにおいてスクリーンショットと同じ状態を表示または再現できない場合、誤解を招く恐れがある、またはメタデータ不完全な機能に関するポリシーに違反していると判定され、否承認となる可能性があります。

  • 価値提案を明確にする: 何をするアプリなのか、他のバージョン(たとえば別地域向けのアプリ)とどう違うのかをわかりやすく説明します。

  • 簡潔に説明する: 説明は適切な形式で簡潔にまとめ、不要な詳細にまで言及するのは避けます。

  • 繰り返しを避ける: 簡単な説明の内容を詳しい説明で繰り返したり、同じキーワードを過度に繰り返したりしないようにします。たとえば、説明内での次のような繰り返しは避けてください。「カーレーシング、カー ドライビング、レースカー、カーレース、レース場、ドライビング、ドライブ、レース、カー、車、自動車、トラック」

  • 透明性を確保する: アプリが特定のユーザーベース向けに設計されている場合はそのように明記します。

その他の推奨事項

ポリシーに準拠するためのヒント

Google Play ポリシーに違反すると、アカウントの停止などの重大な結果につながり、アプリの公開やアップデートの送信が行えなくなる可能性があります。ポリシーに準拠するためのヒントをいくつか紹介します。

  • 完全に機能するアプリを送信する: 審査のために送信する前に、アプリが完全に機能していることを確認します。一部でも意図したとおりに機能しない場合、アプリが否承認となる可能性があります。アプリが未完成の場合はテストトラックを使用してください。

  • ログイン認証情報を提供する: Google Play Console 要件に記載のとおり、Google Play による審査時にアプリにアクセスできるようにするための情報(有効なデモアカウント、ログイン認証情報、その他のログイン情報など)を必ず送信に含めます。この情報がないとアプリを審査できず、アプリが否承認となる可能性があります。ログイン認証情報を提供する際の要件を確認してください。無料の e ラーニング コースも用意しています。

  • アカウント分散管理モデルの管理対象外アカウントに基本チェックを実装する - 管理対象外のアカウントからアプリを公開する前に必ず行う基本チェックを実装し、ポリシーに準拠するための基本的な品質基準(たとえば、アプリの説明がアプリのタイトルのコピーではないか)を満たしているかどうかを確認します。

アプリの審査と公開

アプリをスムーズに公開するためのヒントをいくつか紹介します。

  • 審査中は変更しない: アプリを送信して審査に入ったら、アプリに変更を加えないようにします。できれば、この期間中は「コードフリーズ」を適用してください。

  • ポリシーのステータスを確認する: アプリのポリシー ステータスを確認し、ポリシーに関する問題があれば対処します。

    1. Google Play Console を開きます。
    2. アプリを選択します。
    3. 左側のメニューで [ポリシーのステータス] を選択します。
    4. ポリシーのステータスを確認します。
      • [問題は検出されませんでした] と表示されている場合は、アプリに対して適用された違反措置はなく、何もする必要はありません。
      • アプリが否承認となった場合は、最後に承認されて公開されたバージョンが引き続き Google Play に掲載されています。
      • アプリが削除された場合は、ポリシーを遵守したアップデートが送信されるまでは Google Play に掲載されません。
      • アプリが停止された場合は、以後 Google Play に掲載されません。[再審査を請求] を選択して、その決定に対して再審査を求めることができます。
  • 審査時間を見込んでおく: 審査にかかる時間は状況によって異なります。予期しない問題が発生することも想定し、アプリの審査時間に余裕を持たせてリリース スケジュールを組むようにしてください。審査は通常であれば 7 日以内に完了しますが、例外的にそれ以上かかる場合もあります。

  • 管理対象の公開で早めにアップデートを送信することを検討する: 既存のアプリのアップデートは通常どおり処理されます。アップデートが承認された後、変更を公開する正確なタイミングをデベロッパー自身が管理できます。管理対象の公開の詳細と、変更が審査、公開されるタイミングを指定する方法については、こちらのヘルプセンター記事をご覧ください。

  • ポリシーの問題の解決方法を文書化しておく:アプリを頻繁に公開する場合は、ポリシーの一般的な問題とその解決方法、今後のリリースで同様の問題を防ぐためのプロセス変更やガイドラインについて文書化しておくことを検討します。

ホワイトラベル アプリをそれらのヒントやガイドラインに沿って公開することで、複雑なアプリ公開プロセスにも容易に対応でき、アカウントのステータスを良好な状態に維持しつつクライアントのアプリ リリース プロセスを円滑に進めることができます。

この情報は役に立ちましたか?

改善できる点がありましたらお聞かせください。

さらにサポートが必要な場合

次の手順をお試しください。

true
4677101072963927568
true
ヘルプセンターを検索
true
true
true
true
true
92637
検索
検索をクリア
検索を終了
メインメニュー
false
false
false
false