一般原則

適切に構造化されたデータは、効果的なDecisioning Studioエージェントの基盤です。個々のアセット要件に入る前に、Decisioning Studioに送信するすべてのデータに適用される4つのコア原則を理解しておくと役立ちます。これらの原則のいずれかに違反することは、モデルパフォーマンス低下の最も一般的な原因の一つです。

すべてのアセットで一貫した顧客識別子を使用する

すべてのデータアセット（顧客プロファイル、アクティベーション、エンゲージメント、コンバージョン）は、同じ顧客識別子を参照する必要があります。すべてのアセットにわたって各顧客をユニークかつ一貫して識別するプライマリ識別子が正確に1つ存在する必要があります。

使用する識別子に関するガイダンスについては、Braze external IDを使用するを参照してください。

イベントデータはスナップショットではなく、増分ストリームとして渡す必要がある

コンバージョン、エンゲージメント、アクティベーションなどのイベントは、特定の時点で発生した個別の事象を表します。これらはDecisioning Studioに対して、集約されたスナップショットではなく、増分（追記のみ）の個別レコードストリームとして配信する必要があります。

この区別の詳細な説明と、正しいパターンおよび誤ったパターンの例については、スナップショットとイベントストリームを参照してください。

スナップショットデータは定期的な時間ベースのスケジュールで更新する必要がある

スナップショットデータ（顧客プロファイルや特徴量など）は、特定の時点における顧客の現在の状態を表します。スナップショットデータの更新は、イベントトリガーではなく、定期的なスケジュール（例えば毎日）によって駆動される必要があります。

すべてのアセットは最低限のデータ品質と整合性の要件を満たす必要がある

構造だけでなく、データ自体が内部的に一貫しており、有用であるために十分に完全である必要があります。

特にイベントストリームデータの場合、各レコードには最低限以下が含まれている必要があります。

必須フィールド:

• 顧客識別子
• イベントが発生した時点のタイムスタンプ（システムでレコードが作成された時点ではありません。これらは異なります。なぜ重要かについてはスナップショットとイベントストリームを参照してください）
• システムでレコードが作成された時点のタイムスタンプ（増分エクスポートを確実にスライスするために使用されます）
• イベントタイプ
• 関心のある特定のイベントに絞り込むのに十分なフィールド

推奨フィールド:

• イベントタイプ間の確実なマッチングを可能にする追加のイベントメタデータ（例えば、コンバージョンイベントをそれに先行した特定のアクティベーションにリンクする）