Google is converting existing Search campaigns to AI Max without a mutate call from your code. For a reporting integration, that is a data-quality event: campaign settings change under you, search term rows arrive with a new kind of provenance, and the legacy fields you may be selecting are scheduled to disappear from newer API versions. The Google Ads Developer Blog laid out the details in an August 12, 2026 post. This article translates it into the checks a reporting pipeline needs.

The timeline

Google splits the automigration into two phases.

Phase 1: campaign-level broad match and Automatically Created Assets (ACA). Starting September 1, 2026, Google Ads automatically upgrades Search campaigns using campaign-level broad match or standalone ACA to AI Max, rolling out progressively through the month. Google describes the campaigns as migrated in place rather than recreated.

Phase 2: Dynamic Search Ads (DSA). Legacy DSA campaigns are excluded from the September migration and continue to serve. The August post sets the DSA automigration for February 1 to 28, 2027, with unmigrated DSA campaigns upgraded to standard Search ad groups with AI Max enabled and the ability to create new DSA ad groups removed. An earlier June post had moved this from September 2026 and said DSA creation would be removed in January 2027, so the two posts differ on that detail. If your tooling creates DSAs, test against the August wording and confirm the cutoff before you rely on either.

On August 3, 2026, Google blocked creating new campaign-level broad match configurations or legacy ACA across the UI, Google Ads Editor, and all API versions. A script that still provisions campaigns with those settings should now be expected to fail.

What the migration does to settings

Google’s stated goal is continuity, and the default mappings are specific:

  • Campaign-level broad match campaigns: Text Customization off, Final URL Expansion off, Search Term Matching on. Existing brand inclusions and exclusions are preserved.
  • Standalone ACA campaigns: Text Customization on, Final URL Expansion off, Search Term Matching on.

If you store campaign settings alongside performance data, those are changes you did not make. The API gives you a clean way to find them. Starting in v25, the read-only fields Campaign.aca_migration_date_time and Campaign.broad_match_migration_date_time hold the timestamp of migration, in yyyy-MM-dd HH:mm:ss format in the customer’s time zone. Google’s example query selects both, filtered to values later than 1970-01-01 00:00:00. Because a campaign may have migrated from only one of the two legacy configurations, run the check so that either field being populated counts, and verify the filter behavior against your own accounts.

Use that timestamp to mark a series break. Any before-and-after comparison, such as cost per conversion in August versus October, should carry a flag for the migration date, in the customer’s time zone, not UTC.

New and changed reporting surfaces

Google’s AI Max reporting documentation describes the reporting surfaces to handle:

  • search_term_view with segments.search_term_match_source. This is how you isolate AI Max traffic in the standard search terms report. The documented values are AI_MAX_KEYWORDLESS (matches derived from website content, requiring no keyword), AI_MAX_BROAD_MATCH (expansion of existing keywords), and VERTICAL_ADS_DATA_FEED.
  • ai_max_search_term_ad_combination_view. The most granular view: the exact combination of search term and dynamic assets, with the landing page and headline used.
  • expanded_landing_page_view. URL performance aggregation.
  • final_url_expansion_asset_view and matched_location_interest_view, covering asset-level metrics for text customization and country-level geographic interest.

Check each view’s field reference for which metrics and segments it supports before you design a schema. Do not assume the combination view carries the same metrics as search_term_view.

Keyword joins are now lossy

Keyword-less matches have no keyword by definition. If your warehouse model joins search terms to ad_group_criterion rows to attribute spend to keywords, expect rows that cannot join. That is our inference from the documented definition, not a statement from Google, but it follows directly: a query matched from website content did not come from a keyword you can name. Keep the match source as a dimension and report unattributed terms in their own bucket, instead of dropping them in an inner join and watching totals fall short of the UI.

Landing pages are the other dimension that shifts. With Final URL Expansion, the page a user lands on can differ from the ad’s configured final URL, so URL-level reporting should come from the expansion views, not from the ad resource.

Version support and what breaks

The versioning rules matter more than the migration itself:

  • Any Google Ads API version released after September 1, 2026 will completely remove the legacy entities used to manage campaign-level broad match settings and ACA.
  • Previously released versions that are currently active continue to support those legacy settings until they reach their standard sunset. Google puts that at typically one year after introduction, around September 2027, at which point remaining legacy entities are permanently removed.

Two failure modes follow. If you upgrade your client library to a new major version and still select a removed field, GAQL returns an error for the whole query, not one missing column. And if you stay on an older version, the migrated state is still visible to you, but you carry a sunset date. Maintain a per-field compatibility map so the query builder emits only fields valid for the pinned version. The v25 migration-timestamp fields, for instance, will not exist for a pipeline pinned earlier.

On the write side, Google’s developer action plan warns that integrations should expect error codes when modifying, as opposed to pausing or deleting, legacy expanded dynamic search ads or criteria after they move to standard ad groups. If you manage ads programmatically, treat those errors as expected and route them to a review queue.

A short checklist

  1. Query the two migration timestamp fields daily through October and record them as campaign attributes.
  2. Snapshot campaign settings daily, including Campaign.ai_max_setting.enable_ai_max and the asset automation settings, so unexpected setting changes are visible in your own history.
  3. Add segments.search_term_match_source to search term pulls and keep it as a column.
  4. Replace keyword inner joins with left joins plus an unattributed bucket.
  5. Audit code that creates or edits campaign-level broad match, ACA, or DSA, using Google’s list of affected entities.
  6. Add an annotation layer so dashboards show the migration date on trend lines.
  7. Put the February 2027 DSA window and the September 2027 sunset of older API versions on the roadmap now.

The migration is progressive across September, so an integration that records the timestamps and match sources from the start will be able to explain its own numbers later. One that does not will spend the first quarter of 2027 reconstructing them.