見出し画像
Photo by akisuke0925

【第401回】 Marketing Cloud Next ： 動的セグメントの活用

Nobuyuki Watanabe

2025 年 10 月の Data Cloud アップデートで「動的セグメント」と「ブロードキャストフロー」という新しい機能が追加されました。

今回のセグメント機能
　① ✖️ 標準セグメント
　② ✖️ ウォーターフォールセグメント
　③ ✖️ リアルタイムセグメント
　④ ⭕ 動的セグメント
　⑤ ✖️ Einstein Segment Creation（AI によるセグメント）

特に動的セグメントは、新規のセグメント作成画面に、突然登場したこともあり、「これ、どう使うの？」「従来のセグメントと何が違うの？」と戸惑っている方も多いのではないでしょうか。

そこで本記事では、これらの新機能がどのような場面で活用できるのか、仕組みから実際の利用方法までを、できるだけ分かりやすく整理してご紹介していきます。

両機能の関連性

まず大前提として、現時点では、動的セグメントが利用できるのは「ブロードキャストフロー」のみ です。他のフローでは機能しません。

動的セグメントとは

「静的条件」と「動的条件」の違い

動的セグメントでは、従来の 「静的な条件」 に加えて、配信タイミングに応じて変化する 「動的な条件」 を扱うことができます。

  • 静的条件の例
    　例：性別 = 女性
    　→ API 実行時に「女性全員へ送る」と固定で指定するイメージです。

  • 動的条件の例
    　例：API から渡されたパラメーターに応じて、ある時は「A」、そしてある時は「B」、そしてまたある時は「C」と、柔軟に条件を変化さられます。
    　→ 配信タイミングに差し込んだ値に応じて、セグメントの抽出対象が変わる仕組みです。

動的条件に使用する値は、API 実行時にパラメーターとして指定 します。

以下の例では、チケット ID が「TID01359」というパラメーターを渡しており、「TID01359」を購入した人全員へメッセージを送ることができます。

{ 
"inputs" : [ {
   "ticketIdVariable" : "TID01359"
   } ] 
}

つまり、静的条件が「予め決まっている固定の絞り込み」であるのに対し、動的条件は 「配信直前のパラメーターに応じて毎回結果が変わる絞り込み」 と考えると分かりやすいでしょう。

動的セグメントには「公開」ステータスがありません

通常のセグメントには「ドラフト」「公開」といったステータスがありますが、動的セグメントには「公開」という概念がありません。

常に最新状態がそのまま利用されるため、
「公開作業が不要なセグメント」と理解しておくと良いでしょう。

大規模送信：最大 100,000 件

大規模なオーディエンスに対してメッセージを送信でき、
現時点では、一度に、最大 10 万件まで 送信を可能にします。

Count / Preview を使う際の注意点

動的セグメントでも、通常のセグメントと同様に
Count（件数確認） や Preview（プレビュー） を利用できます。

しかし、動的条件はそのままでは件数が計算できないため、
Count / Preview を行う際は動的パラメータを一時的に静的値へ置き換える必要があります。

  • 一時的に静的値にして件数・結果を確認

  • 問題なければ再度「パラメータ化フィルター」に戻す

こうした流れで確認することで、安全に動的セグメントの挙動をチェックすることができます。

ブロードキャストフローとは

ブロードキャストフローは、以前に私の記事でも紹介した オンデマンドフローの「セグメント版」 とイメージすると理解しやすいです。

  • オンデマンドフロー：1 人ずつ トリガーする

  • ブロードキャストフロー：セグメントを トリガーする

つまり、セグメントに属する対象へ、一括でリアルタイム通知を行うための仕組み です。

アドホック実行のみ対応

現時点では、単発のオンデマンド API 実行のみ対応（スケジュール実行は不可） です。

  • デバッグ機能は未サポート

  • 待機要素も未サポート

※いずれもロードマップには入っているようです。

設定方法

それでは、皆さんが気になっている設定方法について手順を書いてみます。

動的セグメント

1. まずは、新規セグメントの画面で「動的セグメント」を選択します。

2. セグメント対象で「Individual」を選択します。

3. 前述の通り「公開」という概念は存在しませんので、公開スケジュールは設定できません。エンゲージメントデータに対する ルックバック期間 だけ設定してください。

4. まずは、静的条件として、チケット ID が「TID01359」のチケットを購入している人をセグメントでカウントしてみます。

5. このカウントが、ご自身の想定通りの数であることを確認します。この数でフローが実行されれば成功になります。

6. 確認ができたら、再度フィルター画面を開き、「パラメーター化値を有効化」するにチェックを入れます。

7. 値には、「ticketIdVariable」のようなTicket Id に関する変数名を入力します。変数名に過ぎないので、値は何でも問題ありません。

8. すると、値に「変数：{!ticketIdVariable}」が挿入され、カウントもされなくなりました。これで「完了」をクリック、設定を保存してください。

動的セグメントの設定はこれで完了です。

ブロードキャストフローの設定

続いて、ブロードキャストフローの設定を行います。

1. Flow Builder で Broadcast Flow を検索して、選択します。

2. このフローの開始要素で選択できるのは「動的セグメント」のみ です。

3. 続いて、メールアドレスが格納されているデータモデルオブジェクトの API 名 を指定します。

4. 次に、一番下にある、動的セグメントの パラメータ化フィルターへ差し込む値 を指定します。今回は、これを API 実行からの値としたいので、変数として入力します。新規リソースをクリックします。

5. 「変数」を選択します。

6. 変数名を適当につけて（今回は、セグメント設定時の変数名と同じく「ticketIdVariable」にしてあります。）、データタイプは「テキスト」にし、「入力で使用」にチェックを入れます。これでこの変数名で API から値を受けられるようになります。その後、設定を完了してください。

7. 続いて、要素の追加をクリックすると、Marketing Cloud Next 送信ができたり、Marketing Cloud Engagement のジャーニーへ送信することができます。今後、さらに多くのチャネルが追加される予定だそうです。

8. 今回は、Marketing Cloud Next 送信を実行したいと思います。設定後、ブロードキャストフローを保存して、アクティブ化してください。

ブロードキャストフローの設定もこれで完了です。

REST API の実行

REST API の実行については、次の 2 段階があります。

  • アクセストークンの取得

  • リソースサーバーへの実行

アクセストークンの取得に関しては以下の記事を参考にしてください。

これでアクセストークンが取得できたら、リソースサーバーへの実行を行います。

1. 事前に、以下の 3 つを準備します。

  • アクセストークン

  • Flow API 名

  • 私のドメイン名（設定から「私のドメイン」に進んで確認してください）

2. Talend API Tester の新しいリクエストを開いたら、以下の通り登録します。※ Bearer と アクセストークの間は半角スペースが必要です。

--- メソッド 
POST 

--- エンドポイント
https://[私のドメイン名].my.salesforce.com/services/data/v65.0/actions/custom/flow/[Flow API 名]

--- ヘッダー 
Content-Type：application/json 
Authorization：Bearer [アクセストークン]

3. 続いて、ボディのサンプルは、以下の通りです。ticketIdVariable はフローで新規リソースで設定した変数名です。TID01359 の部分をオンデマンド的に差し替えて、様々なチケット ID を送信対象にできます。

{ 
"inputs" : [ {
   "ticketIdVariable" : "TID01359"
   } ] 
}

4. 設定が完了すると、以下のような形になります。赤枠の部分がポイントになる箇所です。

5. 問題なければ、送信をクリックします。

6. 200（成功）でレスポンスが返されたことを確認します。

7. フローで送信を確認すると、セグメントで静的な条件で指定した時のカウントと同じ数が送信されていることが分かります。成功です。

これらの機能が生み出す価値

Dynamic Segments と Broadcast Flows を活用することで、企業は 運用通知・サービス通知をほぼリアルタイムで配信 できます。

✔ 顧客満足度の向上
✔ ブランドへの信頼性強化
✔ 不要な問い合わせ（サービスケース）の削減

特に “今すぐ知らせたい” というシーンで強力に機能します。以下は Salesforce が用意しているユースケースです。

ユースケース紹介

1. 運用通知（Operational Notifications）

  • フライトのゲート変更通知を対象顧客へ即時送信

  • 雷雨が接近しており、パーク内の全顧客へ閉園アナウンスを行いたい場合

2. サービス通知（Service Notifications）

  • 複数地域の郵便番号でネットワーク障害が発生
    　→ 影響が出る前に事前通知し、問い合わせ発生を抑制したい

  • 設備点検エリアの対象者へ事前案内を送信

いかがでしたでしょうか。

頻繁に一括へのリアルタイム送信が求められる企業にとっては、注目すべき新機能だと思います。以下の点に再度注目してみてください。

  • 配信タイミングで条件を動的に差し替えられる

  • セグメントをまとめてリアルタイム通知できる

  • サービス通知・運用通知で即戦力

  • 顧客体験と業務効率の両面でメリットが大きい

まだデバッグ機能や待機要素が未対応など、改善の余地はありますが、とても強力な機能であることは間違いありません。

なお、今回のブロードキャストフローは、サブフロー（子フロー）の対象にもなります。親フローからもトリガーできることを覚えておきましょう。

ぜひ、自社のオペレーションに活用してみてください。

今回は以上です。


次の記事はこちら

前回の記事はこちら

私の note のトップページはこちら