WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
What's new in App Store Connect

What's new in App Store Connect

WWDC 2022App StoreDistributionApp Store Connect
元の動画を見る

ハイライト

セッションでは、Web、iOS アプリ、API の 3 つのレベルで App Store Connect のアップデートを取り上げます。

主要内容

App Store Connect に関する問題は、多くの場合、ボタンに関するものではありません。

マーケティング キャンペーンでは、アプリの新しいバージョン、アプリ内キャンペーン、カスタム製品ページ、製品ページ最適化テストが必要になる場合があります。以前は、これらのプロジェクトは簡単に分解され、レビューのコンテキストが分散していました。拒否されたプロジェクトはリリース頻度にも影響を与えるため、チームは何が継続でき、何が再提出されるべきかを繰り返し判断する必要があります。

このセッションでは、2022 年の変更点を送信エクスペリエンスと API 自動化の 2 つのラインに分けました。

送信エクスペリエンスでは、複数のレビュー プロジェクトが同じレビュー送信に組み込まれます。 App Review では、同じコンテキストでそれらをレビューできます。ほとんどの場合、チームは、承認された iOS バージョンをすでに取得していれば、新しいバイナリを準備することなく、アプリ内アクティビティ、カスタム製品ページ、製品ページ最適化テストを個別に送信することもできます。

API ラインは自動化を目指しています。 App Store Connect API 2.0 ではリソースの数が 60% 拡張され、アプリ内購入、サブスクリプション、ユーザー レビューの返信、アプリのハング診断などの機能が追加されます。バックエンド、運用システム、高品質プラットフォームを公開しているチームにとって、これらのアップデートにより、より多くの App Store Connect オペレーションが Web ページからオーケストレーションされたプロセスに移行されます。

詳細

複数のレビュー項目を 1 つの提出物に結合する

(01:24)新しく強化された App Store の送信エクスペリエンスにより、複数のレビュー項目を 1 つのレビュー送信に含めることができます。セッションに明示的にリストされているレビュー項目には、アプリのバージョン、アプリ内イベント、カスタム製品ページ、製品ページ最適化テストが含まれます。

レビューの送信に必要な項目は 1 つだけです。複数のアイテムをグループ化する利点は、アプリ レビューが同じコンテキストでそれらをレビューできることです。この講演では、レビューの提出はアイテムの数や種類に関係なく、通常 24 時間以内にレビューされることも説明されました。

このメカニズムには重要なルールがあります。それは、提出されたすべての項目が受け入れられた場合にのみ、その中の項目が承認されるということです。プロジェクトが拒否された場合、チームには 2 つの対処方法があります。拒否されたプロジェクトを変更して再提出するか、拒否されたプロジェクトを現在の提出から移動して、承認されたプロジェクトにレビューを完了させるかです。

review submission
├─ app version
├─ in-app event
├─ custom product page
└─ product page optimization test

if all items are accepted:
  every item becomes approved
else:
  edit rejected items and resubmit
  or remove rejected items and submit them later

キーポイント:

  • review submissionこれはレビュー用のコンテナであり、単一の機能ページではありません。 -app version、in-app event、custom product pageそしてproduct page optimization testセッションに明示的にリストされているコミット可能な項目です。 -all items are acceptedスピーチの承認ルールに対応: 提出されたすべてのプロジェクトが受け入れられるまで、プロジェクトは承認されません。 -editそしてremove拒否された場合の続行方法は2通りに対応。

新しいバージョンのバイナリを使用せずにマーケティング プロジェクトを送信する

(03:24) 新しい提出プロセスは、マーケティング コンテンツが必ずしも新しいバイナリに従う必要がないという、もう 1 つの一般的な問題も解決します。

このスピーチでは、各提出物には関連するプラットフォームがあり、各プラットフォームが特定のレビュー項目をサポートしていることが説明されています。アプリのレビューでは、アプリのバージョンをレビューのベースラインとして使用します。提出物にアプリのバージョンが含まれている場合は、このバージョンを使用します。新しいバージョンが含まれていない場合は、既存の承認済みバージョンが必要です。

これは、最初の iOS バージョンが承認された後、新しいアプリ バイナリを必要とせずに、チームがいつでもアプリ内イベント、カスタム製品ページ、製品ページ最適化テストを送信できることを意味します。

approved iOS app version
└─ review against this version
   ├─ in-app events
   ├─ custom product pages
   └─ product page optimization tests

キーポイント:

  • approved iOS app versionこれは、新しいバージョンを使用せずに提出するための前提条件です。 -review against this versionスピーチにおける「項目はこのバージョンに対してレビューされる」というルールから。
  • 3 つのサブ項目はすべて、最初の iOS バージョンが承認された後に個別に提出できるコンテンツです。

Web、iOS、iPadOS でのレビューの管理

(04:40) App Store Connect Web に専用のアプリ レビュー ページが追加されました。アプリに入ると、左側のナビゲーションにあるアプリ レビューで提出物の概要を表示したり、単一の提出物を入力して詳細を表示したりできます。

(05:04) 同じ強化された送信エクスペリエンスが、App Store Connect の iOS および iPadOS アプリにも提供されます。チームはモバイル デバイスから Ready for Review の提出、レビューの進行状況の追跡、ステータス通知の受信、アイテムの削除、拒否理由の表示、アプリ レビューへの応答を行うことができます。

App Review page
├─ submission overview
├─ submission details
├─ App Review messages
└─ recently completed submissions

App Store Connect app on iOS and iPadOS
├─ submit Ready for Review submissions
├─ track review progress
├─ receive status notifications
├─ remove items
├─ view rejection reasons
└─ reply to App Review

キーポイント:

  • App Review page審査プロセスをWeb上で一元管理するための新しいポータルです。 -submission overviewそしてsubmission details概要と詳細は該当ページでご覧いただけます。
  • iOS/iPadOS リストの各項目は、トランスクリプト内のモバイル機能の説明に基づいています。
  • ここには新しいビジネス API はありません。主な変更点は、監査操作とモバイル処理機能への入り口です。

App Store Connect API 2.0 により自動化の範囲が拡大

(05:53) App Store Connect API は、アプリのワークフローのカスタマイズと自動化に使用されます。講演では、過去 1 年間に API が App Clips、Xcode Cloud、アプリ内イベント、カスタム製品ページ、製品ページの最適化、App Store の送信エクスペリエンスの強化をサポートしたと述べました。

2022 年夏の 2.0 リリースでは、API リソースの数が 60% 増加します。新しい機能は次の 3 つの方向に集中しています。

App Store Connect API 2.0
├─ in-app purchase and subscription lifecycle
│  ├─ create
│  ├─ edit
│  ├─ delete
│  ├─ manage pricing
│  ├─ submit for review
│  ├─ create special offers
│  └─ create promo codes
├─ customer reviews
│  ├─ fetch reviews
│  └─ respond to reviews
└─ app hangs diagnostics
   ├─ diagnostic signatures
   └─ diagnostic logs relationship

キーポイント:

  • in-app purchase and subscription lifecycle作成、編集、削除、価格設定、レビューの送信、割引および引き換えコードをカバーします。 -customer reviewsコメントを取得して返信する機能を追加して、顧客サービスまたはユーザー対話プロセスを構築します。 -app hangs diagnosticsハング率を提供するだけでなく、ハング診断タイプを追加しました。 -diagnostic logs relationshipハング シグネチャの詳細なスタック トレースが利用可能です。

XML フィードが終了し始めます

(08:05) Apple は、4 年間の開発を経て App Store Connect API 2.0 を重要なマイルストーンと呼び、REST API が App Store Connect 自動化の未来であると述べています。したがって、XML フィードはその年の秋に廃止されます。

既存の統合の場合、これは移行シグナルです。 XML フィードに依存するパブリッシング、レポート、または内部システムは、App Store Connect API を利用する必要があります。

legacy XML feed integration
└─ migrate to App Store Connect API
   ├─ submission workflows
   ├─ in-app purchase workflows
   ├─ customer review workflows
   └─ power and performance diagnostics

キーポイント:

  • legacy XML feed integration古い XML フィードをまだ使用しているシステムを表します。 -migrate to App Store Connect APIそれが演説で示された方向性だ。
  • 後続の 4 つのワークフローはすべて、このセッションで説明した API 自動化スコープからのものです。

重要ポイント

  • マーケティング コンテンツ リリース パネルを作成: アプリ内アクティビティ、カスタム製品ページ、および製品ページ最適化テストをキャンペーンごとに整理します。 実行する価値がある理由: レビューを送信すると、同じコンテキストで複数のプロジェクトをレビューできます。 開始方法: まず、App Store Connect Web で申請をモデル化し、各項目の審査ステータスと拒否理由を記録します。

  • 運用リリースとアプリ リリースを分割: 最初の iOS バージョンが承認された後、運用チームが独立してアプリ内アクティビティとページ実験を送信できるようにします。 実行する価値がある理由: セッションでは、これらのプロジェクトにはほとんどの場合、新しいアプリ バイナリが必要ないことが明確に述べられています。 開始方法: ルールを設定します: バイナリ関数を含む変更のみがアプリ バージョンのリリースに組み込まれ、他のマーケティング プロジェクトは個別に提出されます。

  • アプリ内購入バックエンドを構築: App Store Connect API 2.0 を使用して、アプリ内購入とサブスクリプションの作成、価格設定、レビューの送信、割引と引き換えコードを管理します。 実行する価値がある理由: API 2.0 は、自動化システムの完全なライフサイクルを開きます。 開始方法: App Store Connect API ドキュメントのアプリ内購入とサブスクリプションのリソースから開始し、手動操作を内部ステート マシンにマップします。

  • App Store レビューの一元処理: レビューをカスタマー サービス システムに取り込み、同じシステムから返信します。 実行する価値がある理由: API 2.0 では、顧客レビューの取得と応答が追加されています。 開始方法: まず、アプリ、国、地域、評価、バージョン番号ごとにコメントキューを作成し、返信承認プロセスにアクセスします。

  • ハング診断を品質ダッシュボードに接続: ハング診断の署名と対応するログを定期的に読み取ります。 実行する価値がある理由: 新しいハング診断タイプでは、最も影響を及ぼしているハング位置を特定し、診断ログの関係を通じてスタック トレースを表示できます。 開始方法: ハングのシグネチャを既存のパフォーマンス ダッシュボードに集約し、影響を受けるユーザーの数または発生率で並べ替えます。

関連セッション

コメント

GitHub Issues · utterances