Skip to main content
セッション開始前に提供内容の詳細や提供可否、必要に応じて一致する商品を取得します。これにより、ホストはブランドとの連携について同意を求める前に、ユーザーへリッチなプレビューを提示できます。

このタスクを使うタイミング

SI セッションを開始する有効なフローは 2 つあります。

フロー A: セッション前の照会(スポンサード結果に推奨)

同意を求める前に商品を見せたい場合に使用します。offering_token がセッション前のコンテキストを橋渡しするため、「2 つ目のもの」といった参照が成立します。 : 検索結果ページで、ユーザーがエンゲージする前に「Nike にはあなたのサイズのランニングシューズが 3 足あり、$89 から」と表示します。

フロー B: 直接セッション

ユーザーがすでにエンゲージする意図を示している場合に使います。ブランドエージェントがセッション内で商品を提示し、何を提示したかを内部で追跡します。 : ユーザーが「Nike とランニングシューズの話をしたい」と言う場合は、事前取得は不要でそのままセッションを開始します。 重要な違い: si_get_offering同意前の匿名プレビュー 用です。すぐにセッションへ進むなら省略できます。

目的

オファーの照会には 3 つの目的があります。
  1. 提供内容の提示 - 同意前に価格、提供可否、説明を表示します
  2. 一致する商品の提示 - コンテキストがあれば、関連商品を返す
  3. セッション継続性 - 返されるトークンで提示内容を保持し、セッション開始時にブランドエージェントが文脈を把握できるようにします

リクエスト

プライバシー

このリクエストには個人を特定できる情報を含めてはいけません。context フィールドには意図の説明を記載できますが、匿名である必要があります(例: “mens size 14 near Cincinnati” は可、メールアドレスは不可)。

レスポンス

Offering Object

Matching Product Object

返された offering または matching_products がホスト境界に入るスポンサードコンテキストである場合、レスポンスレベルで sponsored_context を含めます。返されるパッケージ全体に適用されます。 matching_products が比較、ランキング、または選択のためのスポンサード候補セットである場合は context_use: "comparison_set" を使います。別個のスポンサードユニットまたはハンドオフには presentation_only を、コンテキストがホストの回答生成、プランニング、ランキング、またはその他の推論に利用可能であることを意図する場合にのみ reasoning_context を使います。パッケージを受け入れるホストは、監査証跡が支払いプリンシパル、宣言された使用モード、開示義務、ホストレシートをリンクするよう、後続の si_initiate_session リクエストに sponsored_context_receipt を含められます。

Unavailable Reasons

基本的な提供内容の照会

Response

商品コンテキストを付与

商品を含むレスポンス

これによりホストは次のように提示できます。
「Nike にはあなたのサイズのランニングシューズが 12 足あり、$89 からです。アシスタントと詳しく見てみますか?」

Response with Sponsored Context

提供不可の場合のレスポンス

Offering トークンの利用

offering_tokenセッション継続性 の鍵です。si_get_offering で商品を表示した後に会話を開始するとき、このトークンによりブランドエージェントは何が提示されたかを正確に把握できます。

セッション継続性が重要な理由

Without the token, this conversation breaks:
With the token, the brand agent can reconstruct the full context:

ブランドエージェントがトークンを使う方法

offering_token を生成する際は、クエリの状態をサーバーサイドに保存します。
si_initiate_session でトークンを受け取ったら:

セッション開始時にトークンを含めます

提供内容を取得した後にセッションを開始する場合、トークンを含めます。

重要ポイント

  1. 匿名設計 - 提供内容の照会にはユーザーデータを送信しません。プライバシーを守りつつリッチなプレビューを実現します。
  2. セッション継続性 - Offering トークンは提示内容の記憶です。「最初の選択肢」や「あの青いもの」といった参照をブランドエージェントが解決できます。
  3. 商品マッチング - include_products が true で context があれば、ブランドは関連商品を返せます。「あなたのサイズの靴が 12 足、$89 から」といったプレビューを実現します。
  4. キャッシュ - ホストは ttl_seconds までレスポンスをキャッシュできます。頻繁に照会されるオファーでブランドエージェントの負荷を下げます。
  5. 段階的なフォールバック - 照会が失敗またはタイムアウトしても、ホストはセッションを直接開始できます。照会は必須ではありません。
  6. 代替提案 - 提供不可の場合は alternative_offering_ids を通じて代替案を提示できます。

ベストプラクティス

ホスト向け

  • スポンサード結果を表示する前に提供内容を取得します
  • リッチなプレビューにはコンテキスト付きで include_products を使います
  • TTL を守ってキャッシュし、古いデータを避ける
  • 提供不可の場合の扱いを丁寧にし、期限切れのオファーを表示しません
  • 可能であればセッション開始時に offering トークンを含めます

ブランドエージェント向け

  • 正確な表示のためにリッチな offering 情報を返す
  • コンテキストに合わせた商品マッチングのため include_products をサポートします
  • 妥当な TTL 値を設定する(変動に応じて 5~60 分など)
  • デバッグに役立つ unavailable_reason を提供します
  • 主要なオファーが利用できない場合は代替案を提案します