このタスクを使うタイミング
SI セッションを開始する有効なフローは 2 つあります。フロー A: セッション前の照会(スポンサード結果に推奨)
offering_token がセッション前のコンテキストを橋渡しするため、「2 つ目のもの」といった参照が成立します。
例: 検索結果ページで、ユーザーがエンゲージする前に「Nike にはあなたのサイズのランニングシューズが 3 足あり、$89 から」と表示します。
フロー B: 直接セッション
si_get_offering は 同意前の匿名プレビュー 用です。すぐにセッションへ進むなら省略できます。
目的
オファーの照会には 3 つの目的があります。- 提供内容の提示 - 同意前に価格、提供可否、説明を表示します
- 一致する商品の提示 - コンテキストがあれば、関連商品を返す
- セッション継続性 - 返されるトークンで提示内容を保持し、セッション開始時にブランドエージェントが文脈を把握できるようにします
リクエスト
プライバシー
このリクエストには個人を特定できる情報を含めてはいけません。context フィールドには意図の説明を記載できますが、匿名である必要があります(例: “mens size 14 near Cincinnati” は可、メールアドレスは不可)。
レスポンス
Offering Object
Matching Product Object
Sponsored Context 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:ブランドエージェントがトークンを使う方法
offering_token を生成する際は、クエリの状態をサーバーサイドに保存します。
si_initiate_session でトークンを受け取ったら:
セッション開始時にトークンを含めます
提供内容を取得した後にセッションを開始する場合、トークンを含めます。重要ポイント
- 匿名設計 - 提供内容の照会にはユーザーデータを送信しません。プライバシーを守りつつリッチなプレビューを実現します。
- セッション継続性 - Offering トークンは提示内容の記憶です。「最初の選択肢」や「あの青いもの」といった参照をブランドエージェントが解決できます。
-
商品マッチング -
include_productsが true でcontextがあれば、ブランドは関連商品を返せます。「あなたのサイズの靴が 12 足、$89 から」といったプレビューを実現します。 -
キャッシュ - ホストは
ttl_secondsまでレスポンスをキャッシュできます。頻繁に照会されるオファーでブランドエージェントの負荷を下げます。 - 段階的なフォールバック - 照会が失敗またはタイムアウトしても、ホストはセッションを直接開始できます。照会は必須ではありません。
-
代替提案 - 提供不可の場合は
alternative_offering_idsを通じて代替案を提示できます。
ベストプラクティス
ホスト向け
- スポンサード結果を表示する前に提供内容を取得します
- リッチなプレビューにはコンテキスト付きで
include_productsを使います - TTL を守ってキャッシュし、古いデータを避ける
- 提供不可の場合の扱いを丁寧にし、期限切れのオファーを表示しません
- 可能であればセッション開始時に offering トークンを含めます
ブランドエージェント向け
- 正確な表示のためにリッチな
offering情報を返す - コンテキストに合わせた商品マッチングのため
include_productsをサポートします - 妥当な TTL 値を設定する(変動に応じて 5~60 分など)
- デバッグに役立つ
unavailable_reasonを提供します - 主要なオファーが利用できない場合は代替案を提案します