https://adcontextprotocol.org/schemas/v3/signals/get-signals-request.json
レスポンススキーマ: https://adcontextprotocol.org/schemas/v3/signals/get-signals-response.json
get_signals タスクは、シグナルメタデータとプラットフォーム横断のリアルタイムなデプロイステータスの両方を返します。これによりエージェントは可用性を把握し、アクティベーションプロセスを案内できます。
リクエストパラメーター
discovery_mode: "wholesale" は AdCP 3.1+ のディスカバリー形状です。呼び出し元が
3.1+ のシグナルサーフェスやホールセールサポートを前提にできない場合、クライアントは
ホールセールリクエストを発行する前に、まず get_adcp_capabilities
を呼び出し、signals.discovery_modes に "wholesale" が含まれることを確認すべきです。
フィールドが無いか "brief" のみを列挙している場合は、エージェントを brief 専用として扱い、
signal_spec、signal_refs、または非推奨の signal_ids を使います。非同期ディスカバリー
discovery_mode: "brief" は、セマンティックディスカバリーが遅いプロバイダークエリや、初期レスポンス前に完了できないレビューに依存する場合、submitted を返してもかまいません(MAY)。task_id を用いた get_task_status(レガシー tasks/get)のポーリングは常に有効です。push_notification_config が存在し、エージェントが submitted を返す場合、エージェントは少なくとも終端の完了/失敗通知をその Webhook にも送信します。中間の進捗通知は任意です。discovery_mode: "wholesale" は同期的なフィード読み取りのままで、部分的完了は submitted ではなく incomplete[] で報告します。
Destination オブジェクト
各デプロイ先はtype フィールドでプラットフォームベースかエージェントベースかを区別します。
*
platform は type=“platform” の場合必須、agent_url は type=“agent” の場合必須。
デスティネーションフィルタリング: シグナルは、要求されたデスティネーションのいずれかで利用可能であれば返されます(OR セマンティクス)。シグナルが利用できないデスティネーションは、そのシグナルのレスポンス deployments 配列から省略されます。一部のデスティネーションがシグナルをサポートしない場合、PARTIAL_COVERAGE 警告が含まれることがあります。
アクティベーションキー: 認証済みの呼び出し元がリクエスト中のいずれかのデスティネーションにアクセス権を持つ場合、シグナルエージェントはそれらのデプロイメント(is_live: true のとき)についてレスポンスに activation_key フィールドを含めます。
権限モデル: シグナルエージェントは、呼び出し元の認証・認可に基づいてキーの付与を決定します。例:
- 営業エージェントは自分の
agent_urlに一致するデプロイメントのキーを受け取ります - 複数 DSP プラットフォームへの認証情報を持つバイヤーは、それらすべてのデプロイメントのキーを受け取ります
- アクセス可否は、リクエスト中のフラグではなく、シグナルエージェントの権限システムで決定されます
Filters オブジェクト
catalog_types、非推奨の catalog_signals 機能フラグ、非推奨の
signal_id.source: "catalog" 値はレガシーなワイヤ用語です。新しい文章では、これらを
adagents.json の signals[] におけるプロバイダー公開のシグナル定義として読み替えてください。
既存の 3.x エージェントは互換性のためこれらを受け付け/送出し続けてもかまいませんが、
新しい呼び出し元は signal_ref を使うべきで(SHOULD)、Signals プロトコルを使う前に
signals.features.catalog_signals を必須としてはなりません(MUST NOT)。レスポンス構造
すべての AdCP レスポンスは次を含みます。- message: 操作結果の人間可読な要約
- context_id: フォローアップリクエスト用のセッション継続識別子
- data: タスク固有のペイロード(下記 Response Data 参照)
- MCP: 完全なレスポンスを平坦な JSON として返却
- A2A: アーティファクトとして返却(text パートに message、data パートにデータ)
Response Data
get_signals はディスカバリーと可用性のサーフェスであり、正規のシグナル定義から
すべてのフィールドをインライン化することを要求するものではありません。広範な検索結果や
ホールセールフィードのページでは、シグナルエージェントは各リスティングをコンパクトに保ち、
安定した参照と、大きな定義リソース向けのキャッシュ可能な開示ポインターを使うべきです(SHOULD)。
バイヤーは signal_ref からプロバイダー公開の定義を参照解決できます。プロバイダーの
/.well-known/adagents.json を取得し(存在する場合は authoritative_location に従う)、
一致する signals[].id を選択します。取得した adagents.json ドキュメントは、解決された
authoritative URL に加え、catalog_etag、HTTP ETag / Last-Modified、または上限付き TTL で
キャッシュし、そのキャッシュされたドキュメント内で signal_ref.signal_id を解決します。
taxonomy.etag は、独自の鮮度バリデーターを持つタクソノミードキュメントについてのみ使います。
これらは既存のプロバイダーファイルおよびタクソノミーのバリデーターを再利用します。get_signals
は別個のシグナル定義バリデーターを定義せず、クライアントはシグナル定義キャッシュを
バリデーターのみでキー付けしてはなりません。定義フィールドのインクルージョン
同じ呼び出しでよりリッチなレビューコンテキストが必要なバイヤーはfields を設定できます。これは
別個の検索タスクを導入するのではなく、get_products.fields と同じレスポンス投影パターンを使います。
必須の識別・有効化フィールドは、レスポンススキーマが要求する場合は常に含まれます。追加の値は、
taxonomy、data_sources、methodology、segmentation_criteria、criteria_url、
refresh_cadence、lookback_window、onboarder、modeling、audience_expansion、
device_expansion、countries、consent_basis、restricted_attributes、policy_categories、
art9_basis、data_subject_rights などの、任意のリスティングフィールドやリッチな定義メタデータを
インラインで要求します。
別のプロバイダーのシグナルについて consent_basis や art9_basis が投影される場合、その値は
プロバイダーが宣言したシグナル定義の姿勢のままです。セラーや連携エージェントが、プロバイダー宣言の
根拠を自身の処理根拠で置き換えてはなりません(MUST NOT)。
エージェントは、フィールドが利用可能なとき、厳密な検索、絞り込み、小規模なカスタムシグナル結果
セットについて、要求されたフィールドを尊重すべきです(SHOULD)。広範なディスカバリーやホールセール
ページでは、要求されたフィールドをインライン化するとページが大きくなりすぎる場合、エージェントは
プロバイダー公開の定義、タクソノミードキュメント、基準ページ、開示 URL へのポインターを含む
コンパクトなリスティングを返してもかまいません(MAY)。これにより、静的シグナルは adagents.json
を通じてキャッシュ可能なまま、カスタムや brief 固有のシグナルは有用な場合により深いインライン
コンテキストを返せます。
フィールド説明
- signals: 一致するシグナルの配列
- signal_ref: 正規のシグナル参照。adagents.json の
signals[]を通じて解決されるシグナルにはscope: "data_provider"を、adagents.json のsignals[]に公開されていないソースネイティブなシグナルにはscope: "signal_source"を、プロダクトコンテキストのレスポンスでのみscope: "product"を使います。新しいレスポンスはこのフィールドを含めるべきです(SHOULD)。 - signal_id: 非推奨のレガシー SignalId オブジェクト。新しいクライアントは
signal_refを読むべきです。移行期間中、古いレスポンスはsignal_idのみを含むことがあります。 - signal_agent_segment_id: このシグナルソースが発行する不透明なシグナルハンドル。
activate_signalにはそのまま使い、グローバルに移植可能なシグナル ID として扱わないでください。パッケージレベルのsignal_targeting_groupsでは、signal_refが購入時のアイデンティティであり、このハンドルは選択したプロダクトオプションが別個の実行ハンドルとして公開する場合にのみエコーされます。 - name: 人間可読なシグナル名
- description: 詳細なシグナル説明
- signal_type: シグナルのタイプ。次のいずれか:
marketplace— 再販されるサードパーティセグメント(プロバイダーのadagents.jsonでプロバイダー認可を検証可能)owned— シグナルソースが直接所有するデータから導出されるファーストパーティセグメントcustom— モデル、コンポジット、バイヤー入力からオンデマンドで構築されるソースネイティブなセグメント(既存の上流プロバイダーに帰属しない)
- data_provider: 該当する場合の人間可読なソース名。
scope: "data_provider"のシグナルではこれがデータプロバイダーです。scope: "signal_source"のシグナルではシグナルソースや独自の出所を示すことがあります。 - coverage_percentage: 任意の非推奨レガシースカラー。オーディエンスカバレッジのパーセンテージ。
coverage_forecastを消費しないクライアントのフォールバックとしてのみ使います。coverage_forecast が存在する場合、シグナルレベルのディスカバリーではcoverage_forecastが正規であり、このスカラーはフォールバック専用です。coverage_forecastが同じ分母で absent バケットを含む場合、coverage_percentageは100 * (1 - absent coverage_rate.mid)に整合すべきです。 - coverage_forecast: シグナルの、任意のフォーキャスト形状の可用性ガイダンス。
scopeが分母を宣言し、bucket_semanticsが返される値バケットがexclusiveかoverlappingかを宣言し、bucket_completenessが返されるバケットが完全な分母分割か部分的ヒストグラムかを宣言します。各ポイントは、正規のsignal_refを持つkind: "signal"ディメンション、任意の存在値にはpresence: "present"、特定の値バケットにはpresence: "present"に加えてsignal_value、非存在バケットにはpresence: "absent"に加えてsignal_value: nullを使えます。metrics.coverage_rateは宣言されたスコープの 0.0〜1.0 の割合です。 - deployments: デスティネーションデプロイメントの配列
- agent_url: デスティネーションエージェントを識別する URL
- account: 該当する場合のアカウント ID
- is_live: このデプロイメントでシグナルが現在アクティブかどうか
- activation_key: ターゲティングに使うキー(下記 Activation Key 参照)。
is_live=trueかつ認証済みの呼び出し元がこのデプロイメントにアクセスできる場合にのみ含まれます。 - estimated_activation_duration_minutes: ライブでない場合の有効化所要時間
- pricing_options: 増分価格を持つシグナルの料金オプションの配列。選択した
pricing_option_idをreport_usageまたはパッケージレベルのsignal_targeting_groupsに渡して課金検証に使います。価格が呼び出し元に利用できない、デスティネーションプロダクトにバンドルされている、または増分コストがない場合は省略されます。- pricing_option_id: この料金オプションの一意識別子
- model: 課金モデル —
cpm、percent_of_media、flat_fee、per_unit、またはcustom model: "cpm"—cpm(数値、インプレッション 1000 回あたりのコスト)、currency(ISO 4217)model: "percent_of_media"—percent(0〜100)、currency(ISO 4217)、max_cpm(任意の CPM 上限: 実効課金 =min(percent × media_spend_per_mille, max_cpm))model: "flat_fee"—amount(固定料金)、currency(ISO 4217)、period(monthly、quarterly、annual、またはcampaign)model: "per_unit"—unit(何をカウントするか)、unit_price(1 単位あたりのコスト)、currency(ISO 4217)model: "custom"—description(人間可読)、metadata(構造化パラメーター)、currency(任意)。パフォーマンスキッカー、段階的ボリューム、ハイブリッド式、または標準モデルで表現できない任意の構成のためのエスケープハッチ。バイヤーはコミットメント前にカスタム価格をオペレーターレビューに通すべきです(SHOULD)。
- signal_ref: 正規のシグナル参照。adagents.json の
pricing_option_id を report_usage に渡して課金検証に使います。メディアプロダクトで選択されるセラー提供シグナルでは、パッケージレベルの targeting_overlay.signal_targeting_groups.groups[].signals[].pricing_option_id に渡します。シグナルが複数のモデル(例: CPM とフラットフィー)を提供する場合、予想される配信ボリュームとキャンペーン構造に基づいて選びます。
レスポンスメタデータ
Activation Key オブジェクト
アクティベーションキーは、デスティネーションターゲットでのシグナルの使い方を表します。セグメント ID かキー/バリューのいずれかです。 セグメント ID 形式:プロトコル別の例
AdCP のペイロードはプロトコル間で同一で、リクエスト/レスポンスのラッパーのみ異なります。MCP リクエスト - 営業エージェントがシグナルを問い合わせる
営業エージェントがシグナルを問い合わせます。認証済みの呼び出し元が wonderstruck.salesagents.com であるため、シグナルエージェントはレスポンスにアクティベーションキーを含めます。MCP レスポンス - Activation Key 付き
認証済みの呼び出し元がデプロイメントターゲットに一致するため、レスポンスにアクティベーションキーが含まれます。MCP レスポンス - 複数の料金オプション
一部のシグナルは複数の課金モデルを提供します。バイヤーは 1 つを選択し、直接のシグナル利用ではreport_usage に、シグナルがメディアバイで選択される場合はパッケージレベルの signal_targeting_groups に、その pricing_option_id を渡します。
MCP リクエスト - バイヤーが複数 DSP を確認
バイヤーが複数の DSP プラットフォームで可用性を確認します。MCP レスポンス - マルチプラットフォームアクセスを持つバイヤー
The Trade Desk と Amazon DSP の両方の認証情報を持つバイヤーは、両プラットフォームのキーを受け取ります。A2A リクエスト
自然言語での呼び出し
明示的なスキル呼び出し
A2A レスポンス
A2A は同じデータ構造でアーティファクトとして結果を返します。プロトコルトランスポート
- MCP: 引数を伴う直接のツール呼び出し。完全なレスポンスを平坦な JSON として返却
- A2A: 入力を伴うスキル呼び出し。message とデータを分離した構造化アーティファクトを返却
- データの一貫性: 両プロトコルとも同一の AdCP データ構造とバージョン情報を含みます
シナリオ
すべてのプラットフォームを探索
プラットフォーム横断で利用可能なすべてのデプロイメントを発見します。レスポンス
Message: “Found luxury automotive contextual segment from Peer39 with 15% coverage. Live on Index Exchange and OpenX, pending activation on Pubmatic.” ペイロード:レスポンスフィールド
- context_id (string): セッション永続化用のコンテキスト識別子
- signals (array): 一致するシグナルの配列
- signal_agent_segment_id (string): このシグナルソースが発行する不透明なシグナルハンドル。
activate_signalにはそのまま使い、グローバルに移植可能なシグナル ID として扱わないでください。メディアバイのシグナルグループでは、signal_refが購入時のアイデンティティであり、このハンドルは選択したプロダクトオプションが別個の実行ハンドルとして公開する場合にのみエコーされます。 - name (string): 人間可読なシグナル名
- description (string): 詳細なシグナル説明
- signal_type (string):
marketplace(再販サードパーティ)、owned(シグナルソースのファーストパーティデータ)、またはcustom(オンデマンド構築のソースネイティブセグメント) - data_provider (string, optional): 該当する場合の人間可読なソース/プロバイダー名
- coverage_percentage (number, optional, deprecated): レガシースカラーの推定リーチパーセンテージ。
coverage_forecastが無いかクライアントがサポートしない場合のフォールバックとしてのみ使います。 - coverage_forecast (object, optional): 明示的な分母と可用性ポイントを持つフォーキャスト形状のカバレッジ内訳。「任意の存在値」の集約バケットには
presence: "present"とsignal_valueの省略を使い、行が特定の値のためのものである場合にのみsignal_valueを追加します。返されるバケットが重複しない場合はbucket_semantics: "exclusive"を、複数値シグナルにより返されるレートの合計が 1.0 を超えうる場合は"overlapping"を使います。返されるバケットが宣言された分母をカバーする場合にのみbucket_completeness: "complete"を使い、そうでなければ"partial"を使います。バイヤーは省略されたシェアを、未開示・その他・非サポートのバケットとして扱わなければなりません。
- signal_agent_segment_id (string): このシグナルソースが発行する不透明なシグナルハンドル。
coverage_forecast をシグナルファーストのディスカバリーの正規フィールドとして使います:「このシグナルまたはその値はどれだけのインベントリを持つか?」。kind: "signal" ディメンションを持つプロダクトまたはプロポーザルのフォーキャストは、プロダクト固有のプランニングの正規サーフェスとして使います:「このシグナルはこのプロダクトのベースライン可用性をどう制約するか?」。バケット固有のフィルタリングは現状クライアント側であり、min_coverage_percentage のようなリクエストフィルターは依然としてレガシースカラーを使います。
- deployments (array): プラットフォーム固有のデプロイメント情報
- platform (string): ターゲットプラットフォーム名
- account (string, nullable): アカウント固有の場合の特定アカウント
- is_live (boolean): シグナルが現在アクティブかどうか
- activation_key (object): ターゲティングに使うキー。
is_live=trueかつ呼び出し元がアクセスできる場合にのみ含まれます。上記 Activation Key オブジェクトを参照。 - estimated_activation_duration_minutes (number, optional): ライブでない場合の有効化所要時間
- pricing_options (array): 増分価格を持つシグナルの利用可能な料金オプションの配列。1 つを選択し、その
pricing_option_idをreport_usageまたはパッケージレベルのsignal_targeting_groupsに渡します。- pricing_option_id (string): この料金オプションの一意識別子
- model (string): 課金モデル —
cpm、percent_of_media、flat_fee、per_unit、またはcustom
エラーコード
ディスカバリーエラー
REFERENCE_NOT_FOUND: 参照されたsignal_agent_segment_idが存在しないか、 プライベートなシグナルエージェントがこのアカウントから見えません。リソースが存在するが 未認可であっても、真に存在しなくても、同じコードが返されます — セラーは両者を区別しては なりません(MUST NOT。どの型付きパラメーターの解決に失敗したかはerror.fieldを参照)。 error-handling.mdx の uniform-response の MUST を参照。AGENT_ACCESS_DENIED: 認証済みエージェントの認証情報がこのシグナルエージェントへのアクセスを認可しませんでした
ディスカバリー警告
PRICING_UNAVAILABLE: 1 つ以上のプラットフォームで価格データが一時的に利用不可PARTIAL_COVERAGE: 一部の要求されたプラットフォームがこのシグナルタイプをサポートしませんSTALE_DATA: プロバイダーのリフレッシュ遅延により一部のシグナルメタデータが古い可能性があります
利用上の注意
- 認証ベースのキー: アクティベーションキーは、認証済みの呼び出し元がいずれかのデプロイメントターゲットに一致する場合にのみ返されます
- 権限セキュリティ: シグナルエージェントは、リクエストフラグではなく呼び出し元の識別に基づいてキーの付与を決定します
- デプロイメントステータス:
is_liveを確認して有効化が必要かを判断します - 複数デプロイメント: 複数のデプロイメントターゲットを問い合わせてプラットフォーム横断の可用性を確認します
- 有効化が必要な場合:
is_liveが false の場合はactivate_signalタスクを使います - message フィールド: 最も関連性の高い発見の簡潔な要約を提供します
メディアプロダクト上のセラー提供シグナル
ターゲティングシグナルを所有または適用する認可を持つ営業エージェントは、get_products を通じて購入時のプロダクト適格性を公開します。バイヤーがパッケージ選択前にディスカバリーや有効化を必要とする場合、get_signals を通じてより広範なクロスプロダクトのシグナルフィードを公開することもできます。
get_productsは、プロダクトがパッケージレベルのシグナルターゲティングを持つかを宣言します。products[].included_signalsは、プロダクトにすでにバンドルまたは計画された選択不可のシグナルを記述します。インラインのproducts[].signal_targeting_optionsは、プロダクト固有のメニュー、価格、有効化ハンドル、デフォルト、グルーピングヒント、または brief/refine で選択されたサブセットを運べます。ホールセールプロダクトはインラインオプションを省略し、get_signalsを選択可能なシグナルフィードとして使えます。get_signalsは任意で、signal_ref、signal_agent_segment_id、値メタデータ、および任意のデフォルトまたはアカウントスコープのpricing_optionsを含むクロスプロダクトのシグナルメタデータを返します。create_media_buyは、packages[].targeting_overlay.signal_targeting_groupsでパッケージのシグナルを選択し、選択したシグナルのpricing_option_id、signal_ref、および必要な場合は別個のセラー実行ハンドルを運びます。
signal_targeting_options を、signal_targeting_rules を使ってそのパッケージで何が適用可能かを判断します。プロダクトがインラインオプションを省略するがシグナルターゲティングを許可する場合、候補ディスカバリーと有効化メタデータには get_signals を使い、次に get_products.filters.signal_targeting またはプロダクト固有の get_products クエリを使って、create_media_buy を呼ぶ前に、意図したプロダクトについて候補セットが選択可能で共同構成可能であることを確認します。両サーフェスが価格を含む場合、そのプロダクトについてはプロダクトスコープの signal_targeting_options[].pricing_options の価格が正規です。両サーフェスで公開されるプロダクトローカルなシグナルについては、プロダクトオプションの signal_ref.signal_id が、同じシグナルについてセラーの get_signals.signals[].signal_ref.signal_id と一致しなければなりません(MUST)。included_signals は説明のためだけのもので、シグナルを選択可能にはしません。
メディアバイのプロダクトターゲティングでは、プロダクトオプションとパッケージグループは同じ signal_ref アイデンティティを使います。プロダクトローカルなシグナルオプションには scope: "product"、公開された adagents.json の signals[] で定義されるシグナルには data_provider_domain を伴う scope: "data_provider"、adagents.json の signals[] に公開されないソースネイティブなカスタムシグナルには scope: "signal_source" を使います。プロバイダー公開のシグナルが選択される場合、バイヤーは、シグナル ID またはタグについてプロバイダーの adagents.json の authorized_agents ルールを確認することで、セラーの認可を検証できます。古い Signals プロトコルの signal_id.source 形状は非推奨で、後方互換性のためにのみ保持されます。
ホールセールシグナルフィード
コンシューマー(ストアフロント、連携マーケットプレイス、レジストリ)がシグナルエージェントの完全な価格付きシグナルフィードをミラーする必要がある場合、discovery_mode: "wholesale" を設定し、signal_spec / signal_refs / 非推奨の signal_ids を省略します。呼び出し元が 3.1+ のシグナルサーフェスやホールセールサポートを前提にできない場合、まず get_adcp_capabilities.signals.discovery_modes に "wholesale" があるか確認します。ホールセール列挙は get_products の buying_mode: "wholesale" と対称です。同期的、ページネーションあり、確定価格で、部分的完了は incomplete[] で宣言されます。
リクエスト
レスポンス
認可と来歴
マーケットプレイスシグナル(signal_type: "marketplace")は、上流のデータプロバイダーに帰属し続けます。ホールセール列挙は来歴を潰しません。
- 各マーケットプレイスシグナルは
data_providerを運びます。 - コンシューマーは、プロバイダーの
adagents.jsonを通じてプロバイダー認可を検証すべきです(SHOULD)— そのシグナルクラスについて、シグナルエージェントの URL がプロバイダーの認可リストに現れなければなりません。 - ストアフロントやレジストリは、ホールセール列挙に加えて
adagents.jsonの相互参照を使い、データパブリッシャーのシグナルビューを実体化してもかまいません(MAY): 既知の各データプロバイダーについて、認可されたシグナルエージェント経由で利用可能なシグナルの集合を価格付きで。
価格
エージェントが宣言すべき確定したスタンドアロンシグナル価格を持つ場合、認証済みの呼び出し元についてpricing_options[] を投入しなければなりません(MUST)。account が省略された場合、エージェントはデフォルトのレートカード価格を返すか、pricing_options[] を省略します(その場合、呼び出し元は構成前に account で再クエリするか、get_products のプロダクトスコープ価格を使わなければなりません(MUST))。未認証の呼び出し元は価格なしでシグナルメタデータを受け取ってもかまいません(MAY)。メディアプロダクトにバンドルされている、または増分コストを持たないシグナルは pricing_options[] を省略してもかまいません(MAY)。
機能宣言
シグナルエージェントはget_adcp_capabilities でホールセールサポートを宣言します。
"wholesale" を宣言しないエージェントは、ホールセール呼び出しに対して INVALID_REQUEST を返してもかまいません(MAY)。ホールセールディスカバリーは AdCP 3.1+ であるため、呼び出し元が 3.1+ のシグナルサーフェスやホールセールサポートを前提にできない場合、機能宣言が正規のサポートシグナルとなります。呼び出し元はホールセールリクエストを発行する前に探索すべきです(SHOULD)。
ホールセールフィードバージョニング
ホールセール列挙があっても、エージェントのシグナルフィードをミラーするコンシューマーは、変更を検出するためだけに毎回のポーリングですべてのページネーションされたページを再取得することになります。これを避けるため、get_signals はすべてのレスポンスで返される不透明な wholesale_feed_version トークンをサポートします。後続の呼び出しで if_wholesale_feed_version を通じて渡すと、エージェントは unchanged: true でショートサーキットしてもかまいません(MAY)— シグナルペイロードなし、ページごとの差分なし。
これは get_signals が返すセラー側のホールセールシグナルフィードです。sync_catalogs フィードではありません。sync_catalogs はセラーアカウント上のバイヤー提供のキャンペーン入力フィードを管理します。
変更なしレスポンス
リクエスト:unchanged: true のとき、signals[] は省略しなければならず(MUST)、コンシューマーはローカルのホールセールシグナルミラーを変更してはなりません(MUST NOT)。
ホールセールシグナルフィード変更 — 完全ペイロード返却(省略版)
test=false
ルール
- トークンは不透明です。フォーマットなし、順序なし、検査なし。
- 返される
wholesale_feed_versionはcache_scopeを通じてスコープキー付けされます。呼び出し元は、使用した(account, filters, discovery_mode, destinations, countries)タプルと共に(cache_scope, wholesale_feed_version)のペアをキャッシュします。2 層モデルについては キャッシュレイヤリング を参照。 pricing_versionは任意のより細粒度のトークンです。存在する場合、価格が動くと変わりますが、wholesale_feed_versionは構造/メタデータが動いたときのみ変わります。セグメントメタデータを変えないレートカードスイープで一般的です。if_pricing_versionにはif_wholesale_feed_versionが必要です。 価格は独自の構造的ベースラインを持ちません。if_wholesale_feed_versionなしでif_pricing_versionを送るのはスキーマレベルのエラーです。エージェントの評価は 2 段階です: ホールセールフィード不一致は完全ペイロードを返します。ホールセールフィード一致で価格不一致も完全ペイロードを返します(呼び出し元が更新されたpricing_optionsを確認できるように)。両方一致 →unchanged: true。filtersの正規化。 エージェントは、wholesale_feed_versionキースペースへのハッシュ化前にfiltersオブジェクトを正規化されたものとして扱わなければなりません(MUST): キーを辞書順にソート、省略されデフォルトの値は同一に扱う、フィルターが集合セマンティクスを持つ場合は配列値をソート(例:catalog_types、data_providers)。同等だが形状の異なるフィルターオブジェクトを渡す呼び出し元は、同じwholesale_feed_versionを受け取らなければなりません(MUST)。キー順やデフォルト省略の違いによる暗黙のミラー陳腐化バグを防ぎます。前方互換のデフォルト: 3.x マイナーバージョンで追加される新しいフィルターフィールドは集合か列かのセマンティクスを宣言しなければなりません(MUST)。明示的な宣言がない場合、ルールは集合セマンティクスにデフォルトします。- ページネーションとの相互作用。
wholesale_feed_versioning.supported: trueを宣言するエージェントは、(最初だけでなく)すべてのページネーションされたページでwholesale_feed_versionを返さなければなりません(MUST)。バージョニングを宣言しないエージェントも同様にすべきです(SHOULD)。ページ間でホールセールフィードが変異した場合、新しいバージョンが次のページで現れ、呼び出し元はcursor: nullからページネーションを再開しなければなりません(MUST)— すでに受け取った部分ページは陳腐化したバージョンを記述しています。 unchanged: trueと進行中のページネーション。 ページネーション途中の呼び出し元は、それまでのページが描かれたバージョンに一致するif_wholesale_feed_versionを送ってもかまいません(MAY)。エージェントがunchanged: trueを確認した場合、レスポンスはsignals[]とページネーションエンベロープを完全に省略し、呼び出し元はそのバージョン下での進行中のウォークを放棄します。エージェントは、アクティブなページネーション内の個々のページをスキップするために条件付きフェッチのショートサーキットを使ってはなりません(MAY NOT)—unchangedはフィード対キャッシュバージョンであり、ページ単位ではありません。if_wholesale_feed_versionを無視する v3.1 より前のエージェントは、単に完全ペイロードを返します — 意味的には正しく、非効率なだけです。
specs/wholesale-feed-webhooks.md を参照。ホールセールフィード Webhook は、変更されたシグナルペイロード、価格ペイロード、削除トゥームストーン、または一括変更サマリーを運びます。get_signals は修復と再照合の読み取りのままです。
キャッシュレイヤリング
シグナルエージェントは 2 つの概念的なレイヤーを公開します: パブリックレイヤー(レートカード/構造ビュー)と アカウント別オーバーレイ(プレミアムバイヤー向けのアカウント固有価格)。条件付きフェッチパスはcache_scope を通じてレイヤーを認識します。
2 層キャッシュ。
挙動。
accountなしのリクエストは常にcache_scope: "public"を返します。呼び出し元はパブリックキーの下にキャッシュします。accountありのリクエストはcache_scope: "public"または"account"を返します(エージェントは宣言しなければなりません(MUST)。デフォルトなし)。"public": このアカウントはレートカードで価格付けされます。呼び出し元は重複排除してもかまいません(MAY)— バージョンとペイロードは未認証ビューと同じです。"account": このレスポンスはアカウント固有のオーバーライドを運びます。呼び出し元はアカウントオーバーレイキーの下にキャッシュします。
- エージェントはアカウントを
"account"から"public"にダウングレードしてもかまいません(MAY)— 呼び出し元はこれを「このアカウントはもうオーバーライドを持たない」と解釈し、オーバーレイを破棄すべきです(SHOULD)。
if_wholesale_feed_version での条件付きフェッチ。 トークンを、それが返されたスコープと組にして送ります。エージェントはそのスコープの現在のバージョンと比較します。呼び出し元のトークンが "account" スコープに属するが、エージェントが cache_scope: "public" で応答した場合、それがダウングレードシグナルです。
Webhook 無効化。 ホールセールフィード Webhook イベントは、*.priced と *.updated のペイロードで applies_to.scope を宣言します。エージェントは、どのサブスクライバーがシグナル Webhook を受け取るかを決める際、get_signals discovery_mode: "wholesale" が使うのと同じアカウント/呼び出し元認可述語を適用しなければなりません(MUST)。
applies_to: { scope: "public" }→ パブリックレイヤーのキャッシュを無効化。そのパブリックバージョンを参照するすべてのアカウントオーバーレイも陳腐化します。applies_to: { scope: "account", account_ids: [...] }→ 指定されたアカウントのオーバーレイのみを無効化。account_idsなしのapplies_to: { scope: "account" }→ セラーは影響を受ける集合を秘匿します。サブスクライバー別のスコープフィルターが、プリンシパルが影響を受ける集合にあるサブスクライバーにのみイベントをルーティングします。
specs/wholesale-feed-webhooks.md の §“Cache layering and event scoping” を参照。
incomplete 配列
エージェントが呼び出し元のtime_budget 内(または内部制限のため)にすべての作業を完了できない場合、レスポンスは incomplete — 欠けているものを宣言する配列 — を含みます。呼び出し元は estimated_wait を使って、より大きな予算で再試行すべきかを判断できます。
反復的絞り込み
get_signals は別個のモードフラグなしで反復的絞り込みをサポートします。signal_spec と signal_refs の組み合わせが操作を決定します。
以前の結果を絞り込むには、保持したいシグナルの
signal_ref 値を渡し戻し、変更内容を記述する更新された signal_spec を提供します。
レスポンス - 複数シグナル
レスポンス - 警告付き部分成功
レスポンス - 該当なし
実装ガイド
シグナルメッセージ生成
message フィールドは実行可能なインサイトを提供すべきです。