Google広告の新しい広告クリエイティブを継続的に監視する方法

1. 最初の基準スナップショットを用意する

確認済みの広告主のうち、どの広告主をどのフィルター値で監視するかを正確に定めます。基準となる小規模な収集バッチを保存し、収集時刻、取得件数の上限、実行結果、対象範囲に関する注記を記録します。広告クリエイティブの行は、上書きせずに保存してください。

公開されているGoogle Ads Advertiser Monitor | Creative Snapshotsタスクは、Actorの入力設定を保存したものです。プリセットの入力は`{"targets": ["apple.com", "samsung.com"], "region": "US", "platform": "ALL", "adFormat": "ALL", "includeDeliveryDetails": false, "maxItems": 10}`です。ドメインからは複数のアカウントが見つかることがあるため、targetsは、確認済みの広告主を正確に指定するIDまたはURLに置き換えてください。`maxItems`は、すべての対象に共通する合計取得件数の上限です。日付の扱い方を含め、実際に使用したフィルターを記録してください。

1行は、観測した広告主と広告クリエイティブの1組を表します。正確な識別には、`advertiserId`と`creativeId`の組み合わせを使います。必須フィールドには、`creativeUrl`、`observedAt`、`requestedRegion`、`requestedPlatform`、`requestedFormat`、`status`、`statusReason`が含まれます。`firstShownAt`と`lastShownAt`は公開元の日付であり、自分が初めて観測した時刻ではありません。`variations`と`variationCount`は、配下の広告素材の詳細を表すもので、新しい広告クリエイティブIDではありません。

収集バッチIDと実行状況は、自分で管理するマニフェストに保存してください。行には`runId`フィールドがありません。公開元の総件数を推測で作ったり、件数上限のある実行が成功しただけで完全に収集できたと主張したりしないでください。出力と、実際に上限へ達したか、どの状態で停止したかを確認します。収集できた範囲を確認できない場合は、そのスナップショットに範囲が限定されていることを明記します。現時点での2行のメタデータに対する受け入れ確認は、2つの時点での監視テストではありません。

2. 次回以降の実行予定を決め、結果を検証する

目的に合った適切な間隔で、手動で再実行する時期を決めます。このタスクには定期通知の機能が組み込まれていません。対象アカウント、地域、広告形式、プラットフォーム、対象期間の決め方は同じにしてください。期間を順次ずらす必要がある場合は、比較する両方の実際の対象期間を記録し、期間外になった項目を削除されたものとして扱わないでください。

次回以降の実行結果は、比較の前に毎回検証します。収集が成功したこと、想定したアカウントであること、意図した対象範囲が同じであること、未処理の失敗がないことを確認し、件数上限や収集範囲の状態を正確に把握します。一部だけを収集したサンプルは、収集に成功してもサンプルのままです。失敗や収集結果が空であることは、公開元が明示的に0を表示または返した場合と区別してください。

3. バッチ間で識別キーの集合を比較する

バッチ内では、`advertiserId`と`creativeId`を使って行の重複を取り除きます。バッチをまたぐ観測履歴は残しつつ、比較には各バッチの識別キーの集合を使います。

今回の項目から前回の項目を差し引いたものには、「この比較で新たに観測」と記録します。前回の項目から今回の項目を差し引いたものには、「今回は未観測」と記録します。後者は、見つからないという理由だけで「削除済み」や「配信停止」と呼んではいけません。比較するのは、`advertiserId`と`creativeId`の両方が空欄でない組み合わせだけです。識別情報が欠けている項目は集合に含めず、未解決のままにします。

共通部分とは、両方の集合に含まれる識別キーです。和集合とは、どちらか一方または両方の集合に含まれるすべての識別キーから重複を取り除いたものです。

4. 新たに観測した広告クリエイティブを確認する

新たに観測した広告クリエイティブごとに公開元を開き、識別情報、公開元の日付、そのアカウントと広告クリエイティブの正確なキーをすでに処理したかどうかを確認します。プレビューを利用できない場合は、未確認の状態を維持します。発見が遅かった場合、初回表示日が古い日付になっていることがあります。その場合は、新規配信の開始として発表せず、その事実を報告してください。

通知用に、処理済みキーのテーブルを管理します。各キーには、初回観測日、確認状況、最終観測時刻、通知状況が必要です。通知の送信に失敗した場合の再試行は、データの再収集とは別に行います。同じ広告クリエイティブのキーでプレビューが変わった場合は、改訂内容の確認対象にできますが、新しい広告クリエイティブの通知には該当しません。こうした判断は明示的に記録してください。

比較結果を採用するたびに、確認待ちリストと各項目の対応結果を保存します。実行に失敗した後は、信頼できる基準スナップショットを更新しないでください。範囲が限定された実行でも、新たに観測した候補は得られます。ただし、その実行で見つからなかった識別キーの状態は、不明のままにする必要があります。

架空の具体例で手順を確認する

この例に登場する識別キー、日付、件数、出来事は、すべて架空のものです。

同じフィルター設定で広告主Aを調べる場合を考えます。

• バッチ1は、2026年10月1日12:00:00 UTCに収集しました。広告クリエイティブのキーは、A/C1、A/C2、A/C3です。範囲を限定したサンプルであることを記録します。通知処理済みの記録には、すでにC1、C2、C3が含まれています。
• バッチ2は、2026年10月8日12:00:00 UTCに収集しました。A/C2、A/C3、A/C4、A/C5が含まれています。これも範囲を限定したサンプルです。
• 今回の集合から前回の集合を差し引くと`{C4, C5}`となり、件数は2です。
• 前回の集合から今回の集合を差し引くと`{C1}`となり、件数は1です。
• 共通部分は`{C2, C3}`で、件数は2です。
• 和集合は`{C1, C2, C3, C4, C5}`で、件数は5です。
• これらのサンプルには取得件数の上限があるため、新しい項目2件と返された項目4件から増加率を算出しないでください。

次に、バッチ2の項目を調べます。

• 広告クリエイティブC4の公開元の`firstShownAt`は、2026年9月2日です。新たに観測したものですが、初めて表示されたのが今週ではないことは明らかです。
• 広告クリエイティブC5は`firstShownAt`の日付が不明なため、配信開始時期も不明です。
• 確認待ちリストの状態は次のとおりです。
• A/C4は新たに観測した項目で、公開元を確認済みです。公開元の日付は古いものですが、ライブラリに新たに加わった項目として通知します。
• A/C5は新たに観測した項目です。プレビューを利用できず、日付も不明なため、確認待ちです。
• C1は今回は観測されていません。比較範囲が限定されており、掲載状況は不明です。削除の通知は送信しません。

この架空の時系列で、その後の手順を確認します。

• 10月9日のバッチ3は失敗し、採用できる行は返されませんでした。バッチ2を、信頼できる直近の基準スナップショットとして維持します。バッチ3の失敗後に基準を更新せず、C2からC5までの削除通知も作成しません。
• 10月15日のバッチ4では、同じ対象範囲でC3、C4、C5、C6が返されます。検証を通過して採用したバッチ4を、バッチ2と比較します。
• 新たに観測した項目は`{C6}`です。
• 観測されなかった項目は`{C2}`です。
• 共通する項目は`{C3, C4, C5}`です。

• 広告クリエイティブC4は処理済みのため、重複した通知を防げます。広告クリエイティブC5は未確認です。広告クリエイティブC6は新たな確認対象です。C1またはC2は観測されていませんが、その掲載状況は不明です。管理台帳には、C4は通知済み、C5は確認待ち、C6は新たな確認対象、C1またはC2は未観測で掲載状況不明という行を漏れなく記録します。これは架空の例によるルールの確認であり、現在、公開元のすべてのデータを取得できることの証明ではありません。