スナップショットとイベントストリーム
データは、スナップショット（状態）とイベントストリーム（何が起きたか）という2つの基本カテゴリのいずれかに分類されます。この違いを理解して正しく適用することは、Decisioning Studio Proエージェントが効果的に学習できるようにするために最も重要なことの1つです。
スナップショットデータ(状態)
スナップショットは、特定の時点における顧客の状態を表します。これは「この顧客は現在どのような状態か?」という問いに答えるものです。
スナップショットは静的で集計されたデータです。その時点までのすべての変更の累積結果を反映します。ユーザープロファイルや計算済みの特徴量(たとえば「最終購入からの日数」「ロイヤルティティア」「チャーンスコア」など)に最適です。
必須フィールド
| フィールド | 目的 |
|---|---|
| 顧客識別子 | このレコードが表す顧客 |
| スナップショット日 | このスナップショットが取得された日時 |
スナップショットの更新方法
- トリガー:時間駆動型です。固定のスケジュール(たとえば毎日)でスナップショットを生成し、その日にアクティビティがなかった顧客も含めます。
- 範囲:すべての更新には、イベントがなかった顧客を含む、関連するすべての顧客を含める必要があります。
- 方法:以前の値を上書きするのではなく、新しいスナップショットレコードをデータセットに追加します。これにより、モデルトレーニング用の過去の状態が保持されます。
日次配信用のスナップショットデータをクエリする
Decisioning Studio Proは、レコメンデーションパイプラインを1日に1回実行します。スナップショットデータを配信する際は、各パイプライン実行時に前日のスナップショットをエクスポートしてください。
SELECT *
FROM snapshot_data
WHERE snapshot_date = {t-1} -- on pipeline run date t, export the snapshot from t-1
イベントストリームデータ（フロー）
イベントストリームは、個別のアクションを発生と同時に記録します。「この顧客がいつ、何をしたか」という問いに答えるものです。イベントストリームは、未加工で不変、増分的かつ時系列のデータに最適です。各レコードは、特定の時点で発生した1つの出来事を表します。たとえば、アクティベーション記録、エンゲージメントログ（開封、クリック）、コンバージョンイベント、クーポンの利用などにこのデータストリームを使用します。
必須フィールド
| フィールド | 目的 |
|---|---|
| 顧客識別子 | このイベントの対象となる顧客 |
| イベントタイプ | 何が起きたか（アクティベーション、コンバージョン、クリックなど） |
| イベントタイムスタンプ | イベントが実際に発生した日時 |
| 作成タイムスタンプ | このレコードがお客様のシステムで作成された日時（次のセクションの注記を参照） |
| イベントプロパティ | イベントに関する追加のメタデータ。情報が豊富であるほど、Decisioning Studio Proはカスタマージャーニー全体でイベントをより適切に関連付けられます |
イベントタイムスタンプと作成タイムスタンプは別のフィールドであり、どちらも必須です。イベントタイムスタンプは、アクションが実際に発生した日時を記録します。作成タイムスタンプは、データエントリがお客様のシステムに書き込まれた日時を記録します。処理の遅延により、こちらのほうが遅くなる場合があります。この2つを混同しないでください。
イベントストリームの更新方法
- トリガー: イベント駆動型。新しいイベントが発生すると、新しいレコードが追加されます。
- 範囲: イベントが発生した顧客のみに新しいレコードが作成されます。
- 方法: 既存のレコードは変更されません。更新は常に新しいレコードの挿入として行われます。
日次配信用にイベントデータをクエリする
日次エクスポートは create_timestamp で区切ってください。イベントは発生後にお客様のシステムに書き込まれることがあります（遅延到着）。event_timestamp で区切ると、遅れて到着したレコードは永久に取りこぼされます。
-- Correct: use create_timestamp to ensure late-arriving events are captured
SELECT *
FROM events_data
WHERE DATE(create_timestamp) = {t-1} -- on run date t, export all records created yesterday
-- Incorrect: slicing on event_timestamp will permanently lose late-arriving events
SELECT *
FROM events_data
WHERE DATE(event_timestamp) = {t-1}
たとえば、1月1日に発生したイベントが1月2日までお客様のシステムに書き込まれなかった場合、1月2日に event_timestamp で区切るとそのイベントは完全に取りこぼされます。create_timestamp で区切れば、正しく取得できます。
ネイティブBrazeインテグレーションの場合
Brazeには、これら2つのデータタイプに直接対応する2つの組み込みメカニズムがあります。
カスタム属性: スナップショットデータ
カスタム属性は、ある時点におけるユーザーレベルの状態を保存します。ユーザープロファイルや算出された特徴量 (たとえば、churn_score、total_purchases_last_30d) に使用します。更新のたびに以前の値が上書きされるため、属性には最新の状態が保持され、それ以前のイベントは失われます。
Braze Currents: イベントストリームデータ
Braze Currentsは、変更不可能な生のイベントフローデータを提供します。USER_BEHAVIOR_CUSTOM_EVENTS テーブルは、カスタムイベントが発生するたびにそのすべてのインスタンスを記録するため、アクティベーション、エンゲージメント、コンバージョンイベントの正しいソースとなります。
カスタム属性を顧客の状態のソースとして、Braze Currentsを顧客行動イベントのソースとして扱ってください。生のイベントデータをDecisioning Studio Proに渡すためにカスタム属性を使用しないでください。
よくある問題
イベントデータをスナップショットとして渡す
イベントデータをDecisioning Studio Proに送信する前にスナップショットフィールドに集約すると、いくつかの問題が発生します。
- 粒度の喪失: データが顧客単位の日次サマリーに集約されると、個々のイベントレコードは失われます。Decisioning Studio Proはそれらを再構築できません。
- 不正確なタイムスタンプ: 「last_email_sent」のようなフィールドは直近の発生を示しますが、イベントの完全な履歴が失われるため、正確なアトリビューションができなくなります。
- ファントム更新: イベントが発生しなかった日でもスナップショットレコードが更新されるため、重複除去が難しい重複エントリが作成されます。
Brazeを使用している場合は、Currentsエクスポートを使用して生のイベントデータをDecisioning Studio Proに配信してください。
イベントトリガーでスナップショットデータを更新する
一部の実装では、イベントが発生したときにのみスナップショットデータを更新します。たとえば、顧客が購入したときにのみ特徴量を再計算するケースです。この場合、時間の経過に依存する特徴量が、最近イベントのない顧客について古いままになってしまいます。
たとえば、days_since_last_purchase のような特徴量は、毎日異なる正しい値を持ちます。購入が発生したときにのみ再計算されると、最近購入していないすべての顧客について誤った値のまま固定されてしまいます。スナップショットデータは、すべての顧客を対象とした時間ベースのスケジュールで毎日必ず更新してください。