Skip to main content

バイヤーブリーフと get_products リクエスト形状

このサプリメントは、バイサイドの実装者が人間のキャンペーンリクエストを正確な get_products 呼び出しに変えられるよう準備します。 ゴールはブリーフを冗長にすることではありません。ゴールは意図をブリーフに、ハードな制約を型付きフィールドに置くことで、セラーがどの部分が交渉可能か推測せずに在庫をキュレートできるようにすることです。

メンタルモデル

ブリーフに入るもの

セラーまたはキュレーターが判断を下すのに必要なコンテキストにブリーフを使います:
  • キャンペーン目的: 認知、検討、適格トラフィック、来店、コンバージョン、更新
  • 人間の言葉でのオーディエンス記述
  • 製品、オファー、季節的コンテキスト、またはクリエイティブの方向性
  • ファミリー適合性や競合隣接性のような、理解必須の機微
  • メトリックフィルターではない成功言語、例えば「信頼される編集環境を優先」
例:

フィルターに入るもの

条件に失敗する製品が返ってくるべきでないときにフィルターを使います。 良いフィルター候補:
  • 必須チャネルまたはフォーマット
  • 必須ジオターゲティングサポート
  • 必須の測定またはレポートケイパビリティ
  • 価格通貨制約
  • 予算範囲
  • 固定価格要件
  • ホールセール / カタログ用途の製品カテゴリー
例:
バイヤーが「理想的には CTV だが、ディスプレイでも OK」と言うなら、その選好をブリーフに保ちます。「CTV のみ」と言うなら、filters.channels を使います。

ブリーフ対 refine

バイヤーが以前のディスカバリーレスポンスに反応しているときは buying_mode: "refine" を使います。refine リクエストは何が変わったかを指すべきです: 製品を削除、予算を調整、よりプレミアムなプレースメントをリクエスト、地理を絞る、または代替を求める。 refine に完全に新しいキャンペーンを送らないでください; 代わりに新しい brief リクエストを開始します。

実装チェックリスト

  • セラーを呼ぶ前に、人間のリクエストを意図、ハードな制約、フォローアップの変更に正規化する。
  • バイヤーのビジネス言語を brief に保つ; それをキーワードだけに崩さない。
  • 型付き制約を filters に置き、セラーが filter_diagnostics を通じて除外を説明できるようにする。
  • briefwholesale モードから外す。
  • 後の refine 呼び出しと wholesale_feed_version 比較が正しくスコープされるよう、リクエストタプルをレスポンスとともに永続化する。

練習プロンプト

バイヤーが言います:
Acme Meals の新しいファミリーディナーキットのための 6 週間のローンチが必要。CTV またはオンラインビデオが欲しく、USD 価格のみ、子供のいる親に適したもの、そして完了率レポートが必要。
期待される分解:
  • ブリーフ: ファミリーディナーキットのローンチ、親オーディエンス、適したコンテキスト、6 週間のローンチ。
  • フィルター: ビデオ対応チャネル / フォーマット制約、USD 価格、完了率レポート。
  • ブランド: Acme Meals ドメインまたは BrandRef。