[go: up one dir, main page]

Google Ads is deprecating the call-only ad format. Google Ads API users currently creating or managing call-only ads will need to transition to using Responsive Search Ads (RSAs) with call assets. This change will help advertisers achieve better campaign performance and leverage the latest ad innovations.

What’s Changing?

The call-only ad type, based on the legacy Expanded Text Ad (ETA) framework, is being phased out. Moving forward, phone call lead generation will be fully supported through Responsive Search Ads (RSAs) combined with call assets. RSAs offer greater flexibility and performance by utilizing machine learning to optimize ad creatives.

Why This Change?

  • Improved Performance: Advertisers generally see better results and lower costs per call lead with RSAs and call assets compared to the static nature of call-only ads.
  • Modern Infrastructure: RSAs benefit from ongoing improvements in AI and machine learning. The underlying ETA framework for call-only ads is deprecated.
  • Consistency: This move aligns call-based advertising with the standard for all other Search ad formats, simplifying campaign management.

Impact on Google Ads API Users

If your application uses the Google Ads API to create or manage call-only ads, you will be affected.

  • New Call-Only Ad Creation: Starting January 2026, coinciding with the v23 API release, you will no longer be able to create new call-only ads or duplicate existing ones through the API. The call-only ad type will be removed from the latest API version.
  • Existing Call-Only Ads: Your existing call-only ads will continue to serve and be manageable via the API until February 2027.
  • API Support Sunset: Support for call-only ads will be progressively removed from all active API versions, with full cessation by February 2027.

Key Dates for API Users:

  • January 2026:
    • Creation of new call-only ads (including duplication) is blocked in all Google Ads API versions and all other interfaces (Google Ads UI, Google Ads Editor, SA360).
  • Until February 2027:
    • Existing call-only ads continue to serve.
    • API users can still update existing call-only ads. We strongly recommend using this time to migrate.
  • As of February 2027:
    • All call-only ads will stop serving.
    • Full support for call-only ads is removed from all active Google Ads API versions.

What You Need to Do:

  1. Update API Integrations: Modify your API client libraries and applications to stop creating call-only ad types.
  2. Migrate to RSAs with Call Assets: Transition your ad creation and management workflows to use Responsive Search Ads. Ensure you attach call assets to these RSAs to continue driving phone call leads.
    • To create an RSA, you'll provide multiple headlines and descriptions.
    • Phone numbers are added as assets linked at the customer, campaign, or ad group level.

Benefits of Migrating Early:

  • Take advantage of the better performance of RSAs.
  • Ensure a smooth transition without service interruption.
  • Maintain full control over your ad copy and settings.

We recommend updating your API integrations and migrating your call-only ad strategies well before the deadlines. Please refer to the Google Ads API developer documentation for the latest guidance on working with Responsive Search Ads and call assets.

If you have any questions or want to discuss this post, please reach out to us on our “Google Advertising and Measurement Community” Discord server.

On June 30, 2025 we announced that we would roll out a change that would cause our bidding models to start using the presence of the ClickConversion.conversion_environment field in imported in-app conversions for campaign performance.

That change, which may have caused performance degradation in certain campaigns where this is not set, will no longer be implemented. However we still recommend that users who import conversions using the Google Ads API set the conversion_environment field in order to gain the following benefits:

  • Accurate cross-environment attribution: Understand the full value of your campaigns across website and app sources.
  • Ad destination reporting: Gain insights into where the user lands after clicking your ad, and the relative performance of each segment.
  • Streamlined Google support: Receive faster and more effective troubleshooting.

For more details see this Help Center article.

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

We're thrilled to announce the open source release of the Google Ads API Model Context Protocol (MCP) Server, available here. This project marks a significant step in democratizing access to Google Ads data for the next generation of AI tools and agent developers.

The Model Context Protocol (MCP) is the open standard that allows Large Language Models (LLMs), like Google Gemini, to connect with and act upon external data sources and applications. By releasing an MCP Server specifically for the Google Ads API, we are making it possible for any MCP-compatible AI application to understand and analyze advertising campaigns through natural language.

This initial release is read-only, meaning it can be used for reporting and diagnostics but will not make changes to your account.

Please use the GitHub repo for technical issues with the MCP server.

For technical support issues with the API, reach out to the Google Ads API support channel.

If you have other questions or want to discuss this post, please reach out to us on our “Google Advertising and Measurement Community” Discord server.

When we released V21 of the Google Ads API, we released a field with the wrong name in the BudgetPerDayMinimumErrorDetails message: the field minimum_budget_amount_micros was mistakenly released as minimum_bugdet_amount_micros, with the word “budget” misspelled.

We already corrected the error in V22 of the API; however, we are also retroactively correcting it in V21 starting from October 15th, 2025 (the same day of the V22 release).

What do I need to do?

If you are using one of our officially supported client libraries, they will keep working seamlessly when we release the field rename.

However, when you upgrade to the latest version of your client library, you will have to modify your existing code that accesses this field to comply with the field rename, even if you are still using V21.

If you are using the Google Ads API with the REST transport layer, make sure your code is handling the minimum_budget_amount_micros field by its correct name instead of the mistakenly released one.

If you have any questions or want to discuss this post, please reach out to us on our “Google Advertising and Measurement Community” Discord server.

Today, we’re announcing you can start adding Google Mobile Ads mediation adapters to your iOS projects using Swift Package Manager (SPM).

Swift Package Manager is Apple's first-party tool for managing project dependencies. By supporting SPM, we're making it easier for you to integrate and manage our mediation adapters, helping you streamline your development workflow and reduce setup complexity.

Which adapters are supported?

We're planning to roll out SPM support for all open source and versioned adapters. Each adapter will be in its own dedicated GitHub repository.

Adapters currently available:

Ad source Minimum version supported in SPM
AppLovin 13.3.1.0
DT Exchange 8.3.8.0
IronSource 8.10.0.0
Liftoff Monetize 7.5.3.0
i-mobile 2.3.4.2
inMobi 10.8.6.0
Meta 6.20.1.0
Mintegral 7.7.9.0
Pangle 7.4.1.1.0
Unity 4.16.0.0

Add a Swift Package to your project

To add a package dependency to your Xcode project, navigate to File > Add Package Dependencies… and search for the package using each adapter's corresponding GitHub URL:

Adapters coming soon

We're continuing to roll out Swift Package Manager support for more mediation adapters. Check the list of currently supported adapters by visiting our GitHub page.

If you have any questions or want to discuss this post, please reach out to us on our “Google Advertising and Measurement Community” Discord server.

Starting on November 17 2025, we are changing the account-default behavior of automatically created customer conversion goals.

Current behavior

Currently, when you create a new conversion action using the Google Ads API, customer conversion goals are created automatically, as needed. These newly created goals are automatically set as account-default, meaning this goal will automatically be biddable in any campaign that is optimizing to account-default goals. While convenient, this sometimes leads to bidding mechanisms targeting unnecessary goals, potentially resulting in suboptimal campaign performance. This change aims to optimize bidding performance by reducing the number of unnecessary goals included in the account-default set for a given account.

What’s changing?

With this change, a new automatically created goal will only be set as account-default if all other goals within the same category are also account-default goals. For example, if an account has an existing, non-account-default customer conversion goal associated with a conversion action with the category PURCHASE and a conversion origin of WEBSITE, then any new conversion actions with the category PURCHASE will result in goals that are also not account-default.

This approach helps us better infer user intent, and it ensures that the account-default set remains lean and effective.

Technical recommendation

After this change is introduced, newly created account goals will not be considered account-default automatically. If you want to set an account goal to account-default manually, set the CustomerConversionGoal.biddable field to true.

This update will enhance the efficiency and effectiveness of goal management within Google Ads. We encourage you to review your applications and client workflows in light of this upcoming change.

For any questions or concerns, feel free to refer to our support page. You can also discuss this post in our “Google Advertising and Measurement Community” Discord server.

Today in the Google Ads UI, you will see updated enhanced conversions for leads diagnostics that feature a number of improvements that offer better visibility into the state of your conversion import implementation. The goal of these changes is to help you identify common problems and address them quickly.

Here are some of the changes you’ll see:

  1. New "Importing limited user-provided data" Alert: A new, high-priority alert has been introduced to detect a common implementation error, where users fail to import incremental conversions that contain user-provided data (UPD) but not a GCLID. We recommend that you import all of your conversion data that has user-provided data, regardless of whether or not it has a GCLID. Doing so helps to find cross-device or Youtube EVC conversion touchpoints, driving performance uplift. You may not see these benefits if you omit UPD-only conversions.
  2. Improved Status for "Tagless" Implementations: A new "Good" status has been added to validate setups where advertisers import conversions with both a GCLID and user-provided data, but do not have the Google tag implemented on their website. Previously, this valid configuration could trigger confusing "Urgent" alerts. If you have not implemented the Google tag on your website, it’s important to include GCLIDs in your conversion imports whenever possible in order to get performance benefits.
  3. Reprioritized Alert Logic: Alert priorities have been updated to be more intelligent. For users sending GCLIDs with their offline data, import-related issues will be prioritized as more critical, while tag-related issues will be downgraded in severity.
  4. Complete Alert Visibility: The diagnostics interface has been updated to show all alerts at once, regardless of their severity tier. This allows developers to see a complete picture of all required and recommended actions upfront, rather than fixing one issue only to uncover another.
  5. Deprecation of CLICK_NOT_FOUND: The informational CLICK_NOT_FOUND error has been removed from the Diagnostics UI and API, and, correspondingly, the debug_mode parameter in the UploadClickConversions method that triggers it in API responses has also been removed. See this related blog post for reference.

Reach out to the Google Ads API support channel if you have any questions or need support. If you want to discuss this change with us, join our “Google Advertising and Measurement Community” Discord server.