【第240回】 Data Cloud ： イベント時刻項目 と レコード変更済み項目 解説
Salesforce Data Cloud でデータストリームを作成する際、「イベント時刻項目」（Event Time Field）と「レコード変更済み項目」（Record Modified Field）は非常に重要な設定項目です。これらの項目は、データストリームの設定の中で、以下の箇所で設定されます。
これらの項目の役割と適切な設定方法を理解していないと、大きな事故に繋がります。今回の記事では、その 2 つを比較しながら理解してみましょう。
この記事は、データストリームの設定に関連するため、過去の記事「データエクステンション連携の更新方法を理解する」や「Date 型と DateTime 型における設定のポイント」にも関連してきます。これらとセットで理解することをオススメします。
基本
イベント時刻項目（Event Time Field）
選択可能なカテゴリ：エンゲージメント
設定：必須
設定すべき項目：将来変更されない日付（作成日、イベント日など）
レコード変更済み項目（Record Modified Field）
選択可能なカテゴリ：プロファイル、エンゲージメント、その他
設定：任意
設定すべき項目：ファイル処理の順序を整える日付（最終更新日）
フル更新と更新/挿入 における違い
フル更新の場合：「イベント時刻項目」と「レコード変更済み項目」は、どちらも適用されません。
更新/挿入の場合：「イベント時刻項目」と「レコード変更済み項目」が、適用されます。
1. イベント時刻項目
概要
「イベント時刻項目」（Event Time Field）は、Id 項目に追加された サブプライマリーキー のような役割を果たします。
対象データ型：DateTime データの他、Date データも利用可能
選択可能カテゴリ：エンゲージメントのみ
更新方法：更新/挿入 を選択した場合のみ適用されます。フル更新でも選択する必要はありますが、適用されず、意味を持ちません。
重要なシステム項目「cdp_sys_PartitionDate」について
「イベント時刻項目」として選択された DateTime データ、または Date データは、自動的に作成される「cdp_sys_PartitionDate」に記録されます。
この「cdp_sys_PartitionDate」は、数式項目（Date or DateTime）です。
イベント時刻項目で選択した日付項目の値が入力されますが、DateTime の場合は、以下の数式により「時分秒」は 00:00:00 に変換 されます。
DAYPRECISION(formulaField['イベント時刻項目 API 参照名']);この数式の処理は「タイムゾーン変換」前の値を基に行われます。この説明を分かりやすくするために、以下の表の A001 のレコードを例にします。
今回の「イベント時刻項目」として設定された Created_Date は、2025/1/20 19:00:00（UTC）でインポートされました。
数式によって「時分秒」が 2025/1/20 00:00:00（UTC）に変換されます。
その後、タイムゾーン変換で 2025/1/20 09:00:00（JST）となります。
結果として、cdp_sys_PartitionDate は 2025/1/20 09:00:00 です。
Data Cloud の DataTime 型で発生する「タイムゾーン変換」については、以下の記事で説明しています。
「イベント時刻項目」のシステム処理の仕組み
それでは、この「イベント時刻項目」は、cdp_sys_PartitionDate を使って、どのような処理を行うのでしょうか。それは、以下のような処理です。
■ イベント時刻項目データが cdp_sys_PartitionDate が一致する場合
⇒ 既存レコードが「上書き更新」の対象になります。
■ イベント時刻項目データが cdp_sys_PartitionDate と一致しない場合
⇒ 別の新しいレコードとして「挿入」されます。
注意点
cdp_sys_PartitionDate との 日付 が少しでも異なれば、プライマリーキーが同じであっても、別のレコードが新たに作成されます。
インポートした日付データと cdp_sys_PartitionDate の日付の比較は、数式により「時分秒」が 00:00:00 に変換された後に、比較されます。よってインポートデータが、翌日を跨ぐまでは、数式の結果は、同じ日付に帰結するため、新しいレコードが重複して挿入されることはありません。
新しいレコードが重複して挿入される場合は、別のレコードの話となるので、下の 2 で説明する「レコード変更済み項目」は、当然無視されます。
結論と推奨設定
レコードを上書く想定で更新を行いたい場合は、例えば「レコード作成日」「商品購入日」「メールの開封日」「メールのクリック日」など、将来的に変更されない 日付/日時項目 を選択するようにしてください。
一度、イベント時刻項目を確定すると、別の項目には変更はできませんので、事前に入念な検討が必要となります。
2. レコード変更済み項目
概要
「レコード変更済み項目」（Record Modified Field）とは、レコードの上書き処理を実行して良いかを判断する項目です。
この「レコード変更済み項目」は、インポートされると、ハイウォーターマーク（最大値）として設定されます。このハイウォーターマークを基準にして、各レコードの上書き処理の可否が判断されます。
対象データ型：DateTime データのみ利用可能（Date 型は不可）
選択可能カテゴリ：プロファイル、エンゲージメント、その他
更新方法：更新/挿入 を選択した場合のみ適用されます。フル更新でも選択する必要はありますが、適用されず、意味を持ちません。
動作ルール
既存データの日時を 1 秒でも上回る場合：上書き処理が実行されます。
日時が一致する場合や下回る場合：上書き処理されず、無視されます。
例を挙げますと、現在の「レコード変更済み項目」が 2025/2/19 10:25:45 の場合、同じプライマリーキーを持つレコードを更新する際のルールは以下の通りです：
2025/2/19 10:25:46 以上の値を持っている場合
レコードが上書き更新されます。2025/2/19 10:25:45 以下の値の場合
レコードの更新は無視されます。
設定が不要なケース
以下の状況では「レコード変更済み項目」の設定は不要と思われます。
データファイルが、必ず順序通りに処理される想定の場合
どのような順序でデータファイルを処理しても良い場合
結論と推奨設定
ファイル処理の順序が乱れる可能性がある環境では、「レコード変更済み項目」を設定することでデータ整合性を保つことができます。この項目は、一般的には「レコード最終更新日」を採用します。
3. 両項目の処理の順番
これは言うまでもありませんが、「イベント時刻項目」には、サブプライマリーキーのような役割がありますので、「イベント時刻項目」が先に処理されて、その後に「レコード変更済み項目」が処理されます。
先の処理：「イベント時刻項目」
後の処理：「レコード変更済み項目」
注意点
イベント時刻項目データが cdp_sys_PartitionDate と一致せず、別の新しいレコードが作成された場合は、これは完全な新規レコード扱いとなるため、比較する「レコード変更済み項目」が無いと見做されて、プライマリーキーが重複する形でレコードが作成されます。
4. ハイウォーターマーク（最大値）の違い
データの抽出や処理におけるハイウォーターマークの動作には、対象データソースによる違いがあります。
■ Cloud Storage （Google Cloud Storage など）ファイル連携の場合
ハイウォーターマークは、今回の記事で説明してきた「レコード変更済み項目」によって、各「レコード単位」で管理されます。
■ データエクステンション連携の場合
データエクステンションのハイウォーターマークは「データエクステンション抽出項目」で選択されます。
そして、ハイウォーターマークは「データエクステンション単位」で管理されます。つまり、データエクステンション内の「データエクステンション抽出項目」が「昇順」で並び変えられ、その最大値が記録されるわけですね。
ちなみに、データエクステンションのハイウォーターマークは、Email Studio ＞インタラクションタブ ＞ データファクトリーユーティリティーで管理 されていることも、以下の記事で説明しました。
この両者の違いはしっかりと認識しておいてください。
いかがでしたでしょうか。
再度、簡単にまとめておきます。
イベント時刻項目：サブプライマリーキーの役割を果たし、日付の一致が上書き更新のトリガーとなる。日付の不一致は、同じプライマリーを持つレコードの重複を発生させる原因となる。
レコード変更済み項目：選択された項目の日時の比較に基づき、各レコードにおけるハイウォーターマーク（最大値）を上回った場合は、更新処理を許可する。それ以外の場合は、無視されて処理されない。
これらの項目の設定を正確に理解し、データ整合性の確保や処理パフォーマンスの向上に役立ててください。
今回は以上です。
