How to Monitor New Google Ad Creatives Over Time

1. Set Up Your First Baseline Snapshot

Define exactly which checked advertisers and filter values you monitor. Save a small reference batch with collection time, result limit, run outcome, and any scope note. Save creative rows without overwriting them.

The public Google Ads Advertiser Monitor | Creative Snapshots task is a saved input preset for the actor. Its preset input is `{"targets": ["apple.com", "samsung.com"], "region": "US", "platform": "ALL", "adFormat": "ALL", "includeDeliveryDetails": false, "maxItems": 10}`. Replace targets with exact checked advertiser IDs or URLs since domains can resolve multiple accounts. `maxItems` is a shared cap across targets. Record your actual filters including date policy.

One row means one observed advertiser and creative. The exact identity uses `advertiserId` plus `creativeId`. Required fields include `creativeUrl`, `observedAt`, `requestedRegion`, `requestedPlatform`, `requestedFormat`, `status`, and `statusReason`. `firstShownAt` and `lastShownAt` are public source dates, not your first observation time. `variations` and `variationCount` are child asset details, not new creative IDs.

Keep your collection batch ID and run status in a reader-owned manifest. The row has no `runId` field. Do not invent a source total or claim completeness from a successful cap-limited run. Review output and its actual cap or stop status. If coverage cannot be established, label the snapshot limited. Current two-row metadata acceptance is not a two-time monitoring test.

2. Schedule and Validate Later Runs

Set a reasonable manual repeat time for your need. The task has no built-in recurring alert. Keep the same target account, region, format, platform, and date window policy. If a moving window is needed, record both actual windows and do not treat their exclusions as removals.

Validate each later run before you compare it. Check for a successful collection, expected accounts, the same intended scope, no unhandled failure, and an honest cap or coverage state. A successful partial sample remains a sample. Keep failures and empty collections distinct from an explicit source zero.

3. Compare Identity Sets Across Batches

Deduplicate rows within a batch by `advertiserId` and `creativeId`. Across batches, keep your observation history, but compare each batch's identity set.

Label current items minus previous items as newly observed in this comparison. Label previous items minus current items as not observed now. Never name the latter deleted or inactive solely from absence. Compare only non-blank `advertiserId` plus `creativeId` keys. Missing identity stays unresolved outside the sets.

Intersection means identities in both sets. Union means all distinct identities across both sets.

4. Review Newly Observed Creatives

Open each newly observed creative source and review its identity, source dates, and whether you have already processed that exact account and creative key. Keep an unreviewed state when the preview is unavailable. A late discovery may show an old first shown date. Report that instead of announcing a new launch.

Keep a processed-key table for alerts. Each key needs a first seen date, review status, last observed time, and alert state. Retry a failed alert separately from recollecting the data. A changed preview under the same creative key can be a revision review, but it is not a new-creative alert. Keep such decisions explicit.

Save your review queue and its disposition after every accepted comparison. Do not move the trusted baseline forward after a failed run. A limited run can produce new observed candidates, but its missing identities must remain unknown.

Fictional Worked Example

All identities, dates, counts, and events in this example are invented.

Imagine you check advertiser A with the same filter set:

• Batch 1 collected on October 1, 2026, at 12:00:00 UTC. It has creative keys A/C1, A/C2, and A/C3. You note it is a limited sample. Your processed alerts already contain C1, C2, and C3.
• Batch 2 collected on October 8, 2026, at 12:00:00 UTC. It has A/C2, A/C3, A/C4, and A/C5. It is also a limited sample.
• Current minus previous equals `{C4, C5}` with count 2.
• Previous minus current equals `{C1}` with count 1.
• Intersection equals `{C2, C3}` with count 2.
• Union equals `{C1, C2, C3, C4, C5}` with count 5.
• Do not turn 2 new items and 4 returned items into a growth rate because the samples are capped.

Next, you inspect the items in Batch 2:

• Creative C4 has source `firstShownAt` at September 2, 2026. It is newly observed, but clearly not first shown this week.
• Creative C5 has an unknown `firstShownAt` date, so its launch time is unknown.
• Review queue state:
• A/C4 is newly observed, source checked, has an old source date, and is alerted as new to the library.
• A/C5 is newly observed, preview is unavailable, date is unknown, and review is pending.
• C1 is not observed now, comparison is limited, availability is unknown, and no removal alert is sent.

Next steps in the fictional timeline:

• Batch 3 on October 9 fails and returns no accepted rows. You retain Batch 2 as your trusted last baseline. You do not move the baseline after failed Batch 3, and you do not produce removal alerts for C2 through C5.
• Batch 4 on October 15 returns C3, C4, C5, and C6 with the same scope. You compare accepted Batch 4 against Batch 2.
• Newly observed equals `{C6}`.
• Not observed equals `{C2}`.
• Common items equal `{C3, C4, C5}`.

• Creative C4 processed avoids repeat alert. Creative C5 is unreviewed. Creative C6 is a new review. C1 or C2 absence is unknown. Complete ledger rows include C4 alerted, C5 pending, C6 new review, and C1 or C2 absence unknown. This is a fictional rule check, not proof of current full source availability.