リアルタイム ID ステッチング概要

データ識別子は、処理層（データの収集方法と収集タイミング）と ID タイプ（個人識別情報を含むかどうか）によって分類されます。

重要な注記： 既知 ID と未知 ID の区別は、純粋に識別子の タイプ に関するものです。既知 ID と未知 ID の両方が、処理のためにリアルタイム層またはバッチ層のいずれかを経由して流れる可能性があります。

Real-Time 2.0 はリアルタイムで ID ステッチングを実行します。複数のイベントが異なる列にまたがる一致する ID とともにリアルタイム層を流れると、システムはそれらの識別子を即座に単一のプロファイルに統合します。そのリアルタイムプロファイルは、バッチペアレントセグメントからコピーされた ID と属性で強化されるため、リアルタイム層は常にバッチアクティベーションと同じ統合された顧客ビューで動作します。

つまり、事前に統合されたプロファイルによるリアルタイムエンリッチメントを行うだけではありません。イベントがストリーミングされる際に、リアルタイムで ID を統合しています。

リアルタイム層は、既知 ID と未知 ID の両方を含むストリーミングイベントを受信し、一致する識別子が検出されると即座にそれらをステッチします。

例：

Event 1: { email: "user@example.com", cookie_id: "abc123" }
Event 2: { cookie_id: "abc123", device_id: "xyz789" }
Event 3: { email: "user@example.com", session_id: "session456" }

リアルタイム層は、3 つのイベントすべてが同じ顧客に属していることを認識し、即座にそれらをステッチします。

主なポイント：

• ID ステッチングは、イベントが到着するとエンタープライズグレードのサブセカンドレイテンシで行われます
• 既知 ID と未知 ID の任意の組み合わせで機能します
• スケジュールされたバッチワークフローの完了を待つ必要がありません
• ステッチが完了すると、統合された ID はすべての将来のイベントで利用可能になります

バッチ層は、スケジュールされた Treasure ワークフロー を通じて履歴イベントデータを処理し、履歴的な顧客プロファイルの信頼できる情報源として機能します。バッチプロファイル属性（ロイヤルティティア、生涯価値、購入履歴など）は、リアルタイム層がオンデマンドで読み取る共有データストアに同期されます。

主なポイント：

• スケジュール（毎時、毎日、またはカスタム）に基づいて履歴イベントデータを処理します
• 集約された属性を含む包括的な顧客プロファイルを構築します
• すべての履歴データにまたがる ID 統合を実行します
• リアルタイム層へのアップロードに必要なデータセットを作成します

バッチワークフローによる ID ステッチング： 統合されたゴールデン層が完成したら、それらの ID をリアルタイム層に昇格させるワークフローを追加する準備ができています。Treasure Data の CSM がこの軽量な Treasure ワークフロー を提供します。これは、既存のエンドツーエンドのオーケストレーションにクリーンに組み込めるよう設計されています。

バッチプロファイル属性は、リアルタイム層がオンデマンドで読み取る共有データストアに同期されます。これにより、リアルタイム層は以下の恩恵を受けます：

1. リアルタイムステッチング — ライブイベントから即座に統合された ID
2. バッチプロファイルのエンリッチメント — バッチ層からの履歴属性（ティア、生涯価値、購入履歴）

リアルタイムステッチングでは、各プロファイルに最大 200 個のユニーク ID を保持できます。この上限は、プロファイルに過剰な数のステッチ済み ID が蓄積されるのを防ぐことで、データ品質とシステムパフォーマンスの両方を保護します。

オーバーステッチングは、あまりにも多くの ID が誤って 1 つのプロファイルにリンクされた場合に発生します。これは、十分に一意でない値をステッチングキーとして使用することが最も一般的な原因です。たとえば、汎用的なリージョン ID や共有デバイス識別子をキーとして使用する場合などです。オーバーステッチングは、顧客プロファイルの大幅な不正確さにつながり、重大な場合にはシステムパフォーマンスの低下を引き起こす可能性があります。

プロファイルが 200 個のユニーク ID に達した状態で新しい ID が追加されると、システムは新しい ID を受け入れ、上限内に収まるよう最も古い ID を先に排出します。正当に多くのキーが 1 つのプロファイルに属している場合（たとえば、非常にアクティブなユーザーが 200 個以上の Cookie ID を生成する場合）、最も古い ID はシームレスに削除され、通常は既に関連性のないものです。

バッチ統合 ID（バッチ ID 統合中に割り当てられる正規の永続的な識別子）は、RT プロファイルキーの最も強力な候補です。設計上、バッチプロファイルの論理的な主キーであり、プロファイルキーが満たすべき 3 つの要件をすべて満たしています：

• 必須 — すべてのバッチプロファイルが持っています
• 一意 — 正確に 1 つのプロファイルを識別します
• 永続的 — 正しく管理された入力時間値を持つ永続的な ID 統合によって設定された場合、バッチ統合 ID は時間とともに安定したままであり、Journey での使用に適しています

シナリオ 1：以前は匿名だった訪問者のパーソナライゼーション

最初は匿名の訪問者がウェブサイトに到着します。リアルタイムエンジンは、その未知 ID（cookie_id）をバッチ層の対応する ID（device_id）と照合します。このバッチ層の ID は、既知の顧客 ID（email）にリンクされています。これにより、確立されたロイヤルティステータスに基づいて、訪問者のエクスペリエンスを即座にパーソナライズできます。

シナリオ 2：クロスデバイス認識

顧客が複数のチャネルでブランドと関わる場合、最初はモバイルアプリを使用し（device_id と email で識別）、後でウェブサイトを訪問する（cookie_id と email で識別）とき、リアルタイムシステムは共有されたメールアドレスに基づいてこれら 3 つの個別の識別子を自動的に統合します。この即時ステッチングにより、バッチ処理層に頼ることなく、1 日の過程でリアルタイムにオムニチャネルの ID グラフが作成され、アプリとウェブの両方で一貫してパーソナライズされたエクスペリエンスが実現します。

シナリオ 3：ロイヤルティティアの計算

顧客が店舗の POS システムを使用して購入を完了し、リアルタイムエンジンにイベントが送信されます。同時に、顧客はロイヤルティプログラムに登録し、ウェルカムメールが送信されます。POS 情報と登録データを受信すると、リアルタイムエンジンは顧客のロイヤルティティアを計算します。登録したばかりにもかかわらず、顧客の購入履歴はプラチナティアの基準を満たすとして即座に認識され、ブロンズからの即時アップグレードが行われます。これにより、顧客はプラチナ会員にふさわしい高品質なサービスを受けることができます。