Real-Time 2.0によって処理されたすべてのイベントは、同時に2つの独立したストレージ先に書き込まれます。
| ストレージレイヤー | 保存されるデータ | 更新速度 | 確認方法 |
|---|---|---|---|
| Real-Time Layer | セッション内行動データ、リアルタイムアトリビュート、ステッチされたIDリンク | イベントインジェスト後ミリ秒 | Personalization APIを使用するか、ペアレントセグメント設定ページでRealtime Storageを確認 |
| Batch Layer | 完全なイベント履歴、集計アトリビュート、予測スコア、完全な顧客プロファイル | ワークフロースケジュールに応じて数分〜数時間 | Data WorkbenchでイベントテーブルをQuery |
リアルタイムデータが受信されていることを確認するには、Data Workbenchを使用して基になるイベントテーブルに直接クエリを実行し、未加工のイベントがTreasure Dataストレージに届いていることを確認してください。
概念的な概要については、リアルタイム ID Stitching 概要を参照してください。
Real-Time 2.0のプロファイル統合は2段階のプロセスです。
ステップ1 – ID Stitching（Realtime Decision Engine）
イベントが到着すると、Realtime Decision Engineは即座に現在のユーザーの識別子（匿名Cookie ID、デバイスID、メールハッシュ、またはその他の設定されたキー）を既存の顧客プロファイルに紐付けようとします。これはミリ秒単位で行われ、デバイスやセッションをまたいで持続する統合IDを生成します。
ステップ2 – プロファイル統合（Unify Realtime and Batch Data）
IDが解決された後、エンジンはライブのセッション内データとBatch Storageからの顧客の履歴プロファイルをマージします。この統合プロファイル（リアルタイムアトリビュートと履歴メトリクスの両方を含む）が、パーソナライゼーションとアクティベーションの意思決定を機能させます。
IDステッチングキーとマッチングに使用されるアトリビュートは、ID Stitching設定のペアレントセグメントで設定します。ステッチングキーへの変更は、設定がデプロイされた後、新しいイベントに対してすぐに有効になります。
Real-Time 2.0は、異なる目的を持ち互いを補完する2つの処理パイプラインを実行します。
| Realtime Pipeline | Batch Pipeline | |
|---|---|---|
| トリガー | 到着するすべてのイベント | スケジュール（数分〜数時間） |
| 速度 | ミリ秒 | 数分〜数時間 |
| 処理するデータ | 個別のイベント、セッション内行動 | 完全なイベント履歴、大規模な集計 |
| 出力 | 更新されたリアルタイムアトリビュート、パーソナライゼーション決定、トリガーアクティベーション | 集計アトリビュート、予測スコア、オーディエンスセグメント |
| 最適な用途 | 顧客が今行っていることへの対応 | 完全な履歴に基づいた顧客の理解 |
統合された意思決定の例： 顧客が製品ページを閲覧すると、Realtime Pipelineは即座に行動を検出し、パーソナライズされたレコメンデーションをトリガーします。そのレコメンデーションは、Batch Pipelineが提供する顧客の購買履歴、ロイヤルティランク、および予測ネクストベストオファーでエンリッチされ、タイムリーかつコンテキストに即した意思決定が実現します。
2つのパイプラインのどちらかを選択する必要はありません。すべてのイベントは自動的に両方を流れます。
エンドツーエンドのレイテンシーSLA
| 機能 | レイテンシー | 備考 |
|---|---|---|
| Personalization API | ≤ 100ms（p95） | リアルタイムアトリビュートルックアップとバッチプロファイルマージを含むAPIリクエストからレスポンスまでの時間 |
| トリガーアクティベーション | 最大3分 | イベントインジェストからダウンストリームチャネルへのアクティベーション配信までの時間 |
| バッチ処理 | 数分（ワークフロースケジュールによって異なる） | ワークフロー設定とデータ量によって異なる |
スループット容量
| コンポーネント | デフォルト容量 | 最大（グローバル） |
|---|---|---|
| イベントインジェスト | 2,000 events/second | 100,000+ events/second |
| リアルタイム意思決定 | 8,000 events/second | — |
| トリガーアクティベーション | 8,000 events/second | — |
予想されるイベント量がデフォルトのインジェスト上限の2,000 events/secondを超える場合は、Treasure Dataのアカウントチームに連絡して容量の調整についてご相談ください。上限は設定可能で、高トラフィックのユースケースをサポートするようスケールできます。
Lookup Catalog を使うと、RT 2.0 パーソナライゼーションがリクエスト時に、product_id などのユーザー以外のディメンションをキーとした外部ビジネスデータ（商品カタログ・クーポン定義・セールスケジュールなど）を参照できます。ユーザーごとの値を保持するプロファイルアトリビュートとは異なり、Lookup Catalog は「このユーザーについて何を知っているか」ではなく「このユーザーにとって、この商品について何を知っているか」に答えます。
商品・SKU・クーポン・その他のユーザー以外のディメンションによって変化するデータをパーソナライゼーションのレスポンスに含める必要がある場合に使用します。たとえば、ユーザーがカートに追加した商品に対応するクーポンが存在する場合のみクーポンリマインダーを表示する、といったユースケースに最適です。
詳細なセットアップ手順は Lookup Catalog を参照してください。
リアルタイムデバッグ用 AI スキルを使用してください。これらのスキルは、アクティベーション配信エラー、プロファイルマージの問題、ステッチングキーの品質、ジャーニー実行の問題を調査するための診断クエリを生成します。開始するにはペアレントセグメント ID を指定してください。