英語で読む

次の方法で共有


入札者 - 破壊的変更

インプレッション バス API と入札プロトコルは絶えず変化しています。 変更の大部分は新しい機能のシームレスな追加ですが、統合の調整が必要になる可能性がある "破壊的変更" が導入される場合があります。

このページでは、インプレッション バス API と入札プロトコルに対する "破壊的変更" と見なされる変更について説明します。 また、破壊的変更として品質を損なわない変更の例も示します。

注意

Xandr は、早期通知を提供することなく、バグを修正し、 サービス ポリシー と法的義務に準拠するように機能を調整し、アルファ版とベータ版の機能と製品を変更する権利を留保します。

インプレッション バス API

インプレッション バス API のコンテキストでは、次の種類の変更は破壊的変更と見なされます。

  • フィールドの削除。
  • フィールドを必須以外から必須に変更します。
  • 新しい検証規則の追加。
  • フィールドのデータ型の変更 (たとえば、オブジェクトの配列に変換された ID の配列)。
  • 要求の調整の変更。
  • 応答によって返されるオブジェクトの数を減らします。

インプレッション バス API に破壊的変更を導入する場合、運用環境では 2 つのバージョンの API をサポートします。1 つは破壊的変更あり、もう 1 つは破壊的変更なしで 60 日間サポートされます。 これらの変更と、破壊的変更期間中に各バージョンに正しく到達する方法についてお知らせします (「 破壊的変更通知の受信」を参照してください)。

入札プロトコル

入札プロトコル (要求と応答) のコンテキストでは、次の種類の変更は破壊的変更と見なされます。

  • フィールドの削除。
  • フィールドを必須以外から必須に変更します。
  • フィールドのデータ型の変更 (たとえば、オブジェクトの配列に変換された ID の配列)。

入札プロトコルの破壊的変更は、変更が有効になる少なくとも 45 日前に発表します (「 破壊的変更通知の受信」を参照してください)。

破壊的でない変更の例

次の種類の変更は、破壊的変更として品質を損ないません。 このリストは網羅的ではないことに注意してください。これらは、破壊的でない変更のほんの一例です。

  • 必須ではない新しいフィールド (API または入札プロトコル) の追加。
  • 新しいサービス (API) の追加。
  • レポートへのメトリック/ディメンションの追加 (API)。
  • 新しいレポートの種類 (API) の追加。
  • 削除しないフィールドの非推奨 (API または入札プロトコル)。
  • 許可される同時レポートの数の削減または増加 (API)。
  • オブジェクト内のフィールド、配列内のオブジェクトなどの順序を変更します (API または入札プロトコル)。

破壊的変更通知の受信

  • Xandr ユーザー アカウントを使用している場合は、破壊的変更の通信が自動的に受信されます。
  • 独自の Xandr ユーザー アカウントをお持ちでない場合は、 Microsoft Advertising Xandr サイトで通信を受け取るためにサインアップできます。