Googleの12人のテスタールールは実際には何を言っていますか?
Play ConsoleヘルプセンターからのGoogle自身の言葉は短いです:
"新しく作成した個人デベロッパーアカウントを持っている場合、過去14日間継続してオプトインしている最低12人のテスターでアプリのクローズドテストを実行する必要があります。"
PLAY CONSOLE ヘルプ · 回答 14151465
その文章の3つの詳細がすべてを決定します。テスターは オプトイン でなければならず、ただリストに追加されただけではいけません。14日間は 継続的 で、途切れていない期間でなければなりません。そしてルールは 2023年11月13日以降に作成された個人デベロッパーアカウント に適用されます。
Play Console内でロックされた「本番環境へのアクセスを申請」ステップとしてこのルールに直面します。コンソールが14日連続で少なくとも12人のオプトイン済みテスターをカウントするまで、トラックは閉じられたままです。
なぜGoogleは14日間の12人のテスターを要求するのですか?
この要件は2023年後半に到着しました。Googleが新しい個人デベロッパーアカウントのルールを厳格化した時です。明記された目標は品質です:アプリは、ビルドマシンから直接ではなく、実在の人が本当に使用した後に公開ストアに到達するべきです。
Googleにとって、2週間のライブテスターアクティビティは、コードレビューよりもはるかに確実に、低努力およびスパムの提出をフィルタリングします。元々、ルールは20人のテスターを必要としていましたが、Googleは2024年後半に単独の開発者の負担を軽減するためにこれを12人に減らしました。
この変更は、Googleがほぼ同時期に導入した新しいアカウントの電話やID認証など、他の本人確認と並んでいます。これらは相まって、Playへの配信のハードルを上げました。特に初めてアプリを公開する開発者にとってそうです。
14日間の時計をリセットする間違い
失敗したクローズドテストの多くは、アプリの品質が理由で拒否されるのではなく、12人のテスター数が1日静かに基準を下回ったか、連続記録が途切れたためです。Play Consoleは、これが起こっても警告しません。Testersタブを確認するまで、静かに失敗します。
開発者が失敗した後に私たちのところに来たとき、私たちが最もよく目にするのはこれです:
テスターは初日にオプトインし、その後アプリを二度と開かない
テストがクローズドトラックではなく、オープンまたは内部トラックで実行される
選択した国が、アプリの意図した本番環境の国と一致しない
テスト中のビルドが起動時にクラッシュし、セッションが完全に停止する
テスターが交代させられ、その席の14日間のカウントが再スタートする
チェックアウト後に何が起こるか
注文フローは一つの考えを中心に設計しました:あなたの作業は数週間ではなく数分で終わるべきです。支払いが確認されると、マッチングエンジンがアプリのカテゴリに合うデバイス、ロケール、アカウント年齢を持つテスターを引き出します。
0〜2時間: 12人以上のテスターがマッチし、リストがメールで送信され、Play Consoleに貼り付ける準備ができます。
2〜6時間: テスターが招待を承諾してオプトインし、14日間の時計が始まります。
1〜14日目: 各テスターがアプリを開き、毎日セッションを記録します。Play Consoleでオプトイン数がライブで更新されるのをずっと見守ることができます。
15日目: エンゲージメントレポートが配信され、本番環境へのアクセスを申請する際に参照できるようになります。
実在の人物 vsに適用されます。 ボットファーム
Googleは単なる頭数以上を見ます。デバイス認証、IP分布、アカウント年齢、行動パターンはすべて、テストバッチが本物と見なされるかどうかの要因です。私たちのテスターは40カ国以上に分散しており、Play Storeアクティビティの有機的な履歴を持つアカウントで、Samsung、Google Pixel、XiaomiなどのAndroid OEMの本当の混合を使用しています。
すべてのテスターはプールに参加する前に人間のレビューに合格しており、疑わしいパターンを示すアカウントは新しい注文に割り当てられるのではなく削除されます。ボットパネルとエミュレータファームはここで近道をしますが、それがデベロッパーアカウントにフラグを立てられる原因になります。
15日目に受信箱に届くもの
14日間のウィンドウが閉じると、Googleのアンケートが尋ねる傾向がある詳細を網羅したPDFエンゲージメントレポートを受け取ります:全テスターのオプトインのタイムスタンプ、毎日のセッションの長さ、デバイスモデル、Android OSバージョン、およびテスターの国です。
ほとんどの開発者は、本番環境へのアクセスのアンケートに答える際にこのレポートの短い要約を添付し、Googleのレビューチームがテストの実施方法について質問してきた場合に備えて完全なファイルを手元に保管しています。
本番環境へのアクセスを申請
14日間の要件が満たされると、Play Consoleの「本番環境へのアクセスを申請」ボタンがロック解除されます。フィードバックをどのように集め、その結果何を変更したか(変更した場合)についての短いアンケートに答え、Googleが提出物をレビューします。
レビュー時間は異なりますが、通常は数日です。Play Consoleで完全な14日間と12人以上のオプトインが確認されるまで提出を待つことをお勧めします。数時間早く申請するだけでも、アプリの品質とは無関係な、回避可能な拒否の一般的な原因となります。
このルールはあなたのアカウントに適用されますか?
12人のテスタールールは、特に2023年11月13日以降に作成された個人デベロッパーアカウントを対象としています。登録時にD-U-N-S番号を必要とする組織アカウントは、必須のクローズドテストが免除されます。
それでも、多くの組織アカウントはとにかくクローズドテストを実行することを選択しています。ローンチ前の実際の使用データは、早期のクラッシュによる停止を減らす傾向があり、開発環境外でアプリがどのように機能するかを最初に確認する機会を与えます。
336時間の時計が実際にどのようにカウントされるか
14日間の時計は、12番目のテスターが招待を承諾してオプトインした瞬間に始まります。Play Consoleはそのタイムスタンプから正確に336時間連続してカウントし、注文ごとではなくテスターごとに追跡します。
それをリセットする2つのこと:オプトイン数が12を下回る(一時的でも)、またはテスターを削除して新しい人と交代させることです。交代した人の時計はゼロから始まります。Play Consoleの「テスター」→「クローズドテスト」でいつでも実行中のカウントを見ることができます。
Googleがテスト自体をどのようにレビューするか
12/14のしきい値を超えると申請ボタンがロック解除されますが、それがGoogleのレビューで考慮される唯一のシグナルではありません。自動チェックおよび一部のケースでは手動のレビュアーが、テスト期間全体のセッションの長さ、クラッシュ率、アンインストール率を調べます。
すべてのテスターが初日に1回開き、二度と戻らなかったアプリは、技術的には12/14の数字を満たすことができますが、レビュアーには低エンゲージメントと見なされます。そのため、最小限のカウントに到達するよりも、ウィンドウ全体にわたる毎日の広がりのあるアクティビティが重要です。
一度拒否された場合 — 2回目に何が変わるか
何か別のことをする前に、拒否理由を注意深く読んでください。「テスト不足」はコンテンツやポリシーの拒否とは異なる問題であり、それぞれに異なる修正が必要です。実際の原因に対処せずに再申請しても、同じ結果になるだけです。
理由がテスト不足である場合、Play Consoleは新たな、途切れることのない14日間のウィンドウを要求します。すでに完了した日数に対する部分的なクレジットはありません。拒否が私たちが実施したテストに続くものであり、原因が純粋にテスト量であった場合、私たちは追加費用なしで再実行します。
一人のテスターを招待する前のチェックリスト
テスターがオプトインする前の数分のセットアップで、章3の失敗の大部分を防ぐことができます。まず以下の各項目を確認してください:
内部テストトラックがすでにGoogleによってレビューおよび承認されている
専用のクローズドテストトラックが作成されている(オープンや内部ではない)
選択した国が、意図した本番環境の国と一致する、またはそれを含む
テスターのメールリストまたはGoogleグループがクローズドトラックに正しく添付されている
ストアリスティング(アイコン、スクリーンショット、説明)が、テスターが混乱しない程度に十分に完成している
Play Integrityが実際にチェックしていること
Play Integrity APIは、すべてのインストールを3つの評決に対して評価します:デバイスがGoogleの整合性基準を満たしているか、アプリのバイナリが変更されていないか、アカウントが良好でライセンスされた状態にあるかです。ルート化されたデバイス、エミュレータ、クローンAPKは通常、最初の2つで失敗します。
テストバッチ内で1つでも失敗した評決があると、グループ全体に疑いがかけられる可能性があり、それが、生の頭数よりも、変更されていない実際の物理デバイス上のテスターが重要である理由です。また、安価なボットベースのパネルがデベロッパーアカウントを保護するのではなく危険にさらす主な理由でもあります。
Googleの本番環境アクセスフォームへの回答
本番環境アクセスフォームは平易な言葉で2つのことを尋ねます:テスト中にフィードバックをどのように集めたか、そしてその結果何を変更したかです。曖昧で一般的な回答は、1日に何百件も読むレビュアーの目に留まります。
具体的な回答の方がうまくいきます。例えば、ロード時間が遅いデバイスや、それに対応して出荷した修正など、実際の観察を参照してください。初回で合格した提出物から作成したテンプレートを共有していますので、アプリのテストメモに合わせて調整できます。
Play Consoleの用語定義
Play Consoleが使用する語彙は特殊です。このガイドで最もよく出てくる用語を以下に示します。
オプトイン テスターがウェブまたはPlay Storeでテストへの招待を承諾し、14日間のカウントを開始すること。
クローズドトラック この要件が適用される特定のリリースチャネル。内部テストおよびオープンテストとは異なります。
個人デベロッパーアカウント 個人(非組織)のPlay Consoleアカウント。このルールが適用されるアカウントタイプです。
本番環境へのアクセス すべてのPlay Storeユーザーにアプリを公開する許可。
ローンチ前レポート Googleが実機でアプリを自動スキャンしたもので、クローズドテストとは別に生成されます。
段階的ロールアウト ローンチ後に使用され、全員に拡大する前に、本番環境ユーザーの一定割合にアップデートをリリースすること。