sponsored_placement 正準は、リテールメディアのカタログ駆動クリエイティブ — Amazon SP、Criteo SP、CitrusAd SP、Pinterest Collection、generative-per-SKU — をカバーします。スキーマはバイナリ軸(composition_model、fanout_mode、item_production_model)を捕捉しますが、ランタイムコントラクト — ファンアウトセマンティクス、カタログアセット配線、アダプターごとのトラッキング — はアダプターファミリー間で十分に異なるため、sponsored_placement に対して検証されるマニフェストは、それが特定のリテールメディアネットワークで実際にサーブするかどうかについてバイヤーにほとんど伝えません。
このページは、4 つのコントラクトファミリー、その現在の実験的準備状況、スキーマに存在しないアダプター固有の癖を文書化します。正準は、少なくとも 2 つのリテールメディアネットワークが format_schema 証拠を出荷するまで、3.1 GA を過ぎても experimental: true のままです(canonical-formats.mdx §experimental — 1 フィールド、両軸 を参照)。
4 つのコントラクトファミリー
1. リテールメディア決定的、バイヤーアップロード(Amazon SP)
バイヤーはsync_creatives 経由でカタログアセット(製品画像、ヘッドライン、説明)をアップロードします。リテールメディアネットワークはカタログ行 + アセットを取り込み、クエリ/カテゴリートリガーに対して決定的にサーブします — レンダー時のファンアウトなし。バイヤーはインプレッションごとのレンダリングを予測できます。
- カタログアセットコントラクト: バイヤーはカタログアイテムごとに 1 クリエイティブを供給。
source_catalogスロットはバイヤーの製品フィードを指す。アイテムごとのアセットが必要。 - トラッキング: Amazon ASIN + 標準リテールメディアイベント語彙。アイテムごとのアトリビューションはカタログ行の識別子にマップ。
- アダプターの癖: Amazon のカテゴリートリガーシステムは、同じアップロードされたクリエイティブが異なるカテゴリーコンテキストの下でサーブされうることを意味します — バイヤーはインプレッションレベルのカテゴリーをクリエイティブ形状によって信頼できないものとして扱わなければなりません(MUST)。カテゴリーアトリビューションには Amazon のレポートに依存します。
- 実験的準備状況: サンドボックスと制御されたアダプター使用に十分予測可能。最も予測可能なファミリー。Amazon からの
format_schema証拠は非実験的への昇格をサポートするでしょう。
2. リテールメディアネットワーク合成(Criteo SP、CitrusAd SP)
バイヤーはブリーフ + ブランドアセット(ロゴ、ブランドカラー)を供給します。リテールメディアネットワークは自身のカタログ + デザインテンプレートに対してプレースメントを合成します。バイヤーはアセットバンドルレベルではインプレッションごとのレンダリングを予測できず、ブランドディレクションレベルでのみ予測できます。- カタログアセットコントラクト: バイヤーはブリーフ + ブランドアセットを供給。
source_catalogは セラーの カタログ(リテールメディアネットワークの製品インデックス)で、バイヤーのものではありません。バイヤーの製品参照は SKU / GTIN / カテゴリー経由でセラーカタログ行に一致されます。 - トラッキング: リテールメディアネットワーク自身のイベント語彙。バイヤーアトリビューションは直接クリエイティブイベントではなくネットワークのレポート API を通じてマップ。
- アダプターの癖: Criteo の合成ロジックはリテーラー統合によって変わります — 同じバイヤーブリーフが Criteo 経由で Walmart 対 Target 対 Best Buy で異なるプレースメントを生成します。バイヤーはリテーラーごとのレンダリングを不透明として扱い Criteo の集計レポートに依存しなければなりません(MUST)。
- 実験的準備状況: 制御されたアダプター使用に適する。合成の不透明性が非実験的昇格へのギャップです —
format_schema証拠がリテーラーごとの変動性を文書化する必要があります。
3. インプレッションごとコレクションレイアウト(Pinterest Collection、Snap Collection)
バイヤーはヒーロー画像 + カタログアイテムのコレクションを供給します。表面はインプレッションごとにコレクションレイアウト(グリッド、カルーセル、カバー + リビール)を選びます。composition_model: deterministic はアセットレベルでは技術的に真ですが、レイアウトレベルでは緩いです。
- カタログアセットコントラクト: バイヤーはヒーローアセットスロット + アイテム配列(各アイテム: 画像 + キャプション + URL)を持つ 1 クリエイティブを供給。
source_catalogスロットはバイヤーのキュレートされたアイテムコレクションで、完全な製品フィードではありません。 - トラッキング: Pinterest のコレクションアイテムイベント(
collection_item_click、collection_close_up)プラス標準インプレッション/クリック。アイテムごとのアトリビューション利用可能。レイアウトバリアントアトリビューションは公開されません。 - アダプターの癖: Snap Collection の「カバー + リビール」レイアウトは特定のアスペクト比とアセット数の組み合わせを要求します — スキーマは強制しません。バイヤーは同期前に事前検証すべきです(SHOULD)。
- 実験的準備状況: 制御されたアダプター使用に適する。「決定的」クレームはアセットレベルで生き残りますが、レイアウト変動性が、表面ごとの適合性証拠なしの非実験的昇格をブロックします。
4. Generative-per-SKU(ベンダー固有)
バイヤーはブリーフ + カタログ参照を供給します。セラーの生成パイプラインが SKU ごとにユニークなクリエイティブを生成します。1 ブリーフ × N カタログアイテム → N レンダーされたクリエイティブ。composition_model は deterministic のままです。なぜなら各レンダーされたアイテムは配信前に生成され、次に生成されたとおりにサーブされるからです。生成メカニズムは item_production_model: "agent_synthesized" で捕捉されます。
- カタログアセットコントラクト: バイヤーはブリーフ + カタログスコープ(SKU、カテゴリー、または完全なフィード)を供給。セラーは
item_production_model: agent_synthesizedとfanout_mode: per_itemでbuild_creative経由でクリエイティブを生成。source_catalogスロットはバイヤーの製品フィード。アセットはセラー生成。 - 非決定性: このファミリーの製品は、QA ループが完了する前に生成がスペック内出力を保証できないとき
synthesis_nondeterministic: trueを宣言すべきです(SHOULD)。 - トラッキング: 生成出力 ID + バイヤーのカタログアイテムキー(SKU/GTIN)。バイヤーは各生成されたクリエイティブを、ブリーフのコピーではなく、自身のパフォーマンスシグナルを持つ別個のレンダー出力として扱うべきです(SHOULD)。
- アダプターの癖: 生成シードとプロンプトは通常バイヤーに返されません。バイヤーは特定の生成を再現できません。アセット編集サイクルではなく再生成サイクルを計画します。
- 実験的準備状況: 生成品質証拠がアダプターごとに文書化されるまで
experimental: trueのままにします。制御された使用は可能ですが、合成はバイヤーに不透明でベンダーごとのフレーミングが必要です。
実験的準備状況マトリクス
experimental は正準と製品宣言の両方に存在します。フィールドレベルコントラクトについては canonical-formats.mdx §experimental — 1 フィールド、両軸 を参照してください。
このページが何でないか
- 規範的仕様拡張ではない。 4 つのファミリーは既存の
sponsored_placementスキーマを共有します。この文書は、セラーとバイヤーが正準に対して遭遇する変動性を名指しますが、必須フィールドを追加しません。 - 昇格ゲートではない。 正準の非実験的への昇格は、canonical-formats.mdx に従い、少なくとも 2 つのアダプター全体の
format_schema証拠にゲートされます。このページはformat_schema証拠が各ファミリーについて何をカバーする必要があるかを文書化します。 - 網羅的ではない。 ランタイムコントラクトが上の 4 つのファミリーの 1 つに適合しないアダプターは、マトリクスを拡張できるよう canonical-formats トラックに issue を提出すべきです(SHOULD)。
参照
- #3307 — 元の
sponsored_placement正準 - #4592 — この文書
canonical-formats.mdx— 全体の canonical-formats 語彙