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_kind と format_option_ref を優先すべきです。
build_creative バリアントのプロモート
バイヤーが生成されたビルドリーフを保持する場合、正準的なプロモートは、保持したbuild_variant_id を新しい creative_id として使うことです。セラーは別個のリネージマッピングを保持する必要はありません。デリバリーレポートは通常の creative_id を通じてビルドリーフに結合できます。
test=false
get_creative_delivery は creative_id を結合キーとして使います。保持した build_variant_id を使う代わりに別のライブラリ id を発行するワークフローは、将来のスコープ付きリネージフィールドが採用されない限り、このプロトコルで可視な結合を失います。
アセット構造
アセットはロール名をキーとします。各ロールにはアセットの詳細が含まれます:test=false
アサインメント構造
アサインメントはリクエストレベルにあり、クリエイティブ ID をパッケージ ID にマッピングします。メディアバイを管理しないスタンドアロンのクリエイティブエージェントはこのフィールドを無視します。test=false
published_post で、ペイロードにはアップロードされたメディアバイトではなく投稿 URL またはプラットフォームの投稿 ID が含まれます。バイヤーは、プラットフォーム固有の format_id を作成する代わりに、正準的なクリエイティブのパス(例: format_kind: "video_hosted" とプロダクトの format_option_ref)を通じてこれらのアセットを送信できます。セラーが投稿を解決できるが、投稿を所有するパブリッシャーのアイデンティティのような必要な下流のプラットフォーム接続を欠く場合、訂正可能なエラーは AUTHORIZATION_REQUIRED です。新しい実装は error.details.missing_connections[] を含めるべきで、呼び出し元は人を正しい接続フローに通し、認可が回復した後にリトライできます。
レスポンス
レスポンスは識別共用体を使います——レスポンスは三つの形のうちちょうど一つを持ち、混在することはありません: 1. 同期的な成功 — クリエイティブごとの結果:creatives- 処理された各クリエイティブの結果(成功と失敗の両方のアイテムを含む)dry_run- これがドライランだったかどうかを示すブール値(オプション)
errors- 操作レベルのエラーの配列(認証失敗、サービス利用不可)
status- 常に"submitted"task_id-tasks/getによるポーリングまたは完了時のウェブフック受信のためのハンドルmessage- キューの状態を説明する任意の人が読めるテキスト
creatives 配列は、submitted エンベロープではなくタスクの完了アーティファクトに載ります。アイテムごとの非同期レビュー(同期の残りが解決される間、一つのクリエイティブが pending_review になっている)は、ここではなく、その項目に status: "pending_review" を持つ同期的な成功の分岐に属します。
成功レスポンスの各クリエイティブに含まれるもの:
- すべてのリクエストフィールド
platform_id- プラットフォームの内部 ID(actionがfailedでない場合)action- この同期が実行したライフサイクル操作:created、updated、unchanged、failed、deletedstatus- 助言的なレビューライフサイクルの状態(CreativeStatus):processing、pending_review、approved、suspended、rejected、archived。UI のヒントおよびポーリングスケジューリングのシグナルであり、支出の認可ゲートではありません。actionと直交します——actionは同期が何をしたかを、statusはクリエイティブがレビューライフサイクルのどこにいるかを記述します。値はCreativeStatusのみに由来し、CreativeActionからは決して来ません(created/updated/failedをstatusに入れないでください)。非同期レビューのセラーはprocessingまたはpending_reviewを返します。同期レビューのセラーは、終端の値(approved/rejected)や、回復可能な依存関係/認可のゲートが配信を妨げる場合にsuspendedを返してもよい(MAY)。バイヤーは、このレスポンスのstatus: approvedに基づいて下流の支出やパッケージの有効化をゲートしてはなりません(MUST NOT)——支出をコミットする前にlist_creativesまたは署名付きのレビューウェブフックで突き合わせてください。権威ある状態は常にlist_creativesを介します。actionがfailedまたはdeletedの場合は省略されなければなりません(MUST)——失敗したアイテムには意味のあるレビュー状態がなく(errorsを参照)、削除されたアイテムはライブラリから消えています。スキーマは条件付き制約によってこの省略ルールを強制します。errors- エラーメッセージの配列(action: "failed"の場合のみ)warnings- 非致命的な警告の配列(オプション)
一般的なシナリオ
一括アップロード
1回の呼び出しで複数のクリエイティブをアップロードする:ジェネレーティブクリエイティブ
クリエイティブエージェントを使用してブランドアイデンティティデータからクリエイティブを生成します。完全なワークフローの詳細はジェネレーティブクリエイティブガイドを参照。ドライラン検証
アップロードせずにクリエイティブ設定を検証する: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フィルターを使用します
ドライラン
- 変更を加えずにリクエストを検証します
- エラーと警告を返す
- アセットを処理したりクリエイティブを作成したりしません
- プリフライト検証チェックに使用します
エラー処理
ベストプラクティス
-
アップサートセマンティクスを使用する — 同じ
creative_idで既存のクリエイティブを更新し、重複を作成しません。これにより反復的なクリエイティブ開発が可能。注意: アクティブな配信中のクリエイティブは更新がブロックされます(#7 を参照)。 -
まず検証する —
dry_run: trueを使用して実際のアップロード前にエラーをキャッチします。帯域幅と処理時間を節約できます。 - アサインメントをバッチ処理する — 更新間の競合状態を避けるために、すべてのパッケージアサインメントを1回の同期呼び出しに含めます。
- CDN ホストのアセット — 高速処理のために公開アクセス可能な CDN URL を使用します。プラットフォームはプロキシ遅延なしに直接アセットをフェッチできます。
- ブランドアイデンティティ — ジェネレーティブクリエイティブの場合、処理失敗を避けるために同期前にブランドアイデンティティスキーマを検証します。
-
フォーマットサポートを確認する — アップロード前に
list_creative_formatsを使用してプロダクトがクリエイティブフォーマットをサポートしているか確認します。 -
アクティブ配信の保護 — アクティブで一時停止されていないパッケージにアサインされているクリエイティブは、
delete_missingで更新または削除できません。まずパッケージを一時停止するか、update_media_buyでクリエイティブのアサインを解除するか、別のcreative_idで新しいクリエイティブを作成します。
関連タスク
list_creative_formats- アップロード前にサポートフォーマットを確認しますlist_creatives- ライブラリ内のクリエイティブをブラウズ・フィルタリングしますbuild_creative- ライブラリクリエイティブからマニフェストをビルドするか、ゼロから生成しますpreview_creative- クリエイティブマニフェストのプレビューを生成します- クリエイティブアセットタイプ - アセットの技術要件