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

## 用語

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

### 処理層

| 用語 | 定義 | 特性とユースケース |
|  --- | --- | --- |
| **リアルタイム層** | ストリーミングイベントがリアルタイムで到着するとデータを処理します。 | インタラクションの時点（ウェブサイト、アプリ）で即座にキャプチャされます。即時パーソナライゼーション、セッション追跡、リアルタイム意思決定に不可欠です。 |
| **バッチ層** | スケジュールされた統合ワークフローを通じてデータを処理します。 | スケジュールされた間隔または大きなグループで収集、処理、取り込まれます。多くの場合、オフラインソース（POS、CRM）または履歴データからのものです。永続的な顧客プロファイル、履歴レコード、バックエンド分析の構築に重要です。 |


### ID タイプ

| 用語 | 定義 | 主な機能と例 |
|  --- | --- | --- |
| **既知 ID（PII）** | 個人識別情報；特定の個人を直接または間接的に識別できます。 | **アドレサビリティ**（メール、SMS による積極的なリーチ）および**クロスチャネルマッチング**（デバイス/プラットフォームをまたいだ決定論的な統合）に重要です。例：メールアドレス、電話番号、顧客 ID、氏名。 |
| **未知 ID（非 PII）** | 匿名識別子；PII を含みません。 | サイト分析、行動セグメンテーション、プログラマティック広告の基盤となります。既知 ID が提供されるまで匿名性を維持しながら、ユーザーの行動とデバイスを追跡するために不可欠です。例：Cookie ID、デバイス ID、匿名セッショントークン。 |


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

## 機能概要

Real-Time 2.0 はリアルタイムで ID ステッチングを実行します。複数のイベントが異なる列にまたがる一致する 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. **バッチプロファイルのエンリッチメント** — バッチ層からの履歴属性（ティア、生涯価値、購入履歴）


## プロファイルあたりの ID 上限

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

### オーバーステッチングとは？

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

### 上限の仕組み

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

パージされた ID
バルクデータは削除されませんが、リアルタイムシステム内でのプロファイルとの関連付けはパージされます。ID を再関連付けするには、新しい受信イベントからプロファイルが自然に再構築されるか、ID グラフワークフローをスケジュールで実行して関連する ID グラフを再アップロードする必要があります。

## RT ID ステッチングの設定

### RT プロファイルキーの選択

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

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


Note
バッチ統合 ID は、リアルタイム層でバッチプロファイル属性を検索・取得するために使用されます。受信するリアルタイムイベントデータのステッチングキーとしては**使用されません**。ライブイベントのステッチングは、設定した RT ステッチングキー（メール、Cookie ID、デバイス ID など）を使用して実行されます。

## ユースケース

### Real-Time 2.0 プラットフォームが価値を発揮する場面

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

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

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

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

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

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

### バッチのみの統合に対する利点

| 側面 | バッチのみ | Real-Time 2.0 |
|  --- | --- | --- |
| **ID 統合速度** | 数時間（次のバッチ実行まで） | 数秒 |
| **匿名から既知への移行** | 次のバッチまで遅延 | 即時 |
| **クロスデバイスステッチング** | 遅延 | リアルタイム |
| **初回訪問時のパーソナライゼーション** | 以前のバッチ実行のデータに限定 | 顧客が一致する ID を提供するとすぐに利用可能 |
| **アクティベーショントリガー** | バッチ完了後 | 発生と同時に |