スナップショットとイベントストリーム
データは、スナップショット（状態）とイベントストリーム（何が起きたか）の2つの基本カテゴリに分類されます。この違いを理解し、正しく適用することは、Decisioning Studioエージェントが効果的に学習するために最も重要なことの1つです。
スナップショットデータ（状態）
スナップショットは、特定の時点における顧客の状態を表します。「この顧客は今どのような状態か？」という質問に答えるものです。
スナップショットは静的で集約されたものです。その時点までのすべての変更の累積結果を反映します。顧客プロファイル、計算済みフィーチャー（例：「最終購入からの日数」「ロイヤルティティア」「チャーンスコア」）に最適です。
必須フィールド
| フィールド | 目的 |
|---|---|
| 顧客識別子 | このレコードが誰を記述しているか |
| スナップショット日付 | このスナップショットがいつ取得されたか |
スナップショットの更新方法
- トリガー： イベント駆動ではなく、時間駆動です。スナップショットは、その日に顧客のアクティビティがあったかどうかに関係なく、固定スケジュール（例：毎日）で生成する必要があります。
- スコープ： すべての更新には、イベントがなかった顧客を含む、すべての関連顧客を含める必要があります。
- 方法： 以前の値を上書きするのではなく、新しいスナップショットレコードをデータセットに追加します。これにより、モデルトレーニング用の履歴状態が保持されます。
日次配信用のスナップショットデータのクエリ
Decisioning Studioはおすすめパイプラインを1日1回実行します。スナップショットデータを配信する際は、各パイプライン実行時に前日のスナップショットをエクスポートします：
1
2
3
SELECT *
FROM snapshot_data
WHERE snapshot_date = {t-1} -- on pipeline run date t, export the snapshot from t-1
イベントストリームデータ（フロー）
イベントストリームは、個別のアクションを発生時に記録します。「この顧客は何をしたか、いつしたか？」という質問に答えるものです。イベントストリームは、生の、不変の、増分的で、時系列のデータに最適です。各レコードは、特定の時点で発生した1つの出来事を表します。例えば、このデータストリームはアクティベーションレコード、エンゲージメントログ（開封、クリック数）、コンバージョンイベント、またはクーポン利用に使用します。
必須フィールド
| フィールド | 目的 |
|---|---|
| 顧客識別子 | このイベントが誰に関するものか |
| イベントタイプ | 何が起きたか（例：アクティベーション、コンバージョン、クリック） |
| イベントタイムスタンプ | イベントが実際に発生した日時 |
| 作成タイムスタンプ | このレコードがシステムに作成された日時（以下の注記を参照） |
| イベントプロパティ | イベントに関する追加メタデータ。これが豊富であるほど、Decisioning Studioはカスタマージャーニー全体でイベントをより適切にリンクできます |
イベントタイムスタンプと作成タイムスタンプは異なるフィールドであり、両方とも必須です。イベントタイムスタンプは、アクションが実際に発生した日時を記録します。作成タイムスタンプは、データエントリがシステムに書き込まれた日時を記録しますが、処理の遅延により後になる場合があります。この2つを混同しないでください。
イベントストリームの更新方法
- トリガー： イベント駆動です。新しいイベントが発生すると、新しいレコードが追加されます。
- スコープ： イベントがあった顧客のみが新しいレコードを取得します。
- 方法： 既存のレコードは不変です。更新は常に新しいレコードの挿入です。
日次配信用のイベントデータのクエリ
日次エクスポートのスライスには、event_timestampではなくcreate_timestampを使用してください。イベントは発生後にシステムに書き込まれることがあります（遅延到着）。event_timestampでスライスすると、遅延到着したレコードが永久に欠落します。
1
2
3
4
-- 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
1
2
3
4
-- 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に渡さないでください。
よくある問題
イベントデータをスナップショットとして渡す
イベントデータをDecisioning Studioに送信する前にスナップショットフィールドに集約すると、いくつかの問題が発生します：
- 粒度の喪失： データが日次の顧客レベルのサマリーに集約されると、個々のイベントレコードは失われます。Decisioning Studioはそれらを再構築できません。
- 不正確なタイムスタンプ： 「last_email_sent」のようなフィールドは最新の発生を示しますが、イベントの完全な履歴が失われ、正確なアトリビューションが不可能になります。
- ファントム更新： イベントが発生しなかった日でもスナップショットレコードが更新され、重複排除が困難な重複エントリが作成されます。
Brazeを使用している場合は、生のイベントデータをDecisioning Studioに配信するために、カスタム属性ではなくCurrentsエクスポートを使用してください。
イベントトリガーでスナップショットデータを更新する
一部の実装では、イベントが発生した場合にのみスナップショットデータを更新します。例えば、顧客が購入した場合にのみフィーチャーを再計算するなどです。これにより、時間の経過に依存するフィーチャーが、最近イベントがなかった顧客に対して古くなります。
例えば、days_since_last_purchaseのようなフィーチャーは、毎日異なる正しい値を持ちます。購入が発生した場合にのみ再計算される場合、最近購入していないすべての顧客に対して不正確な値で固定されます。スナップショットデータは、すべての顧客を毎日カバーする時間駆動のスケジュールで常に更新してください。