Skip to main content
タスク: 説明に基づいてシグナルを発見し、それらがどこにデプロイされているかの詳細を返します。 応答時間: 約 60 秒(バックエンドシステムとの推論/RAG) リクエストスキーマ: 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_specsignal_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 と同じレスポンス投影パターンを使います。 必須の識別・有効化フィールドは、レスポンススキーマが要求する場合は常に含まれます。追加の値は、 taxonomydata_sourcesmethodologysegmentation_criteriacriteria_urlrefresh_cadencelookback_windowonboardermodelingaudience_expansiondevice_expansioncountriesconsent_basisrestricted_attributespolicy_categoriesart9_basisdata_subject_rights などの、任意のリスティングフィールドやリッチな定義メタデータを インラインで要求します。 別のプロバイダーのシグナルについて consent_basisart9_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_percentage100 * (1 - absent coverage_rate.mid) に整合すべきです。
    • coverage_forecast: シグナルの、任意のフォーキャスト形状の可用性ガイダンス。scope が分母を宣言し、bucket_semantics が返される値バケットが exclusiveoverlapping かを宣言し、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_idreport_usage またはパッケージレベルの signal_targeting_groups に渡して課金検証に使います。価格が呼び出し元に利用できない、デスティネーションプロダクトにバンドルされている、または増分コストがない場合は省略されます。
      • pricing_option_id: この料金オプションの一意識別子
      • model: 課金モデル — cpmpercent_of_mediaflat_feeper_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)、periodmonthlyquarterlyannual、または campaign
      • model: "per_unit"unit(何をカウントするか)、unit_price(1 単位あたりのコスト)、currency(ISO 4217)
      • model: "custom"description(人間可読)、metadata(構造化パラメーター)、currency(任意)。パフォーマンスキッカー、段階的ボリューム、ハイブリッド式、または標準モデルで表現できない任意の構成のためのエスケープハッチ。バイヤーはコミットメント前にカスタム価格をオペレーターレビューに通すべきです(SHOULD)。
課金モデルに合った料金オプションを選択します。直接のシグナル有効化では、その pricing_option_idreport_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" を使います。バイヤーは省略されたシェアを、未開示・その他・非サポートのバケットとして扱わなければなりません。
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_idreport_usage またはパッケージレベルの signal_targeting_groups に渡します。
    • pricing_option_id (string): この料金オプションの一意識別子
    • model (string): 課金モデル — cpmpercent_of_mediaflat_feeper_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: プロバイダーのリフレッシュ遅延により一部のシグナルメタデータが古い可能性があります

利用上の注意

  1. 認証ベースのキー: アクティベーションキーは、認証済みの呼び出し元がいずれかのデプロイメントターゲットに一致する場合にのみ返されます
  2. 権限セキュリティ: シグナルエージェントは、リクエストフラグではなく呼び出し元の識別に基づいてキーの付与を決定します
  3. デプロイメントステータス: is_live を確認して有効化が必要かを判断します
  4. 複数デプロイメント: 複数のデプロイメントターゲットを問い合わせてプラットフォーム横断の可用性を確認します
  5. 有効化が必要な場合: is_live が false の場合は activate_signal タスクを使います
  6. message フィールド: 最も関連性の高い発見の簡潔な要約を提供します

メディアプロダクト上のセラー提供シグナル

ターゲティングシグナルを所有または適用する認可を持つ営業エージェントは、get_products を通じて購入時のプロダクト適格性を公開します。バイヤーがパッケージ選択前にディスカバリーや有効化を必要とする場合、get_signals を通じてより広範なクロスプロダクトのシグナルフィードを公開することもできます。
  • get_products は、プロダクトがパッケージレベルのシグナルターゲティングを持つかを宣言します。products[].included_signals は、プロダクトにすでにバンドルまたは計画された選択不可のシグナルを記述します。インラインの products[].signal_targeting_options は、プロダクト固有のメニュー、価格、有効化ハンドル、デフォルト、グルーピングヒント、または brief/refine で選択されたサブセットを運べます。ホールセールプロダクトはインラインオプションを省略し、get_signals を選択可能なシグナルフィードとして使えます。
  • get_signals は任意で、signal_refsignal_agent_segment_id、値メタデータ、および任意のデフォルトまたはアカウントスコープの pricing_options を含むクロスプロダクトのシグナルメタデータを返します。
  • create_media_buy は、packages[].targeting_overlay.signal_targeting_groups でパッケージのシグナルを選択し、選択したシグナルの pricing_option_idsignal_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.jsonauthorized_agents ルールを確認することで、セラーの認可を検証できます。古い Signals プロトコルの signal_id.source 形状は非推奨で、後方互換性のためにのみ保持されます。

ホールセールシグナルフィード

コンシューマー(ストアフロント、連携マーケットプレイス、レジストリ)がシグナルエージェントの完全な価格付きシグナルフィードをミラーする必要がある場合、discovery_mode: "wholesale" を設定し、signal_spec / signal_refs / 非推奨の signal_ids を省略します。呼び出し元が 3.1+ のシグナルサーフェスやホールセールサポートを前提にできない場合、まず get_adcp_capabilities.signals.discovery_modes"wholesale" があるか確認します。ホールセール列挙は get_productsbuying_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_versioncache_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_typesdata_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" } → セラーは影響を受ける集合を秘匿します。サブスクライバー別のスコープフィルターが、プリンシパルが影響を受ける集合にあるサブスクライバーにのみイベントをルーティングします。
完全な Webhook 側の仕様については specs/wholesale-feed-webhooks.md の §“Cache layering and event scoping” を参照。

incomplete 配列

エージェントが呼び出し元の time_budget 内(または内部制限のため)にすべての作業を完了できない場合、レスポンスは incomplete — 欠けているものを宣言する配列 — を含みます。呼び出し元は estimated_wait を使って、より大きな予算で再試行すべきかを判断できます。

反復的絞り込み

get_signals は別個のモードフラグなしで反復的絞り込みをサポートします。signal_specsignal_refs の組み合わせが操作を決定します。 以前の結果を絞り込むには、保持したいシグナルの signal_ref 値を渡し戻し、変更内容を記述する更新された signal_spec を提供します。
シグナルエージェントは、提供された ID を出発点として、spec を調整ガイダンスとして使い、元の選択と要求された変更の両方を反映したシグナル(例: 同じプロバイダーのより広範なセグメント、またはより高いカバレッジを持つ代替プロバイダーの比較可能なセグメント)を返します。

レスポンス - 複数シグナル

レスポンス - 警告付き部分成功

レスポンス - 該当なし

実装ガイド

シグナルメッセージ生成

message フィールドは実行可能なインサイトを提供すべきです。