Rollouts でディスカウントを 「一部配信・比較・同時ローンチ」

図解 ： Rollouts でディスカウントを予約配信・テストできるように Admin / New ・ 2026-10-02 Rollouts でディスカウントを 「一部配信・比較・同時ローンチ」 Rollouts にディスカウントを含められるようになった。新しいオファーをオンラインストアのトラフィックの一部だけに出し、既存オファーとコンバージョンを比較して、テーマやチェックアウトの変更と一緒にローンチできる。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： ディスカウントを Rollout に載せる流れ できるようになった3つのこと 従来の期間指定 vs Rollouts 変わらないこと／記載がないこと 使い方の流れ（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまで Rollouts に載せられたのはテーマやチェックアウトの変更。今回から ディスカウントも Rollouts に含められる ようになった。 「全員に一斉に出す」のではなく、 一部のトラフィックで試す → 結果を見る → 広げる という段階的な出し方が、割引でもできる。 これまで ： 開始日・終了日で単独配信 ディスカウントは開始日・終了日を設定して公開する単独プロモーション。出すと決めたら全体に適用される。 これから ： Rollouts で段階配信・比較 オンラインストアのトラフィックの一部に新オファーを出し、既存オファーとコンバージョン結果を比較。準備ができたら拡大。 2 仕組み図解 ： ディスカウントを Rollout に載せる流れ Rollouts ： ストアの変更をスケジュールし、トラフィックの一部で試してから広げるための仕組み。今回の更新で、その対象に ディスカウント が加わった。配信割合の指定方法や上限などの詳細は本記事には記載なし。 3 できるようになった3つのこと Schedule ディスカウント変更を予約 新オファーをオンラインストアのトラフィックの一部に出し、準備ができたら拡大できる。 Compare オファーを比較 ディスカウント変更を既存オファーと対比してテストし、コンバージョン結果を見て残すほうを決める。 Launch together まとめてローンチ ディスカウントを、テーマ・チェックアウトの変更と同じ 1 つの Rollout で同時に公開するよう予約できる。 4 従来の期間指定 vs Rollouts 項目 ディスカウント単体（開始日・終了日） Rollouts に含める 配信範囲 記載なし（単独プロモーションとして公開） 一部トラフィック から始めて拡大 オファーの比較 記載なし 可能 既存オファーとコンバージョン結果を比較 他の変更との同時公開 記載なし 可能 テーマ・チェックアウトと 1 つの Rollout で 顧客の適用条件 ディスカウントの設定どおり ディスカウントの設定どおり（ 引き続き適用 ） 位置づけ 継続利用可 新しい選択肢 5 変わらないこと／記載がないこと 顧客の適用条件はそのまま Rollout に含めても、そのディスカウントに設定済みの顧客の適用条件（eligibility rules）は引き続き適用される。 開始日・終了日も使い続けられる 単独のプロモーションを予約したい場合は、これまでどおりディスカウントの開始日・終了日で設定できる。 対象プラン・対象ディスカウントの種類・配信割合の設定範囲・比較で見られる指標の詳細・API での扱いは、本記事には 記載なし 。導入前にヘルプドキュメント（ディスカウントの予約とテスト）と管理画面で確認すること。 6 使い方の流れ（3ステップ） 1 Rollout にディスカウントを含める 必要ならテーマ・チェックアウトの変更も同じ Rollout に。 2 一部のトラフィックで試す 既存オファーと比べてコンバージョン結果を確認。 3 残すオファーを決めて拡大 準備ができたら、より広く公開する。 上は記事に書かれている機能を順に並べた流れ。管理画面での具体的な操作手順は本記事には 記載なし （ヘルプドキュメント参照）。 7 技術者が押さえるべき5つのポイント 1. 対象は「オンラインストアのトラフィック」 記事が明示しているのはオンラインストアのトラフィックの一部への配信。POS など他チャネルへの適用は記載なし。チャネル横断の割引を組んでいる場合は挙動を事前確認。 2. 適用条件は二重のフィルタになる 「Rollout で振り分けられたか」に加えて、ディスカウント側の顧客適用条件も効く。テスト時に割引が出ない場合は両方を疑う。 3. テーマ・チェックアウトと「同時公開」の単位 キャンペーン LP（テーマ）・チェックアウト変更・割引を 1 つの Rollout でそろえられるので、公開タイミングのズレ（割引だけ先に効く等）を防ぎやすい。 4. API／Webhook の言及は無い Admin GraphQL から Rollout にディスカウントを含められるか、配信割合を操作できるかは記載なし。自動化前提の案件は検証が必要。 5. 開始日・終了日の予約とは別ルート 単独プロモーションは従来どおり開始日・終了日で予約できる。 テストや他の変更との連動が要るものは Rollouts、単純な期間限定セールは期間指定 、と運用ルールを決めておくと、どちらで公開したかの混乱を避けやすい（使い分け方針は記事に記載なし、運用上の提案）。 8 業務に活かせる3つのユースケース USE CASE 1 「どの割引が一番効くか」をデータで決める 課題 「10% OFF と送料無料のどちらが売れるか」を担当者の勘で決めていて、施策の根拠を説明できない。 打ち手 新オファーを Rollout に含め、一部トラフィックで既存オファーと比較。コンバージョン結果を見て残すほうを決める。 効果 割引施策の意思決定に根拠ができ、効かない割引で粗利を削るリスクを減らせる。 技術メモ 比較で見られる指標の範囲は記事に記載なし。粗利や AOV まで見たい場合は Shopify Analytics など別の集計と合わせて確認。 USE CASE 2 BFCM などの大型キャンペーンを「1 回の公開」でそろえる 課題 セール開始時刻にキャンペーン用テーマ・チェックアウト変更・割引をそれぞれ手作業で切り替えていて、反映のズレや作業漏れが起きる。 打ち手 3 つの変更を 1 つの Rollout にまとめ、同時に公開するよう予約する。 効果 深夜・早朝の切替作業が減り、「LP は出たのに割引が効かない」といった事故を防げる。 技術メモ 割引の顧客適用条件は引き続き適用されるので、会員限定割引などは条件設定を事前にテストしておく。 USE CASE 3 強めの割引を「小さく出して」リスクを抑える 課題 大幅値引きや新しい形の割引を全体に一気に出すと、想定外の利益減や設定ミスの影響が大きい。 打ち手 まずオンラインストアのトラフィックの一部だけに配信し、結果と挙動を確認してから拡大する。 効果 設定ミスや期待外れの施策を、影響が小さいうちに見つけて止められる。 技術メモ 途中で配信割合を変える方法・ロールバックの手順は記事に記載なし。運用前にヘルプドキュメントで確認すること。 9 提案で使える1行サマリ 「割引も Rollouts で 一部に出して試し、既存オファーとコンバージョンで比べ、テーマ・チェックアウトと一緒に公開 できるようになった。 顧客の適用条件はそのまま。勘で決めていた割引施策を、データで決める運用に切り替えられる。」 source ： changelog.shopify.com / schedule-and-test-discounts-with-rollouts 公開日 2026-10-02