Skip to main content
クリエイティブライブラリにクリエイティブアセットをアップロードして管理します。一括アップロード、アップサートセマンティクス、ジェネレーティブクリエイティブをサポートします。クリエイティブライブラリをホストするすべてのエージェント — クリエイティブエージェント(広告サーバー、クリエイティブ管理プラットフォーム)およびクリエイティブを管理するセールスエージェント — が実装します。 レスポンスタイム: 即時〜数日(completed を返すか、数時間/数日かかるレビューのために submitted を返す) リクエストスキーマ: creative/sync-creatives-request.json レスポンススキーマ: creative/sync-creatives-response.json

クイックスタート

クリエイティブアセットをアップロードする:
注意: クリエイティブごとの非同期レビューは、同期的な成功レスポンスの creatives[].status(例: pending_review)で表面化されます。操作全体がキューに入れられる場合(バッチ取り込み、同期をゲートするガバナンスレビュー)、レスポンスはトップレベルの status: "submitted"task_id を持つ submitted エンベロープになります。非同期承認ワークフローを参照。

書き込み後読み取りの可視性

同期的な sync_creatives の成功レスポンスを介して受理されたクリエイティブは、レスポンスが返される前にクリエイティブライブラリにコミットされていなければなりません(MUST)。それらは、同じアカウントと認可された呼び出し元からの後続の list_creatives 呼び出しに対して即座に可視でなければならず(MUST)、レビューのライフサイクルステータスが processing または pending_review のクリエイティブも含みます。 同期的な成功の分岐でクリエイティブを確認応答しつつ、ライブラリへの書き込みを後のバックグラウンドコミットまでバッファリングする実装は非準拠です。同期操作全体が返却前にコミットできない場合は、代わりに submitted タスクエンベロープを使います。その場合、可視性の要件は、受理されたクリエイティブとともにタスクが完了した時点で適用されます。

リクエストパラメータ

クリエイティブオブジェクト

レガシーの format_id か正準的な format_kind のパスのいずれかを提供し、両方は決して提供しません。新しい 3.1+ の統合では、ルーティングがプロダクトの宣言したフォーマットオプションに依存する場合、format_kindformat_option_ref を優先すべきです。

build_creative バリアントのプロモート

バイヤーが生成されたビルドリーフを保持する場合、正準的なプロモートは、保持した build_variant_id を新しい creative_id として使うことです。セラーは別個のリネージマッピングを保持する必要はありません。デリバリーレポートは通常の creative_id を通じてビルドリーフに結合できます。
test=false
その後、get_creative_deliverycreative_id を結合キーとして使います。保持した build_variant_id を使う代わりに別のライブラリ id を発行するワークフローは、将来のスコープ付きリネージフィールドが採用されない限り、このプロトコルで可視な結合を失います。

アセット構造

アセットはロール名をキーとします。各ロールにはアセットの詳細が含まれます:
test=false

アサインメント構造

アサインメントはリクエストレベルにあり、クリエイティブ ID をパッケージ ID にマッピングします。メディアバイを管理しないスタンドアロンのクリエイティブエージェントはこのフィールドを無視します。
test=false
公開済み投稿(published-post)参照プロダクトでは、アセットのロールは通常 published_post で、ペイロードにはアップロードされたメディアバイトではなく投稿 URL またはプラットフォームの投稿 ID が含まれます。バイヤーは、プラットフォーム固有の format_id を作成する代わりに、正準的なクリエイティブのパス(例: format_kind: "video_hosted" とプロダクトの format_option_ref)を通じてこれらのアセットを送信できます。セラーが投稿を解決できるが、投稿を所有するパブリッシャーのアイデンティティのような必要な下流のプラットフォーム接続を欠く場合、訂正可能なエラーは AUTHORIZATION_REQUIRED です。新しい実装は error.details.missing_connections[] を含めるべきで、呼び出し元は人を正しい接続フローに通し、認可が回復した後にリトライできます。

レスポンス

レスポンスは識別共用体を使います——レスポンスは三つの形のうちちょうど一つを持ち、混在することはありません: 1. 同期的な成功 — クリエイティブごとの結果:
  • creatives - 処理された各クリエイティブの結果(成功と失敗の両方のアイテムを含む)
  • dry_run - これがドライランだったかどうかを示すブール値(オプション)
2. 終端のエラー — 処理されたクリエイティブなし:
  • errors - 操作レベルのエラーの配列(認証失敗、サービス利用不可)
3. Submitted タスクエンベロープ — 操作全体が非同期でキューに入れられた(バッチ取り込み、同期をゲートするガバナンスレビュー):
  • status - 常に "submitted"
  • task_id - tasks/get によるポーリングまたは完了時のウェブフック受信のためのハンドル
  • message - キューの状態を説明する任意の人が読めるテキスト
最終的なクリエイティブごとの creatives 配列は、submitted エンベロープではなくタスクの完了アーティファクトに載ります。アイテムごとの非同期レビュー(同期の残りが解決される間、一つのクリエイティブが pending_review になっている)は、ここではなく、その項目に status: "pending_review" を持つ同期的な成功の分岐に属します。 成功レスポンスの各クリエイティブに含まれるもの:
  • すべてのリクエストフィールド
  • platform_id - プラットフォームの内部 ID(actionfailed でない場合)
  • action - この同期が実行したライフサイクル操作: createdupdatedunchangedfaileddeleted
  • status - 助言的なレビューライフサイクルの状態(CreativeStatus): processingpending_reviewapprovedsuspendedrejectedarchived。UI のヒントおよびポーリングスケジューリングのシグナルであり、支出の認可ゲートではありませんaction と直交します——action は同期が何をしたかを、status はクリエイティブがレビューライフサイクルのどこにいるかを記述します。値は CreativeStatus のみに由来し、CreativeAction からは決して来ません(created/updated/failedstatus に入れないでください)。非同期レビューのセラーは processing または pending_review を返します。同期レビューのセラーは、終端の値(approved/rejected)や、回復可能な依存関係/認可のゲートが配信を妨げる場合に suspended を返してもよい(MAY)。バイヤーは、このレスポンスの status: approved に基づいて下流の支出やパッケージの有効化をゲートしてはなりません(MUST NOT)——支出をコミットする前に list_creatives または署名付きのレビューウェブフックで突き合わせてください。権威ある状態は常に list_creatives を介します。actionfailed または deleted の場合は省略されなければなりません(MUST)——失敗したアイテムには意味のあるレビュー状態がなく(errors を参照)、削除されたアイテムはライブラリから消えています。スキーマは条件付き制約によってこの省略ルールを強制します。
  • errors - エラーメッセージの配列(action: "failed" の場合のみ)
  • warnings - 非致命的な警告の配列(オプション)
完全なフィールドリストについてはスキーマを参照: sync-creatives-response.json

一般的なシナリオ

一括アップロード

1回の呼び出しで複数のクリエイティブをアップロードする:

ジェネレーティブクリエイティブ

クリエイティブエージェントを使用してブランドアイデンティティデータからクリエイティブを生成します。完全なワークフローの詳細はジェネレーティブクリエイティブガイドを参照。

ドライラン検証

アップロードせずにクリエイティブ設定を検証する:

creative_ids フィルターを使用したスコープ更新

大きなライブラリから特定のクリエイティブのみを更新し、その他には影響を与えない:
creative_ids フィルターを使用する理由:
  • スコープ更新: 指定されたクリエイティブのみが変更され、ライブラリに 100+ あっても同様
  • エラー復旧: 一括同期の検証失敗後に失敗したクリエイティブのみをリトライ
  • パフォーマンス: スコープが事前にわかっているとパブリッシャーが処理を最適化できます
  • 安全性: 明示的なターゲティングにより意図しない変更のリスクを低減

非同期承認ワークフロー

二つの異なる非同期パターンがあります——エージェントの振る舞いに応じて正しいものを選んでください: クリエイティブごとの非同期レビュー(一般的): 同期操作自体は同期的に解決されますが、1 つ以上のクリエイティブが下流のレビュー(ブランドセーフティ、ポリシーコンプライアンス)を必要とします。レビュー中のアイテムは、status: "pending_review"(または取り込み中は processing)とともに同期的な成功レスポンスで返ってきます。バイヤーは list_creatives またはウェブフックを通じて終端の状態を突き合わせます。 操作レベルの非同期(あまり一般的でない): 同期全体がキューに入れられます——取り込みがバッチ化されている、またはガバナンスレビューが同期全体をゲートしているため、セラーが応答前にアイテムごとの結果を返せません。レスポンスは submitted エンベロープです:
  • トップレベルの status: "submitted"task_id
  • message — 任意の人が読める説明
  • このエンベロープには creatives 配列なし
tasks/get をポーリングするか、ウェブフックを待ちます。完了アーティファクトが、アイテムごとの action/status の結果を持つ creatives 配列を運びます。操作レベルの失敗は、タスク上の status: "failed" として表面化します。 参照: ウェブフック設定についてはウェブフックを参照。

同期モード

アップサート(デフォルト)

  • creative_id で既存のクリエイティブを作成または更新します
  • パッケージアサインメントをマージする(追加的)
  • 提供されたフィールドを更新し、その他はそのままにします
  • 特定のクリエイティブにスコープを制限するために creative_ids フィルターを使用します

ドライラン

  • 変更を加えずにリクエストを検証します
  • エラーと警告を返す
  • アセットを処理したりクリエイティブを作成したりしません
  • プリフライト検証チェックに使用します

エラー処理

ベストプラクティス

  1. アップサートセマンティクスを使用する — 同じ creative_id で既存のクリエイティブを更新し、重複を作成しません。これにより反復的なクリエイティブ開発が可能。注意: アクティブな配信中のクリエイティブは更新がブロックされます(#7 を参照)。
  2. まず検証するdry_run: true を使用して実際のアップロード前にエラーをキャッチします。帯域幅と処理時間を節約できます。
  3. アサインメントをバッチ処理する — 更新間の競合状態を避けるために、すべてのパッケージアサインメントを1回の同期呼び出しに含めます。
  4. CDN ホストのアセット — 高速処理のために公開アクセス可能な CDN URL を使用します。プラットフォームはプロキシ遅延なしに直接アセットをフェッチできます。
  5. ブランドアイデンティティ — ジェネレーティブクリエイティブの場合、処理失敗を避けるために同期前にブランドアイデンティティスキーマを検証します。
  6. フォーマットサポートを確認する — アップロード前に list_creative_formats を使用してプロダクトがクリエイティブフォーマットをサポートしているか確認します。
  7. アクティブ配信の保護 — アクティブで一時停止されていないパッケージにアサインされているクリエイティブは、delete_missing で更新または削除できません。まずパッケージを一時停止するか、update_media_buy でクリエイティブのアサインを解除するか、別の creative_id で新しいクリエイティブを作成します。

関連タスク