(Translated by https://www.hiragana.jp/)
Google Ads Developer Blog: 2025

Today we’re announcing the deprecation of Structured Data Files (SDF) v7. This version will sunset on November 4, 2025.

Migrate to SDF v7.1 or higher before the sunset date to avoid any interruption of service. See the differences between SDF v7 and v7.1 in the v7.1 release notes.

Today we’re announcing the deprecation of Structured Data Files (SDF) v7. This version will sunset on November 4, 2025.

Migrate to SDF v7.1 or higher before the sunset date to avoid any interruption of service. See the differences between SDF v7 and v7.1 in the v7.1 release notes.

After November 4, 2025, the following changes will apply to all users:

If you run into issues or need help with your migration, please contact us using our new Display & Video 360 API Technical support contact form.

The open beta launch of AI Max for Search campaigns in the Google Ads UI will begin on 27 May 2025.

While full AI Max for Search campaigns support in the ...
The open beta launch of AI Max for Search campaigns in the Google Ads UI will begin on 27 May 2025.

While full AI Max for Search campaigns support in the Google Ads API is planned for v21 in August 2025, we want to ensure you're prepared for the open beta rollout and understand its potential impact on your API interactions.

What is AI Max for Search campaigns?
What is Changing?
During the open beta period, before full API support arrives in v21, there will be a transitional phase. Here's what API users need to know:
  1. Feature Grouping in the UI: When a user enables AI Max for Search campaigns for a campaign in the Google Ads UI, several legacy features will be grouped into the new AI Max for Search campaigns settings:
    • Text customization (formerly known as Automatically created assets (ACA))
    • Campaign-level broad match (the setting itself)
    • Brand inclusions (previously tied to campaign-level broad match)
    • Campaign-level brand exclusions
  2. Potential API Conflicts During Transition: Once AI Max for Search campaigns has been enabled and then disabled for a campaign via the UI, managing its associated features (ACA, brand list inclusions/exclusions) using any API version is subject to feature grouping and may cause errors. Starting with v21, AI Max for Search campaigns can be activated through the API.
    • Why? Disabling AI Max for Search campaigns in the UI during this interim period doesn't fully revert the underlying settings configuration back to the pre-AI Max for Search campaigns state compatible with older API versions for these specific features.
    • Campaign-Level Broad Match: Attempts to toggle the campaign-level broad match setting via the API will be allowed but may function differently depending on the AI Max for Search campaigns state. Keywords will still be converted to Broad Match if the setting is enabled via the API, but the primary control mechanism moves to AI Max for Search campaign.
    • Text customization: Attempts to deactivate text customization via API requests will raise an error if Final URL expansion is enabled in the UI.
  3. Mitigation - UI Warnings: To prevent accidental disruption, the Google Ads UI will display warning messages when enabling or disabling AI Max in Search campaigns for campaigns that use these legacy features, explicitly mentioning the potential impact on API workflows during this beta period.
  4. Recommendation: We strongly advise coordinating within your teams. If your organization relies heavily on API workflows for managing ACA or Brand Lists, be cautious about enabling and then disabling AI Max in Search campaigns in the UI for those campaigns until full API support lands in v21 in August 2025.
What Stays the Same:
  • You can continue to manage existing Search campaigns using ACA, campaign-level broad match, and brand exclusions via the current API version (v19) as long as AI Max in Search Campaigns has not been enabled and then disabled for those specific campaigns in the UI.
  • Ad Group level Brand Inclusions and Locations of Interest (LOI) pilots (outside of AI Max for Search campaigns) are ending. Functionality for these will only be available within AI Max for Search campaigns going forward.
Preparing for the Future - v21 and beyond:
  • Full Support Coming: API v21 (planned for August 2025) will introduce dedicated fields and services to fully manage all AI Max for Search campaigns features, including the new consolidated controls.
  • Legacy Field Deprecation: Following the launch and adoption of v21, older API versions will sunset. At that point, the legacy fields for ACA, campaign-level broad match, and standalone brand exclusions/inclusions will be fully deprecated and removed from the API.
If you have any questions, please contact us on the forum.

We previously announced our 2025 Google Ads API release plans. We are introducing a few changes to this schedule as a part of our ongoing efforts to evolve our release process. The new schedule lets us make various product features available earlier in the Google Ads API. As usual, additional details on new features will follow as part of the release notes for individual versions.

We previously announced our 2025 Google Ads API release plans. We are introducing a few changes to this schedule as a part of our ongoing efforts to evolve our release process. The new schedule lets us make various product features available earlier in the Google Ads API. As usual, additional details on new features will follow as part of the release notes for individual versions.

  1. V20_1 will be upgraded to a major version and named V21.
  2. V21 will be renamed to V22.
  3. We will add two minor releases (v19_2, v20_1) alongside V21 to add these features in existing Google Ads API versions.
  4. The projected launch dates will remain unchanged.

Here’s our updated schedule.

Version Planned Release

Type

Projected launch Projected sunset
V20 Major June/July 2025 June 2026
V21 Major August/September 2025 August 2026
V19_2 Minor August/September 2025 February 2026
V20_1 Minor August/September 2025 June 2026
V22 Major October/November 2025 October 2026

Please take a look at your future plans to make sure they still align with the upcoming Google Ads API release schedule.

How to get help

If you have any questions or need help, check out the Google Ads API support page for options.

IMA Android version 3.35.1 adds the ImaSdkFactory.initialize() method. This call begins loading necessary SDK resources before the first ad request, leading to faster load times. These changes can limit ad buffering, and help maximize ad impressions and monetization. Depending on the device, the loading process can take several seconds to complete.

IMA Android version 3.35.1 adds the ImaSdkFactory.initialize() method. This call begins loading necessary SDK resources before the first ad request, leading to faster load times. These changes can limit ad buffering, and help maximize ad impressions and monetization. Depending on the device, the loading process can take several seconds to complete.

We strongly recommend making the initialize() call as soon as possible after the app starts. This approach shortens the time to first frame for pre-roll ads, thus limiting the time users are waiting and increasing monetization potential.

For applications that implement these load time improvements, the following benefits show:

  • An average decrease of 0.25 to 0.5 seconds in time to first frame.
  • With larger decreases for TV implementations, up to a five second improvement.

The following diagram shows an app using the initialize() method call to load system resources before a user selects a video:

The ImaSdkFactory.initialize() call accepts an ImaSdkSettings instance. Use the same settings values that are used to create any AdsLoader instances in the app. For client-side and DAI for more information, see optimize IMA load time . If you have any questions, feel free to reach out using the IMA technical forum.

Today, we’re announcing the April 2025 update to the Display & Video 360 API. This update includes the following:

Today, we’re announcing the April 2025 update to the Display & Video 360 API. This update includes the following:

In addition to these new features, This update also includes a fix for a known issue that caused advertisers.list requests to ignore provided orderBy parameters.

For more details, see the Display & Video 360 API release notes. Before using these new features, make sure to update your client library to the latest version.

If you need help with these new features, please contact us using our new Display & Video 360 API Technical support contact form.

Google Ads API v17 will sunset on June 4, 2025. After this date, all v17 API requests will begin to fail. Migrate to a newer version prior to June 4, 2025 to ensure your API access is unaffected.
Google Ads API v17 will sunset on June 4, 2025. After this date, all v17 API requests will begin to fail. Migrate to a newer version prior to June 4, 2025 to ensure your API access is unaffected.

Here are some resources to help you with the migration: You can view a list of methods and services your project has recently called using the Google Cloud Console:
  1. In the Google Cloud Console, open the APIs & Services tab.
  2. In the table, click Google Ads API.
  3. On the METRICS subtab, you should see your recent requests plotted on each graph. You can see which methods you've sent requests to in the Methods table. The method name includes a Google Ads API version, a service, and a method name, such as google.ads.googleads.v17.services.GoogleAdsService.Mutate.
  4. (Optional) Choose the timeframe you want to view for your requests.
If you have questions while you’re upgrading, reach out to us on the forum or at googleadsapi-support@google.com.

Today, we’re announcing the v19.1 release of the Google Ads API. To use any of the v19.1 features, you must upgrade your client libraries and client code. The updated client libraries and code examples will be published next week. This release includes no breaking changes and maintains backwards compatibility for those who have already upgraded to v19.

Today, we’re announcing the v19.1 release of the Google Ads API. To use any of the v19.1 features, you must upgrade your client libraries and client code. The updated client libraries and code examples will be published next week. This release includes no breaking changes and maintains backwards compatibility for those who have already upgraded to v19.

Here are the highlights:

Where can I learn more?

The following resources can help you get started:

If you have any questions or need additional help, contact us via the forum.

We're excited to introduce Google's approach to Server Guided Ad Insertion (SGAI), designed to unlock key benefits:

  • Flexibility: Support for new innovative ad formats to meet publisher’s diverse needs
  • Control: Greater control over ad break scheduling
  • Efficiency: Resource savings and operational simplification

We're excited to introduce Google's approach to Server Guided Ad Insertion (SGAI), designed to unlock key benefits:

  • Flexibility: Support for new innovative ad formats to meet publisher’s diverse needs
  • Control: Greater control over ad break scheduling
  • Efficiency: Resource savings and operational simplification

SGAI is an ad insertion method where an ad server instructs the video player on how to manage ad transitions dynamically within the content stream. This technique blends the advantages of two common methods: it offers the seamless ad integration seen in server-side insertion (SSAI) and the implementation ease found in client-side insertion (CSAI). SGAI’s ability to support non-intrusive ad experiences, such as squeezebacks and L-banners, where advertisements appear alongside the continuously playing content, creates prominent branding opportunities and experiences alongside content.

In this post, we'll address the key questions on the core concepts and benefits of this exciting new technology.

What is the "server-guided" part in SGAI?

SGAI uses Google Dynamic Ad Insertion (DAI) to perform ad selection, transcoding, and return the ad pod manifest for the entire ad break, ready for the video player to load and play just like a content stream.

The server-guided aspect highlights the collaborative nature of ad delivery in SGAI. While Google DAI servers do the heavy lifting of building and delivering the ad break, the client app and video player takes control of the ad break timing and insertion.

Control over ad break scheduling

To control the ad break timing, you can use your own infrastructure, such as a packager, an encoder, a manifest manipulator or a direct notification to the client app. Ahead of the ad breaks, you can use the Ad Manager’s Early Ad Break Notification API to create and schedule upcoming ad breaks, optimizing ad fill rate for high concurrency livestream events.

Using these tools, you define the expected start time, duration, and metadata of the ad break and signal Google Ad Manager, your client app and the video player to prepare and play the ad break.

How flexible is SGAI?

There are two different methods of using server guided ad insertion to meet diverse publisher needs:

  • Client-side ad stitching: the client app listens to the video player's timed metadata for upcoming ad break events or follows a preset ad schedule. The client app proactively loads the ad break manifest.
    At ad break start, the client app can switch between content and ad, or arrange both content and ads simultaneous playbacks to implement innovative ad formats, such as squeezeback, L-banner, side-by-side windows.
  • Server-side ad stitching: the packager, or encoder, inserts an ad marker pointing to the ad manifest into the content manifest. The video player reactively loads the ad break manifest and switches between content and ad in due time.

We design our SGAI to work with standards, such as HLS interstitials and the upcoming DASH specification. This allows for easy interoperability across different players, client platforms and streaming tech stacks.

How does SGAI client-side ad stitching work?

This section covers an SGAI client-side example in which the video player parses SCTE-35 markers in the content manifest and schedules an ad break. This approach offers server resource savings and operational simplification.

The livestream flow has the following key steps:

  1. The client app loads the IMA SDK to create DAI pod serving stream sessions and process ad events.
  2. The client app uses a video player for playback, and constructs the HLS or DASH ad pod manifest URLs, incorporating SCTE-35 data as needed.
  3. A few seconds before the expected ad break time, the video player loads the ad pod manifest. At the beginning of the ad break, the client app switches from the content to the ad playback.

How does SGAI server-side ad stitching work?

Livestream workflows with SGAI server-side ad stitching follow similar steps above, but a packager inserts ad markers pointing to ad pod manifest URLs shortly before each ad break.

Next Steps

We encourage you to explore SGAI documentation to create premium ad experiences with efficiency and adaptability. To get started on using SGAI, contact your Google account manager.

- Thang Duong, Ads Developer Relations and Sourya Roy, Senior Product Manager, Google Ad Manager

Today we’re announcing the general availability of Structured Data Files v8.1. All users can now use SDF v8.1 to upload and download SDFs in the Display & Video 360 UI, and to download SDFs through the Display & Video 360 API.

Today we’re announcing the general availability of Structured Data Files v8.1. All users can now use SDF v8.1 to upload and download SDFs in the Display & Video 360 UI, and to download SDFs through the Display & Video 360 API.

SDF v8.1 adds support for controlling inventory source settings for Demand Gen ad groups, enforces OMID targeting set at the advertiser level, and renames TrueView Content Filter column to Inventory Mode in “Line Item” and “Insertion Order” files.

In addition to launching SDF v8.1, we are also announcing the following two breaking changes to Structured Data Files that will go into effect on April 22, 2025:

  • You will no longer be able to create YouTube video action line items using SDF. Instead, customers should create Demand Gen line items. Any attempted creation of line items using SDF upload with a Subtype column value of “Action” and a Type column value of “TrueView” will fail.
  • You will be required to include the value “Video Partners” in the TrueView Inventory Source Targeting column of line items with the Type column value of “Demand Gen”. Once this enforcement begins, the value will be backfilled for existing line items and included when downloading new Structured Data Files. To control whether ad groups within Demand Gen line items serve on Google Display Network inventory, you will be required to update to SDF v8.1 and set your desired values in the Demand Gen Inventory Source Strategy and Demand Gen Enabled Inventory Sources columns for ad groups. More details on this renaming and inventory expansion can be found in the Display & Video 360 Help Center.

Full details on the changes between v8 and v8.1 can be found in the Structured Data Files release notes. If you are still using v6, v7 or v7.1, you can follow the instructions in our v7 and v8 migration guides.

If you run into issues or need help with this new version, please follow the instructions in our support guide, or contact us using our contact form.

Today, we are deprecating Display & Video 360 API v3. We will sunset v3 on October 7, 2025. Please migrate to Display & Video 360 API v4 before the sunset date to avoid an interruption of service.

Today, we are deprecating Display & Video 360 API v3. We will sunset v3 on October 7, 2025. Please migrate to Display & Video 360 API v4 before the sunset date to avoid an interruption of service.

New features will not be added to v3 now that it is deprecated. All new feature releases will target v4 exclusively. Read our release notes for more information on updates made to the API in v4 and see our GitHub repository for new code samples using v4. Follow the steps in our v4 migration guide to migrate.

If you run into issues or need help with this new version, please follow the instructions in our support guide or contact us using our contact form.

Previously, if any Google Ads API request had an invalid developer token, the API returned an OAUTH_TOKEN_HEADER_INVALID error, which is also used for other invalid request header values. To make it clear when the authentication error is specifically caused by an invalid developer token, we are changing the API to return a new error code, DEVELOPER_TOKEN_INVALID, for version v19.1 of the Google Ads API. All API versions before v19 will handle invalid developer tokens by throwing a DEVELOPER_TOKEN_NOT_APPROVED error instead. If you are using version v19 of the API with our client libraries, you will need to update to the latest version of the client libraries after the v19.1 release. These changes will be effective starting April 28, 2025.

Previously, if any Google Ads API request had an invalid developer token, the API returned an OAUTH_TOKEN_HEADER_INVALID error, which is also used for other invalid request header values. To make it clear when the authentication error is specifically caused by an invalid developer token, we are changing the API to return a new error code, DEVELOPER_TOKEN_INVALID, for version v19.1 of the Google Ads API. All API versions before v19 will handle invalid developer tokens by throwing a DEVELOPER_TOKEN_NOT_APPROVED error instead. If you are using version v19 of the API with our client libraries, you will need to update to the latest version of the client libraries after the v19.1 release. These changes will be effective starting April 28, 2025.

Anyone who has already set up the Google Ads API to make successful calls are highly unlikely to be affected by this change. It is mainly meant to improve the experience of new developers onboarding to the API.

If you have any questions, please ask them in the Google Ads API forum. We're here to help!

Starting on May 1, 2025, we will begin to automatically enable brand guidelines for Performance Max campaigns that use the same brand assets ( BUSINESS_NAME, LOGO, and ...
Starting on May 1, 2025, we will begin to automatically enable brand guidelines for Performance Max campaigns that use the same brand assets (BUSINESS_NAME, LOGO, and LANDSCAPE_LOGO) across all asset groups.

Please note the rollout timelines:
  • For Google Ads UI users: The process will begin on May 1, 2025 for customer IDs that exclusively manage their campaigns using the UI.
  • For API users: This process will begin on June 1, 2025.
The overall process across all campaigns is expected to be complete by July 31, 2025.

Important Notes:
  • Only campaigns using consistent business names and logo assets across all asset groups will be automatically migrated. Campaigns with variations in these assets will not be migrated.
  • All eligible Performance Max campaigns under a customer ID will be migrated simultaneously.
  • After migration, each migrated campaign will have its own set of brand assets stored at the campaign level using CampaignAsset.
  • You can tell if a campaign has been migrated by checking its Campaign.brand_guidelines_enabled field.
Actions Required
If your application creates asset groups, update your code to check the campaign’s Campaign.brand_guidelines_enabled field. This will tell you whether to include brand assets in the new asset group.

If your application modifies brand assets, update your code to check the campaign’s Campaign.brand_guidelines_enabled field. This will tell you where to save the brand asset; either on a campaign using a CampaignAsset or on an asset group using an AssetGroupAsset.

To avoid extra steps later, we strongly recommend migrating all of your campaigns now using CampaignService.EnablePMaxBrandGuidelines. If you migrate your campaigns manually, each CampaignService.EnablePMaxBrandGuidelines request can only include 10 EnableOperations.

If you have any questions or need help, check out the Google Ads API support page for options.

We’re pleased to announce that we are promoting Display & Video 360 API v4 from beta to general availability. With v4 entering general availability, it is now our recommended version. Our guides have been updated to reflect v4 features and conventions.

We’re pleased to announce that we are promoting Display & Video 360 API v4 from beta to general availability. With v4 entering general availability, it is now our recommended version. Our guides have been updated to reflect v4 features and conventions.

We recommend migrating from v3 to v4 at your earliest convenience, as v3 will be deprecated and sunset in the coming months. See instructions on migrating to v4 in our migration guide and an exhaustive list of changes made in v4 in our February 13, 2025 release notes.

Before trying to call v4, make sure to update your client library to the latest version.

If you run into issues or need help using this new version, please contact us using our support contact form.

As of v17 of the Google Ads API, recommendations of type LOWER_TARGET_ROAS have included a current_average_target_micros as a whole currency value instead of a micros value (where one million is equivalent to one currency unit) as indicated by the field name. On April 23, 2025, we are rolling out a fix to populate current_average_target_micros with the micros value.

As of v17 of the Google Ads API, recommendations of type LOWER_TARGET_ROAS have included a current_average_target_micros as a whole currency value instead of a micros value (where one million is equivalent to one currency unit) as indicated by the field name. On April 23, 2025, we are rolling out a fix to populate current_average_target_micros with the micros value.

Note that as a result of the incorrect unit, the currently returned current_average_target_micros value is truncated and is therefore less precise than the micros equivalent. If you were converting the existing value to micros by multiplying by 1,000,000, the resulting value wouldn't necessarily be correct because any digits past the first position are dropped. For example, a current_average_target_micros value of 5 might have been converted to 5,000,000 in micros before the change, but could be returned as 5,750,000 (more precise) after the change.

What do I need to do?

If you use the Google Ads API or Google Ads scripts to query the recommendation resource for recommendations of type LOWER_TARGET_ROAS, and your application logic uses the current_average_target_micros field, you must update your application to treat the value as micros instead of a whole budget value for when the change takes effect on April 23, 2025.

If you have any questions or need help, check out the Google Ads API support page for options.

Historically, we have always heard from the Google Ads API developer community that code examples are one of the most useful tools to learn about the API and its features. For a long time, however, our API documentation offered code examples for the Google Ads client libraries, but not for REST. We've heard requests from the community to offer more REST code examples, and so we've been working hard to create and integrate a rich set of REST examples directly into our developer documentation.
Historically, we have always heard from the Google Ads API developer community that code examples are one of the most useful tools to learn about the API and its features. For a long time, however, our API documentation offered code examples for the Google Ads client libraries, but not for REST. We've heard requests from the community to offer more REST code examples, and so we've been working hard to create and integrate a rich set of REST examples directly into our developer documentation.

Now, alongside client library examples, you'll find corresponding REST examples showing you exactly how to structure your curl commands or equivalent code in your preferred language to perform common operations like:
  • Create customer accounts
  • List accessible accounts
  • Manage recommendations
  • Generate keyword ideas
  • And more!
You can find these examples in relevant sections of the Google Ads API documentation on our developer site. For instance, when you look at the guide for listing accessible accounts, you'll now see a "cURL" tab alongside other language options, providing a clear and concise REST-based example.

At the moment, we've added a small, but substantial, subset of examples. We're adding more soon.

Have ideas for additional REST examples?
You can help us prioritize which examples to add and also help implement them. To request a specific code example, open an issue on the REST code examples GitHub repository. You can also open pull requests to help create new examples, or expand the existing ones. Our team will review your submission, and your contribution could help other Google Ads API users.

We hope this addition of REST examples, driven by your valuable feedback, will significantly improve the development experience for a wide range of Google Ads API users. We're excited to see how these examples help you build even more innovative solutions.

Over the next several Google Ads API updates, we'll be adding new types of resources you can track using the ChangeStatus feature.

What this means for you:
  • More detailed tracking: You'll soon be able to better track changes to your Google Ads accounts.
  • Important - Check for UNKNOWN changes: Even in older versions of the API, you might start seeing new change entries. These entries will show up as UNKNOWN resource types because the older versions won’t support the new values.
Over the next several Google Ads API updates, we'll be adding new types of resources you can track using the ChangeStatus feature.

What this means for you:
  • More detailed tracking: You'll soon be able to better track changes to your Google Ads accounts.
  • Important - Check for UNKNOWN changes: Even in older versions of the API, you might start seeing new change entries. These entries will show up as UNKNOWN resource types because the older versions won’t support the new values.
How to prepare:
  • Handle UNKNOWN: If your app uses ChangeStatus, make sure it can handle entries with a resource type of UNKNOWN. This will prevent errors when the new types are added.
  • Update to the latest API version: Once the new version is released, updating your app will show the correct, specific names of the new change types instead of UNKNOWN.
  • We'll announce the exact new resource types in the release notes when the update is live.
If you have any questions, please ask them in the Google Ads API forum. We're here to help!

Version 24.0.0 of the Android Google Mobile Ads SDK is now available. To take advantage of the latest features and performance improvements, we highly recommend you configure your app to upgrade as soon as possible. Major changes to the SDK are as follows:

Version 24.0.0 of the Android Google Mobile Ads SDK is now available. To take advantage of the latest features and performance improvements, we highly recommend you configure your app to upgrade as soon as possible. Major changes to the SDK are as follows:

Minimum Android API level

Starting with version 24.0.0, the Google Mobile Ads SDK requires all apps to be on a minimum Android API level of 23. To adjust the API level, change the value of minSdk in your app-level build.gradle file to 23 or higher.

Optimized initialization and ad loading

By default, The OPTIMIZE_INITIALIZATION and OPTIMIZE_AD_LOADING flags are now generally available and set to true. These flags help reduce ANRs. You can further prevent ANRs by initializing the Google Mobile Ads SDK on a background thread. For more information, see Optimize initialization and ad loading.

Removed ad services config in AndroidManifest.xml

To prevent merge conflicts for apps that configure API-specific Ad Services, we've removed the android.adservices.AD_SERVICES_CONFIG property tag from the SDK’s manifest file. This change provides greater flexibility for developers who need to customize their Ad Services configurations.

SDK deprecation and sunset timelines activated

With this Android major version 24 launch and the iOS major version 12 launch last month, new deprecation and sunset dates for older releases are as follows:

  • Android Google Mobile Ads SDK versions 22.0.0 - 22.6.0 are officially deprecated, and will sunset in June 2026.
  • Android versions 21.x.x and iOS versions 9.x.x will sunset on June 30, 2025.
    • While there are currently no plans to disable ad serving on Android versions 21.x.x and iOS versions 9.x.x, we strongly recommend updating to the latest SDK version to avoid future impactions.

For a complete list of changes in v24.0.0 and detailed migration steps, check the release notes and SDK migration guide. If you have any questions or need additional help, contact us through Mobile Ads SDK Support.

We are introducing several changes to the CustomerService.CreateCustomerClient method to align the Google Ads API with how Google Ads UI handles new account creation functionality. These changes will take effect on ...
We are introducing several changes to the CustomerService.CreateCustomerClient method to align the Google Ads API with how Google Ads UI handles new account creation functionality. These changes will take effect on March 17, 2025.

New error codes for policy enforcement
In order to limit abuse, the Google Ads API introduced two new error codes in the version v19 of the API for the purpose of policy enforcement.
  1. Google Ads manager accounts that do not have a certain threshold of spending or a certain number of active child accounts without policy issues (for example, not suspended or closed for policy violations) will be ineligible to create child accounts under them. Developers will receive a CustomerError.CREATION_DENIED_INELIGIBLE_MCC error code in the upcoming version v19 of the Google Ads API. To fix the issue, link a Google Ads account that is compliant with the Google policies and meets the threshold spending levels under your manager account.
  2. Google Ads manager accounts that have been flagged for policy violations related to account creation will no longer be able to create child accounts under them. Developers will receive a CustomerError.CREATION_DENIED_FOR_POLICY_VIOLATION error code in the upcoming version v19 of the Google Ads API.
In both these cases, existing API versions (v18 and older) will throw a ContextError.OPERATION_NOT_PERMITTED_FOR_CONTEXT error instead.

Quota limits for account creation
The Google Ads API will enforce limits on creation of new Google Ads accounts. Developers will receive a QuotaError.RESOURCE_EXHAUSTED error once the limits are reached. The retry_delay field of the quota_error_details contains additional details on how long you should wait before retrying the API call. We do not expect most developers to be affected by these limits.

What do I need to do?
If your application uses the Google Ads API to create new Google Ads accounts, you should review your code to ensure that your application correctly handles these new error codes.

If you have any questions or need help, check out the Google Ads API support page for options.Reach out to the Google Ads product support team for any questions related to account policies.

Today, we’re announcing the v19 release of the Google Ads API. To use some of the v19 features, you will need to upgrade your client libraries and client code. The updated client libraries and code examples will be published next week.
Today, we’re announcing the v19 release of the Google Ads API. To use some of the v19 features, you will need to upgrade your client libraries and client code. The updated client libraries and code examples will be published next week.

Here are the highlights:
  • Added support automatically generating enhanced video assets for Performance Max campaigns.
  • Removed all feed-related entities from the Google Ads API like Feed, FeedMapping, FeedService, AdGroupFeed, feed_placeholder_view. Users should now use assets to achieve the same purpose.
  • Demand Gen ads now support 9:16 portrait image assets. Use DemandGenMultiAssetAdInfo.tall_portrait_marketing_images to include these assets in your ads.
  • Added more methods to DataLinkService for updating and removing previously created DataLink for YouTube.
  • ValueRuleItineraryAdvanceBookingWindow now supports targeting for travel searches that take place today.
  • Removed support for VIDEO_OUTSTREAM.
  • (For allowlisted accounts only) Updates to brand guidelines
    • Brand guidelines can now be enabled for Performance Max campaigns during campaign creation. We also added a new CampaignService.EnablePMaxBrandGuidelines which allows you to enable brand guidelines for existing Performance Max campaigns.
    • You can set the brand guidelines’ details such as font family and colors using Campaign.brand_guidelines.
  • (For allowlisted accounts only) Added support for message assets through Asset.business_message_asset.
Where can I learn more?
The following resources can help you get started: If you have any questions or need additional help, contact us via the forum.

We're pleased to announce that v202502 of the Google Ad Manager API is now available. This is a maintenance release to add new error types for entity limits.

For the full list of changes, check the release notes. Contact us on the Ad Manager API forum with any API-related questions.

We're pleased to announce that v202502 of the Google Ad Manager API is now available. This is a maintenance release to add new error types for entity limits.

For the full list of changes, check the release notes. Contact us on the Ad Manager API forum with any API-related questions.

What’s changing?
Starting the week of May 1 2025, we will roll out consent unbundling for OAuth user authentication to all Google Cloud projects which were created before 2019. If you own an application that uses an Ads-related API through a Google Cloud project created before 2019, you may need to update your application to handle unbundled user consent before ...
What’s changing?
Starting the week of May 1 2025, we will roll out consent unbundling for OAuth user authentication to all Google Cloud projects which were created before 2019. If you own an application that uses an Ads-related API through a Google Cloud project created before 2019, you may need to update your application to handle unbundled user consent before May 1 2025.

Background
Consent unbundling for OAuth user authentication flow allows users to customize which specific OAuth scopes they want to authorize your application for, rather than an all-or-nothing approach. All the Google Cloud console projects created since 2019 have this feature turned on, whereas all the projects created before 2019 have this feature turned off.

The following screenshot shows the difference between an all-or-nothing consent prompt, and an unbundled consent prompt. Figure 1: All-or-nothing consent screen. Users aren’t allowed to choose from a list of OAuth scopes.

Figure 2: Unbundled consent screen. Users are allowed to choose from a list of OAuth scopes.

Who is affected by this change?
You will be affected by this change if ALL of the following conditions are met:
  1. Your API application uses a Google Cloud Console project that was created before 2019.
  2. Your application implements the OAuth 2.0 user consent flow – an authentication workflow where the user logs in with their Google account and grants one or more permissions that your application is requesting.
  3. Your application uses more than one Google API, and one of the APIs is an Ads-related API listed below.
Who isn’t affected by this change?
  • Existing refresh tokens: This change doesn’t affect user authentications that you already have in place. Your existing refresh tokens will continue to work without any changes or re-authentication.
  • Single scope applications: If your application uses only one Google API scope, your application isn’t affected by this change, since there aren’t multiple OAuth scope to unbundle.
  • Single user applications / Manually authenticated applications: Your application doesn’t have an explicit OAuth user authentication flow implemented. Instead, you use a manual authentication script such as GenerateUserCredentials, gcloud CLI or OAuth Playground to authenticate the user, and then use those credentials for a long period of time. Since you select all the scopes that your application requires while authenticating, your application isn’t affected by this change.
  • Service accounts: If your application uses a service account to authenticate your API calls, you won’t be affected by this change

What do I need to do?
You need to ensure that your application can handle partial user consent. To do this,
  1. Request the list of OAuth scopes that the user consented to by including the include_granted_scopes parameter in your OAuth flow.
  2. Examine the actual list of OAuth scopes that the user consented in the OAuth response.
  3. Implement incremental authorization in your application.
Review our OAuth granular consent guide to learn about the requirements and best practices to handle granular consent.

How do I test this feature?
There are two ways to test this feature:
  1. Create a new Google Cloud project: New Google Cloud projects have enabled OAuth consent unbundling. So you can create a new Google Cloud project, and use it for testing your application.
  2. Enable consent unbundling in your existing project: You can set the enable_granular_consent parameter to true in your OAuth authorization request.
Which API scopes are affected?
The following APIs related to Ads are affected by this change.
API OAuth Scope
Google Ads API https://adwords.google.com/api/adwords
Google Ad Manager API (SOAP API, Beta) https://www.googleapis.com/auth/dfp
https://www.googleapis.com/auth/admanager
Bid Manager API https://www.googleapis.com/auth/doubleclickbidmanager
Content API for Shopping https://www.googleapis.com/auth/content
Display and Video 360 API https://www.googleapis.com/auth/display-video-mediaplanning
https://www.googleapis.com/auth/display-video-user-management
AdMob API https://www.googleapis.com/auth/admob.report
https://www.googleapis.com/auth/admob.googlebidding.readwrite
https://www.googleapis.com/auth/admob.monetization
AdSense for Platforms API https://www.googleapis.com/auth/adsensehost
https://www.googleapis.com/auth/adsense
https://www.googleapis.com/auth/adsense.readonly
Google Analytics API https://www.googleapis.com/auth/analytics
https://www.googleapis.com/auth/analytics.readonly
https://www.googleapis.com/auth/analytics.edit
https://www.googleapis.com/auth/analytics.manage.users
https://www.googleapis.com/auth/analytics.manage.users.readonly
https://www.googleapis.com/auth/analytics.provision
https://www.googleapis.com/auth/analytics.user.deletion
Campaign Manager 360 API https://www.googleapis.com/auth/ddmconversions
https://www.googleapis.com/auth/dfareporting
https://www.googleapis.com/auth/dfatrafficking
Search Ads 360 API https://www.googleapis.com/auth/doubleclicksearch
Google Tag Manager API https://www.googleapis.com/auth/tagmanager.delete.containers
https://www.googleapis.com/auth/tagmanager.edit.containers
https://www.googleapis.com/auth/tagmanager.edit.containerversions
https://www.googleapis.com/auth/tagmanager.manage.accounts
https://www.googleapis.com/auth/tagmanager.manage.users
https://www.googleapis.com/auth/tagmanager.publish
https://www.googleapis.com/auth/tagmanager.readonly
Real time bidding API https://www.googleapis.com/auth/realtime-bidding
Authorized Buyers Marketplace API https://www.googleapis.com/auth/authorized-buyers-marketplace
https://www.googleapis.com/auth/adexchange.buyer

How to get help
If you have any questions or need help, reach out to your respective API’s support team with your questions.

In the coming months, we will make changes to the Display & Video 360 API and Structured Data Files to improve API function and better align with the Display & Video 360 product.
In the coming months, we will make changes to the Display & Video 360 API and Structured Data Files to improve API function and better align with the Display & Video 360 product.

These changes may impact your existing integrations. We have announced these changes on our Announced Deprecations page. We recommend you review these individual changes that will take effect on the following dates: If you believe any of these changes will impact your integrations, follow the recommended actions in the change description.

If you run into any issues or have questions about these changes, please contact us using our new Display & Video 360 API Technical support contact form.

We’re pleased to announce that Display & Video 360 API v4 is available in public beta starting today. We’ve also launched an update to the v3, adding new features.

Here is a subset of changes introduced in v4:

We’re pleased to announce that Display & Video 360 API v4 is available in public beta starting today. We’ve also launched an update to the v3, adding new features.

Here is a subset of changes introduced in v4:

In addition, we've released an update that adds the following features in both v3 and v4:

More detailed information about this release can be found in our release notes. Follow the steps in our migration guide to migrate from v3 to v4. Be aware that breaking changes may be made to v4 while in beta, and any such changes will be listed in the Display & Video 360 API release notes.

Before using new v3 features, make sure to update your client library to the latest version.

If you run into issues or need help with these new features or samples, please contact us using our support contact form.

Starting on April 7, 2025, a new maximum membership duration of 540 days will gradually roll out for Customer Match lists in Google Ads and Display & Video 360 platforms. This change is being made to better align with Customer Match best practices.

Starting on April 7, 2025, a new maximum membership duration of 540 days will gradually roll out for Customer Match lists in Google Ads and Display & Video 360 platforms. This change is being made to better align with Customer Match best practices.

From this date, existing lists configured to have no membership expiration set or membership expiration greater than 540 days will be updated to use the maximum membership duration of 540 days, and a membership duration of 540 days will be retroactively applied to all those existing members that have a longer duration. The reflected list size decreases as memberships expire. Campaigns targeting too small a segment of users can’t serve ads and may automatically pause. Refresh your Customer Match list before April 7, 2025 to renew memberships or replace the expired Customer Match lists with up-to-date lists to ensure that your ad campaigns are not interrupted.

With a set membership duration, you will need to start refreshing your list regularly by re-uploading customer data to your lists. If you do not, the list size will get smaller over time. Refer to this article to learn more about Customer Match.

Required actions for Google Ads API users

Starting on April 7, 2025, requests to set the UserList.membership_life_span field in the Google Ads API to greater than 540 will return a RangeError.TOO_HIGH error. We recommend you check your current implementation to make sure you no longer set the field value to greater than 540.

For existing user lists with membership_life_span field in the Google Ads API greater than 540, starting from April 7, 2025 customer data user lists will be automatically migrated to have a membership life span of the maximum 540 days. If you need to update your code to regularly refresh your customer lists, check out our guide for examples.

No action is required if you do not set the membership_life_span field in the Google Ads API and you regularly refresh your customer lists. Leaving the field unset has the same effect as setting it to the maximum 540 days value.

If you run into issues or have questions about these changes, please contact us using our Google Ads API forum.

Required actions for Display & Video 360 API users

Starting on April 7, 2025, firstAndThirdPartyAudiences.create and firstAndThirdPartyAudiences.patch requests to the Display & Video 360 API that set the membershipDurationDays field to greater than 540 will return a 400 error. Setting the membershipDurationDays field is required when you create a Customer Match list, so we recommend that you check your current implementation to make sure you no longer set the field to a value greater than 540.

From April 7, 2025, existing Customer Match list with a membershipDurationDays field set to a value greater than 540 days will be automatically migrated to a membership duration of the new maximum 540 days. After this date, you will need to regularly refresh your Customer Match list. See our guide for examples on how to update your Customer Match list.

If you run into issues or have questions about these changes, please contact us using our Display & Video 360 API Technical support contact form.


Version 12.0.0 of the Google Mobile Ads SDK is now available. We recommend upgrading as soon as possible to get our latest features and performance improvements.

Updated Swift APIs

We’ve updated the Google Mobile Ads SDK to define an NS_SWIFT_NAME for every API to follow the naming conventions from Apple’s Swift API Design Guidelines. For example, we have:

Version 12.0.0 of the Google Mobile Ads SDK is now available. We recommend upgrading as soon as possible to get our latest features and performance improvements.

Updated Swift APIs

We’ve updated the Google Mobile Ads SDK to define an NS_SWIFT_NAME for every API to follow the naming conventions from Apple’s Swift API Design Guidelines. For example, we have:

  • Removed the GAD prefix across names for all types.
  • Renamed the GAM prefix to AdManager.
  • Renamed the GADM prefix to Mediation.

For the full list of Swift API name changes, see Swift naming support.

Swift 6 Concurrency

Swift 6 concurrency support is being rolled out incrementally, starting this release with added support for our ad format delegate methods. Future SDK versions will include further improvements.

Changes to Xcode requirements

The minimum supported Xcode version has been bumped to 16.0.

For the full list of changes, check the release notes. Check our migration guide to ensure your mobile apps are ready to upgrade.

SDK Deprecation Reminder

Per the deprecation schedule, the release of version 12.0.0 means that:

  • iOS Google Mobile Ads SDK versions 10.x.x are officially deprecated, and will sunset in Q2 2026.
  • Versions 9.x.x and below will sunset on June 30, 2025.
    • While there are currently no plans to disable ad serving on version 9.x.x, we strongly recommend updating to a supported SDK version to avoid being impacted in the future.

As always, if you have any questions or need additional help, contact us via the developer forum.

We are pleased to announce the launch of the Google Ads API Research Group. As a Developer Relations team, we want to ensure your voice is not only heard, but that your suggestions are incorporated into product decisions. Our goal is to turn your feedback into real improvements to the Google Ads API developer experience.

We are pleased to announce the launch of the Google Ads API Research Group. As a Developer Relations team, we want to ensure your voice is not only heard, but that your suggestions are incorporated into product decisions. Our goal is to turn your feedback into real improvements to the Google Ads API developer experience.

As a member of the research group, we'll invite you to participate in user research opportunities, such as surveys and usability studies. These opportunities let you voice your opinions and ideas about the Google Ads API, inform product design and prioritization, and ultimately shape the Google Ads API developer experience.

To sign up for the Google Ads API Research Group, fill out the opt-in form. This form takes about 5 minutes to complete. We are deeply committed to improving developer experience and appreciate your feedback.

Starting on March 3, 2025, the Google Ads API and Google Ads scripts search term insight reports will return all search subcategories as empty. The Google Ads UI already removed this field, and the API is also rolling out this change to be consistent across Google Ads.

Starting on March 3, 2025, the Google Ads API and Google Ads scripts search term insight reports will return all search subcategories as empty. The Google Ads UI already removed this field, and the API is also rolling out this change to be consistent across Google Ads.

What do I need to do?

Starting March 3, 2025, it is expected that all values for segments.search_subcategory will be empty.

If you query segments.search_subcategory in the campaign_search_term_insight or customer_search_term_insight reports, then:

  1. Check that your code can handle an empty value in segments.search_subcategory. An empty string already is a catch-all, so your code should be already handling this.
  2. We recommend removing segments.search_subcategory from your query.

If you have any questions or concerns, you can reach out to us through our support form.

The IMA DAI SDK now supports passing the network code parameter when creating a full-service stream request. This change is specifically for IMA DAI integrations using either LiveStreamRequest or VODStreamRequest classes. Adding the network code is a one-time change that enables IMA DAI to respect your Ad Manager settings.

The IMA DAI SDK now supports passing the network code parameter when creating a full-service stream request. This change is specifically for IMA DAI integrations using either LiveStreamRequest or VODStreamRequest classes. Adding the network code is a one-time change that enables IMA DAI to respect your Ad Manager settings.

We recommend you provide the network code for IMA to apply your Ad Manager settings to the stream request. For example, if you turn off programmatic limited ads in Ad Manager, use the Google Ad Manager network code parameter to ensure local storage is also disabled for limited ads in DAI on your app.

The following example constructs an IMA DAI HTML5 LiveStreamRequest class with the network code in the request to Ad Manager:

function requestLiveStream(assetKey, apiKey, networkCode) {
  var streamRequest = new google.ima.dai.api.LiveStreamRequest();
  streamRequest.assetKey = assetKey;
  streamRequest.apiKey = apiKey;
  streamRequest.networkCode = networkCode;
  streamManager.requestStream(streamRequest);
}

You can pass the network code using the IMA DAI SDK for full-service DAI on all of the platforms:

For more information, see the programmatic limited ads Ad Manager article. Additionally, follow Find your Ad Manager network code. If you have any questions, feel free to reach out using the IMA technical forum.