リクエスト
Offering Token
開始前にホストがsi_get_offering 参照を行った場合、セッション継続性 のためトークンを含めます:
- ユーザーが見る: “Nike Pegasus (129), Vomero ($139)”
- ユーザーが言う: “真ん中のものについて詳しく教えて”
- ブランドエージェントはトークンに保存されたコンテキストを用いて「真ん中のもの」→ Air Max と解釈します
Sponsored Context Receipt
ホストがセッション前の照会からのスポンサードコンテキストを受け入れた、または明示的に拒否した場合、ホストの境界決定をブランド/セラーに見えるようにするためにsponsored_context_receipt を含めます。
受け入れられたレシートは、使用モードをダウンスコープしたり、必要な開示を辞退したりできません。いずれの条件も尊重できないホストは、代わりにスポンサードコンテキストを拒否します。拒否されたレシートは
accepted_context_use と disclosure_commitment を省略しなければなりません。
Identity オブジェクト
consent_granted が true の場合:
consent_granted が false の場合:
Supported Capabilities オブジェクト
ホストプラットフォームがレンダリングできるものを宣言します:レスポンス
Response オブジェクト
例
リクエスト
レスポンス
キーポイント
- コンテキストは会話ハンドオフ - ホストがブランドエージェントにユーザーのニーズを伝え、ブランドエージェントが自然に会話を続けます。
- ブランドがロイヤルティデータを参照 - Jane のメールが認識されれば、Delta が SkyMiles ステータスを自動取得します。ホストはロイヤルティ番号を保持しません。
- offering_id はブランド固有 - ブランドがこの参照を解釈し、プロモーションや割引、ロイヤルティ特典を適用します。ホストはオファーの意味を理解せずに渡すだけです。
-
機能ネゴシエーション - レスポンスの
negotiated_capabilitiesには、このセッションで利用できる機能(ブランドとホストの交差)が示されます。 -
明示的同意のある PII 受け渡し -
consent_grantedが true の場合、実際のメール/名前が渡されます(ハッシュなし)。これは同意に基づく直接のハンドオフです。