アプリが Rollout（計画的なローンチ・実験・期間限定イベント）を見つけ、スケジュールやトラフィック配分、変更されるリソースを読み取り、変更時には通知を受け取れるようになった。対象はディスカウント・カタログ・テーマ・チェックアウトとアカウントの設定。
本記事は以前の状態を明示していない（記載なし）。今回「アプリが Rollout を discover / read できるようになった」と案内されている。
Rollout の一覧・検索・ID 指定取得、トリートメントごとの変更内容、スケジュール、配分を読める。ライフサイクル・実効配分・リソース変更を Webhook で受け取れる。
rollouts で一覧・検索rollout(id:) で直接取得※ バーの長さはイメージ。具体的な数値や、両者がずれる条件は記事に記載なし。
effectiveTrafficAllocation を見ること。通知の種類は「ライフサイクル」「実効配分」「リソース変更」の 3 系統。
どの Rollout が変わったかを知るきっかけとして使う。
記事の推奨 ： 影響を受けた Rollout を refetch して連携データを最新に保つ。
| 通知の系統 | 何がわかるか | 具体的なトピック名 |
|---|---|---|
| ライフサイクル | Rollout の状態の変化 | 記載なし（API リファレンス参照） |
| 実効配分 | effective allocation の変化 | 記載なし（API リファレンス参照） |
| リソース変更 | Rollout が変更するリソースの変化 | 記載なし（API リファレンス参照） |
read_rolloutsRollout データにアクセスするために要求するスコープ。
Rollout の中に含まれるディスカウント等のリソース本体（payload）には、それぞれの既存スコープが適用される。
既存インストールでは、マーチャントによる再承認（reauthorization）が必要になる可能性がある。
記事で案内されているのはクエリ（rollouts / rollout(id:)）と Webhook。Rollout を作成・更新する mutation については記載なし。
trafficAllocation だけで判断しない。現在どれだけ効いているかは effectiveTrafficAllocation、トリートメント間の配分は split 値で読む。
記事は通知後に影響 Rollout を refetch するよう案内している。通知 payload の中身だけで状態を組み立てる前提にしない設計が無難。
read_rollouts に加え、中身のリソース payload には既存スコープが適用される。片方だけだと見えない部分が出る前提でスコープ設計とエラーハンドリングを。
ディスカウントを読むアプリ向けに「Update your app to account for discount Rollouts」が用意され、互換性の挙動にも触れている。既存のディスカウント連携がある場合は、本機能の導入有無に関わらず確認対象。既存インストールの再承認フローもあわせて計画する。
read_rollouts を追加 → rollouts でディスカウントに影響する Rollout を把握 → Webhook 受信時に該当 Rollout を再取得。trafficAllocation・effectiveTrafficAllocation・トリートメントの split 値・開始/終了予定を取得して並べて表示。実効配分の Webhook で更新。read_rollouts で読み、Webhook で追従できるようになった。