# リアルタイム パーソナライゼーション APIについて

パーソナライゼーションAPIは、パーソナライゼーションサービスを設定し、ユーザーのアクティビティに基づいてパーソナライズされたレスポンスを返すことを可能にするエンドポイントのコレクションです。現在、設定エンドポイントは「Treasure Data内部使用のみ」であり、TD Customer Successチームがパーソナライゼーション環境をセットアップするために使用しています。(将来的には、これらのAPIの機能がTreasure コンソールユーザーインターフェースに追加される可能性があります。)アカウントのパーソナライゼーションが設定された後、パーソナライゼーションサービスがそれに対して動作できるように、TDで顧客情報を更新するために呼び出すAPIは単純に次のようになります。

`{{personalizationBaseUrl}}/:database/:table`

お客様の地域のパーソナライゼーションAPIのbaseURLを確認するには、[Treasure API baseURLs](/apis/endpoints/endpoints)を参照してください。

以下は、リアルタイムパーソナライゼーションAPIを使用してアカウントを設定し、新しい顧客データをアップロードまたは更新する方法の内訳です。

## フェーズ1. パーソナライゼーションルーティングの確立

- **API利用可能性:** 内部使用のみ(Treasure Dataが処理)
- **何が起こるか:** ルーティングAPI呼び出しは、パーソナライゼーションサービスが監視すべきデータベーステーブルを登録します。
- **ペイロード例**



```json
"add": {
  "destinations": [
    {
      "database": "reactor",
      "table": "page_views"
    }
  ]
}
```

## フェーズ2. パーソナライゼーション設定の定義とアップロード

- **API利用可能性:** 内部使用のみ(Treasure Dataが処理)
- **何が起こるか:** YAML設定が準備され、プロビジョニングAPIを通じてアップロードされます。ファイルは、キー、イベント、アトリビュート、オファー、アクティベーション、トークンを定義します。詳細については、[設定ファイルセクションの説明](/ja/products/customer-data-platform/real-time/about-the-real-time-personalization-api#contentsYAMLfile)を参照してください。
- **トークンガイダンス:** 1つ以上の認証トークンを生成し(例: ダッシュを削除したUUID v4)、プロビジョニング前に設定に埋め込むためにTreasure Dataと共有します。フェーズ3の例に示されているトークンは、UUID `e65d8a9d-f209-4f02-b84c-d660efff6f27`から派生しています。


## フェーズ3. パーソナライゼーションエンドポイントへのイベント送信

- **エンドポイント:** `{{personalizationBaseUrl}}/:database/:table`
- **リクエスト例**



```bash
curl -i --header 'Content-Type: application/vnd.treasuredata.v1+json' \
--header 'wp13n-token: 1/8/e65d8a9df2094f02b84cd660efff6f27' \
--header 'Authorization: TD1 1/abcdef•••••••••••••••••••••••0123456789' \
-X POST \
-d '{"td_client_id":"202", "some_key":"some other data"}' \
--location https://eu01.p13n.in.treasuredata.com/your_database/pageviews
```

パーソナライゼーションエンドポイントに送信されたイベントは、他のTreasure Dataイベントと同様にPlazmaに取り込まれます。さらに、パーソナライゼーションサービスは、イベントを送信したプロファイルに合わせたレスポンスを返す場合があります。

## フェーズ4. パーソナライゼーションレスポンス処理

- **API利用可能性:** 内部使用のみ(Treasure Dataが処理)
- **何が起こるか:** イベントが監視対象テーブルにコミットされた後、パーソナライゼーションエンジンは設定(例: offersセクション)を評価し、アクションを実行するかどうかを決定します。
- **設定例:** 次のスニペットは、プロファイルに既に保存されているpreferencesがある場合にトリガーされるオファーを示しています。



```yaml
offers:
- name: "preferences_known"
  set:
    - event: "pageview"
      if: PROFILE.preferences.length > 0
  data:
    td_client_id: ${PROFILE.td_client_id}
    preferences: ${PROFILE.preferences.slice(-1)[0].value}
```