【第640回】 Marketing Cloud Next ： Send Time Attributes の分析方法

2026年10月31日 07:31

前回の記事では、Marketing Cloud Next の Send Time Attributes を利用し、メッセージの送信時に任意のデータを記録する方法を紹介しました。

そこでは、フライトの搭乗ゲート変更を例に、予約番号、便名、変更前のゲート、変更後のゲートを記録しました。

保存された内容は、次のような JSON 文字列です。

{"BookingNumber":"BK-002","FlightNumber":"NH456","PreviousGate":"C05","CurrentGate":"D08"}

この情報を使って「NH456 に関する通知を確認したい」「予約番号ごとに通知履歴を一覧にしたい」と考えたときには、それぞれの値を独立した項目として扱えると便利です。

今回は、Data 360 の Batch Data Transform（バッチデータ変換） を利用して、JSON 文字列から必要な値を取り出す方法を解説します。

最終的には、それらの値をデータエクスプローラーや CRM レポートで確認したいと思います。

① 送信時の情報を残すと、何に役立つのか

まず、送信時の値を残す意味を整理しておきます。

Send Time Attributes のメリットは、「誰に送ったか」に加えて、「どの予約や契約に関する通知だったか」「そのとき、どの値を案内したか」を、後から確認しやすくなることです。

今回のフライトの例であれば、次のような場面で役立ちます。

「ゲート変更の案内が来ていない」と問い合わせがあった場合：予約番号と便名を手掛かりに、対象の通知履歴を探せます。そのうえで、配信結果などの履歴と組み合わせて状況を確認します。
ゲートが C05 → D08 → E12 と複数回変わった場合：それぞれの通知時に、どのゲートを案内したかを確認できます。現在の予約データが E12 に更新されていても、以前の通知に記録された D08 は、その時点の値として参照できます。
誤ったゲートを案内した可能性がある場合：記録された属性を使い、誤った値が記録されている通知や、訂正案内が必要な対象を調べる手掛かりにできます。
ひとりのお客様が複数の予約を持っている場合：顧客 ID だけでは判断しにくい「どの予約についての連絡か」を、予約番号で区別できます。

同じ考え方で、保険なら保険証券番号、EC なら注文番号、プロモーションなら個別のクーポンコードを残す用途にも応用できます。

一方で、全員に同じ内容を送るメルマガなどでは、追加属性を記録するメリットは比較的小さいかもしれません。予約・契約・注文などにひも付く通知や、個別の値を案内するメッセージで、使い道が明確になる機能ですね。

なお個別の問い合わせに対して、データエクスプローラーを使って対象の履歴を開き、JSON の値を確認するだけであれば、必ずしも列への変換は必要ありません。

今回の変換は、あくまで 予約番号や便名を独立した項目として一覧表示・絞り込み・集計したい場合に、そのためのデータを用意するものです。

② バッチデータ変換とは

バッチデータ変換は、Data 360 にあるデータを読み込み、必要な加工を行い、その結果を別のデータオブジェクトに保存する機能です。

画面上に処理を表す「ノード」を配置し、データをどの順番で加工するかを設定します。不要な行の除外、複数のデータの結合、値の計算などを組み合わせることができます。

今回使用するのは、Flatten JSON という変換です。１つの項目に保存されている JSON 文字列から、指定した属性を列として取り出します。

つまり、前回の記事が「送信時の情報を残す設定」だったのに対し、今回は 「残した情報を検索や分析に使いやすい形に整える設定」 です。

バッチデータ変換は手動で実行でき、定期実行の設定も可能です。メール送信と同時に変換される仕組みではないため、分析用データの更新タイミングは別途考える必要があります。

③ 今回作成するデータ

今回の例では、前回記録した 4 つの値を、次のような列として取り出します。

BookingNumber（予約番号）：BK-002
FlightNumber（便名）：NH456
PreviousGate（変更前のゲート）：C05
CurrentGate（変更後のゲート）：D08

※ 上記は、前回の JSON を展開した場合の出力イメージです。

変換後は、FlightNumber が NH456 のデータに絞り込んだり、BookingNumber を指定して確認したりするための項目として利用できます。

ただし、実際の出力には、この 4 項目だけでなく、元の履歴レコードを識別する ID、日時、イベント種別なども必要です。

同じ予約に対して、搭乗ゲートの変更通知を 2 回送る場合もあります。そのため、予約番号だけでは、個々の送信履歴を一意に識別できません。

今回の設計では、元の履歴レコードとの対応を維持しながら、送信時の 4 属性を列として追加することを目指します。

④ スキーマファイルを用意する

Flatten JSON には、JSON の構造を定義した スキーマファイル を使用します。

前回の記事で紹介した、設定の Send Time Attributes 画面にある Download Schema から取得するファイルです。ビジネスユニットの Send Time Attributes 画面からも、対象のスキーマをダウンロードできます。

今回のファイルは、次の内容になっています。

{
  "type": "object",
  "properties": {
    "BookingNumber": {
      "type": "string"
    },
    "CurrentGate": {
      "type": "string"
    },
    "FlightNumber": {
      "type": "string"
    },
    "PreviousGate": {
      "type": "string"
    }
  }
}

このファイルには、BK-002 や NH456 といった実際の値は入っていません。

「BookingNumber という属性があり、その値は文字列である」といった、JSON を読み取るための構造が定義されています。

今回の 4 属性は、すべて string、つまり文字列です。予約番号やゲート番号は数字を含んでいても計算対象ではありませんので、文字列として扱います。

データ変換には、実際の値を持つデータと、その読み取り方を定義するスキーマの両方が必要になります。

⑤ Email Engagement を入力として使用する

今回は、Email Engagement DMO から直接データを読み込み、JSON を展開した結果を新しい分析用 DMO に保存する構成にします。

今回の環境では、Add Input Data で Engagement カテゴリの Email Engagement DMO を選択できます。

最終的に表示する項目は、次の 8 つです。

Email Engagement Id
Engagement Date Time
Individual Id
Sendtime Email Address
BookingNumber
FlightNumber
PreviousGate
CurrentGate

前半の 4 項目は元の DMO から引き継ぎ、後半の 4 項目は Send Time Attributes の JSON から取り出します。

なお、Engagement Date Time は、その履歴に記録されたエンゲージメントの発生日時です。送信日時として扱う場合は、対象のイベント種別を確認する必要があります。

⑥ バッチデータ変換を作成する

1. Data Transforms タブを開き、新規をクリックします。

2. Batch Data Transform を選択します。

3. Data Model Objects と Data Space を選択します。

4. Add Input Data から Email Engagement を選択します。

入力として、次の 6 項目を選択します。

Email Engagement Id
Key Qualifier Email Engagement Id
Engagement Date Time
Individual
Sendtime Email Address
Send Time Attributes

※ Key Qualifier Email Engagement Id は、最後に保存するために必要です。

⑦ Send Time Attributes がある履歴だけを抽出する

今回は、Send Time Attributes が記録されている履歴だけを変換し、フライト予約の属性を持つ履歴を専用 DMO に保存します。

最終的な処理の順番は、次のとおりになる想定です。

Input：Email Engagement DMO から読み込む
Filter：Send Time Attributes が空の行を除外する
Transform／Flatten JSON：JSON から 4 つの属性を取り出す
Filter：BookingNumber が空の行を除外する
Output：指定の 9 項目を専用 DMO に保存する

1. Input でプレビューデータを用意する

データ変換を効率良く設定するには、プレビューデータをどれだけしっかりと揃えられるかになります。プレビューデータの数は 500 行でも良いですが、少なくとも今回の対象データが適切に混ざるように設定します。

2. 最初のフィルターを設定する

Input ノードの後ろに、Filter ノードを追加して、＋ボタンをクリックして、Send Time Attributes を選択します。

ここでは、以下 2 つのフィルター条件を設定して、Send Time Attributes に値があるレコードに限定します。

フィルター名：Send Time Attributes IS NOT NULL

Send Time Attributes が NULL ではない（is not null）
Send Time Attributes が空文字ではない（does not equal）

※「空欄」の設定の仕方は、以下のように「空欄」になっている箇所を選択して、チェックを付けて設定します。

3. Flatten JSON を設定する

続いて、Filter ノードの後ろに Transform ノードを追加します。

1. Send Time Attributes 項目のアクションボタンから、Flatten Data ＞ Flatten JSON を選択します。

2. Upload File から SendTimeAttributes_schema.json を指定します。

3. 変換の名前（例：Send Time Attributes）を入力したら、Add New Table をクリックします。

4. テーブル名（例：SendTimeAttributes・・・アルファベット以外禁止）を入力して、BookingNumber、FlightNumber、PreviousGate、CurrentGate のすべてを抽出する属性として選択します。

5. Apply をクリックします。

4. JSON 展開後のフィルターを設定する

続いて、もう 1 つ Filter ノードを追加します。

Send Time Attributes は、別の用途でも使用できるため、JSON が入っているだけでは、今回のフライト予約に関する履歴とは限りません。

ここまでくると、BookingNumber がフィルター条件に使えるようになるので、今回は抽出した BookingNumber に対し、次をすべて満たす条件を設定します。

フィルター名：BookingNumber IS NOT NULL

BookingNumber が NULL ではない（is not null）
BookingNumber が空文字ではない（does not equal）

※「空欄」は Add new value で何も入力せずに、チェックボタンをクリックすると生成できます。

このフィルターのプレビューで、前回のテスト履歴から次の値が取り出されていることを確認します。

BookingNumber：BK-002
FlightNumber：NH456
PreviousGate：C05
CurrentGate：D08

あわせて、Email Engagement Id、Engagement Date Time、Individual Id、Sendtime Email Address の 4 項目が、同じ履歴の値として出力ブランチに引き継がれていることを確認します。

⑧ Output ノードから新しい DMO を作成する

BookingNumber の条件を設定した 2 つ目の Filter ノードの後ろに、Output ノードを追加します。

これにより、Send Time Attributes を持ち、かつ BookingNumber に値がある履歴だけが、今回の出力対象になります。

今回は Create New を選択し、新しい DMO を作成します。名前は、例えば
「Flight Notification Send Attributes」など、内容が分かるものにします。

Create New：Output ノードから、新しい Transform 型 DMO を作成します。
Use Existing：すでにある、出力先として利用可能な Transform 型 DMO を選択します。

元の Email Engagement DMO に項目を追加して、そこへ書き戻す構成ではありません。データ変換から直接書き込める DMO は Transform 型の DMO に限られます。

その他は、以下で設定します。

Write Mode：Upsert
Object Name：Flight Notification Send Attributes
Object API Name：Flight_Notification_Send_Attributes
Object Category：Other
Object Description：任意
Primary Key：Email Engagement Id
Key Qualifier：Key Qualifier Email Engagement Id

※ Upsert は、毎回入力データを読み込み、出力へマージする方式です。増分処理だけになる設定ではありません。

※ 中央の項目入力欄は DMO の項目名になります。自由に変更できます。

設定ができたら、保存します。

バッチデータ変換名：Flight Notification Send Attributes
定義名：Flight Notification Send Attributes Definition

⑨ 手動で実行して結果を確認する

保存が終わったら、データ変換のトップページに戻って、一覧から対象の変換を選択し、ステータスが Active になっていることを確認したら Run Now を実行します。

処理完了後、データエクスプローラーで作成した出力先 DMO を開き、次の 8 項目を選択し、表示します。

Email Engagement Id
Engagement Date Time
Individual Id
Sendtime Email Address
BookingNumber
FlightNumber
PreviousGate
CurrentGate

不正な形式の JSON を持つ行は、Flatten JSON の結果に含まれないと公式ヘルプに記載されています。件数が想定と異なる場合は、入力の JSON とフィルター条件を確認してください。

⑩ CRM レポートで確認する

今回の構成では、フィルターで対象を選び、変換結果を新しい専用 DMO に直接保存しています。

CRM レポートでは Data Cloud の DMO を使ったレポートも可能です。

CRM レポートでも、データエクスプローラーと同じ８項目を表示する構成にします。

例えば、CRM レポートのフィルターを使って、現場では次のような確認ができると考えられます。

BookingNumber を指定し、特定の予約に関する通知履歴を確認する。
FlightNumber で絞り込み、対象便の履歴を一覧表示する。
Sendtime Email Address で、送信時のメールアドレスを確認する。
Engagement Date Time で並べ替え、記録されたゲート番号を時系列で確認する。

CRM レポートであれば、比較的ユーザーが使いやすい形になりますね。

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

Send Time Attributes によって、メッセージの送信時に使用した業務データを残せるようになりました。

さらに、Batch Data Transform の Flatten JSON を組み合わせることで、保存した属性を予約番号や便名などの独立した項目として扱うための準備ができます。

個別の履歴を確認するだけであれば、JSON のままでも利用できます。一覧での検索や集計が必要になった段階で、今回の変換を組み合わせるとよいと思います。

送信時の情報を何のために残し、どの頻度で確認するのか。その目的に合わせて、変換するデータの範囲や更新頻度を決めておくことが大切ですね。

今回は以上です。