# Real-Time 2.0を始める

このガイドでは、Real-Time 2.0を正常に実装するために必要な前提条件、セットアップワークフロー、設定の制限、およびベストプラクティスについて説明します。このガイドを使用して、Real-Time 2.0のデプロイを計画および実行してください。

| カテゴリ | 制限 / 動作 | 注記 |
|  --- | --- | --- |
| IDステッチングキー | 最大100個のIDをステッチングキーとして定義可能 | 例: email、user_id、td_client_id。プロファイルへのイベントのリンクに使用されます。 |
| バッチID同期(初期化) | オプション。バッチIDグラフをリアルタイムにインポートして継続性を確保できます | 既存のバッチIDをリアルタイムで利用可能にする必要がある場合に推奨されます。 |
| プロファイルキー(プライマリID) | ペアレントセグメント作成時に定義。後で変更できません | バッチデータとリアルタイムデータ間の主要な結合キーを決定します。 |
| イベントテーブル | ペアレントセグメントあたり最大100個のイベントテーブル | バッチおよびリアルタイムのイベントテーブルの両方に適用されます。 |
| イベント定義 | ハード制限なし | 定義全体の集約フィルター長は1000文字以内である必要があります。 |
| アトリビュートバックフィル | バッチアトリビュートでサポート | バックフィルを使用して、既存のバッチデータの値でRTアトリビュートを事前入力します。 |
| バッチアトリビュートのインポート | サポート | バッチテーブルに新しく追加されたフィールドは、セグメントの更新後に利用可能になります。 |
| 新しいイベントフィールド | データベースで自動的に利用可能 | パーソナライゼーションまたはトリガーで使用するには、RTアトリビュートとして明示的に設定する必要があります。 |
| マルチアカウントデプロイ | CI/CDパイプライン経由でサポート | 設定を1つの環境からエクスポートして、別の環境で再利用できます。 |


## 期待される動作

* バッチID同期: 必須ではありませんが、既存のバッチIDをリアルタイムに移行する場合に推奨されます。
* プロファイルキー: ペアレントセグメント設定時に選択され、その後固定されます。
* アトリビュート: バックフィルを使用すると、RTアトリビュートに履歴値を入力できます。新しいフィールドは自動的にシステムに流入しますが、アクティベーションまたはパーソナライゼーションで使用するには明示的な設定が必要です。
* アカウント間のデプロイ: 複数の環境間で一貫した設定を確保するために、CI/CDプロセスを通じてサポートされます。


## 注記と推奨事項

* リアルタイムを有効にする前に、プロファイルキー戦略を計画して、やり直しを避けます。
* 既存のバッチセグメントでリアルタイムを有効にする場合は、アトリビュートバックフィルを使用します。
* マルチ環境デプロイを簡素化するために、CI/CDで設定を管理します。
* 新しいバッチまたはイベントフィールドを定期的に確認して、RTアトリビュートとして昇格させるかどうかを決定します。