[go: nahoru, domu]

The Content API for Shopping now automatically increases your products and accounts quotas as your account grows.

Because your API quota now changes dynamically, we have removed the static chart from our published limits guide. To check your current daily quota and usage, and current per minute quota, you can call the quotas.list service.

The following errors are not API quota errors and can’t be resolved by automatic quota increases. They require you to request a quota increase.

  • too_many_items: Merchant quota exceeded
  • too_many_subaccounts: Maximum number of subaccounts reached

Automatic quota only applies to the products and accounts services. If you need an increased API quota for any other service, or if you’re hitting your daily API quota for the products or accounts services or need a temporary increase for the accounts or products services, contact us with the following information:

  • Your Merchant Center ID
  • Which methods you’ve reached your quota limits on
  • An estimation of how many calls per day you need for those methods
  • The reason why you need an increased quota

Note that our general quota policy is you should not update your products more than twice per day, and that you should check your accounts and account statuses not more than once per day.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

What happened?

For developers linking Merchant Center accounts to Google Ads using Google Ads API v14, there was an issue from 04:00 PST Monday, Feb 19 to 08:00 PST Tuesday, Feb 20 that caused some requests to the MutateMerchantCenterLink method of MerchantCenterLinkService to return MutateError.RESOURCE_NOT_FOUND. Also calls to ListMerchantCenterLinks may not have returned some MerchantCenterLinks with link status PENDING.

What should I do?

If you use Google Ads API v14 to link Merchant Center accounts to Google Ads accounts using MerchantCenterLinkService, you should check to see if you have accounts that have pending link requests during the period of time described above. This issue has now been resolved and you may retry the failed calls to complete the linking of Merchant Center accounts. Also check ListMerchantCenterLinks for accounts with link status PENDING. Some of these link requests may not have previously been returned during that time period.

How to get help

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

The Content API for Shopping easy onboarding authentication method and tab, which create a service account for you, will not be available in Merchant Center Next. Easy onboarding is still available in Merchant Center Classic.

You can still use existing service accounts that you created using Merchant Center Classic. To set up a service account without using easy onboarding in Merchant Center Classic, follow these steps:

  1. Ensure you have an existing cloud project or create a new one in the Google Cloud Console.
  2. Generate or access your service account credentials.
  3. Download the JSON private key from Google API Console. This JSON private key can be used in the same way as the one downloaded from Merchant Center previously.
  4. Add the new service account as a user to your Merchant Center account. If you’re a third-party developer (and don’t have access to the Merchant Center UI for the account), your client will need to complete this step for you.

For more details, see the API documentation.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

Buy on Google for Search and Shopping will no longer be available starting September 26, 2023. All Merchant and Consumer support will end for Buy on Google on Search on November 25, 2023. The only exception is that the orders.get and orders.list methods will remain available for Search and Shopping until October 30, 2024, so that merchants can download their historical order data.

See below for the specific timeline of when Buy on Google methods will no longer be available for the Search and Shopping program.

June 28, 2023 onwards:

September 30, 2023:

October 31, 2023:

All the orders related resources (orders, orderinvoices, orderreports, orderreturns, ordertrackingsignals) and all their underlying methods. The only exception is that the orders.get and orders.list methods will remain available for Search and Shopping until October 30, 2024, so that merchants can download their historical order data.

If you are currently using the Buy on Google endpoints for Search and Shopping via the Content API, you will need to stop using these services for Search and Shopping before the dates listed above, as your requests will start to fail after that date.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

The Content API for Shopping will undergo planned maintenance on September 28, 2023, from 15:00 to 17:00 UTC.

During this time, you will not be able to make any changes to your account such as updates to users, business information, feeds, shipping details, or linking your Google Ads accounts.

You can still upload products to your existing feeds or data sources and run ads as usual.

Note that the Google Ads API is also affected by this outage, as you will not be able to link MC accounts and Google Ads accounts together via the Google Ads API during this time period.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

On August 23rd, 2023, we introduced new features in the Content API for Shopping to help you display detailed information about product and account issues to your merchants, and enable those merchants to request re-review or perform other actions. The new MerchantSupport service provides more transparency about our policy-related requirements to your merchants. These methods should be used for merchants based in the EEA, but can be used globally.

Here are the 2 new methods (developer guide):
  • Render account issues: provides UI elements with text in the language you select to display account issues to your merchants and redirect link to Merchant Center for merchants to request a re-review or perform other actions
  • Render product issues: provides UI elements with text in the language you select to display product issues to your merchants and redirect link to Merchant Center for merchants to request a re-review or perform other actions
All issue texts returned from MerchantSupport methods above are localized. Clients can request texts in any Merchant Center supported language. Please note that merchants need to have access to their Merchant Center account in order to perform the actions.

If you are based in EEA, we highly recommend implementing MerchantSupport methods by the end of the year, so that your merchants will have more information regarding our policy-related requirements, and have access to our new features. In the future we will expand the MerchantSupport service to let you request re-review or perform other actions directly with the Content API for Shopping. With this future addition, your merchants will not have to be redirected to Merchant Center, they will be able to request the action directly in your UI.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

What’s Changing

Starting the week of September 4, 2023, MerchantLinkService.MutateMerchantCenterLink method will fail with an AuthorizationError.ACTION_NOT_PERMITTED error for authorized users without Admin access levels.

Required Actions

If your application mutates Merchant Center links using the MutateMerchantCenterLink method, review the account permissions of the users authorizing API calls and update their permissions appropriately to ensure they have the required access levels. Refer to the help center guide for instructions.

Change Rationale

This change will align the Google Ads API behavior with other products such as the Google Ads UI and Google Ads Editor, which only allow Administrator users to mutate Merchant Center links. Currently, the Google Ads API allows users with Standard Access levels but without Admin access level permissions to mutate Merchant Center links using the MerchantLinkService.

If you have any questions, please reach out to us on the forum.

In the Content API for Shopping, we informed you last June that new Merchant IDs were migrating from 32 bit to 64-bit signed integers.

Existing Merchant IDs haven’t changed. Beginning on March 13, 2023 new Merchant IDs created could be in the 64-bit signed range. Through a slow rollout over the next few months, a higher percentage of new Merchant IDs will be in the 64-bit signed range. By June 2023, all new Merchant IDs created will be in the 64-bit signed range.

To avoid any issues, please make sure your applications are fully compliant with IDs within a range of 64-bit signed integer values.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

Starting on April 24, 2023, the Content API for Shopping methods productstatuses.list and productstatuses.get will include issues from all eligible destinations by default. This will likely increase the size of the response you get back from the same call.

Currently, the responses you get when using the productstatuses.list and productstatuses.get methods only include issues from Shopping Ads and don’t include issues from other destinations, for example free listings issues.

Including issues from all eligible destinations will let you provide your users with an overall better experience. This change will improve your issue visibility across all destinations. In turn, you will see an increase in the number of results, or the size of responses you’ll receive.

No action is needed from you as the free listing issues will now be included by default when using the Content API for Shopping methods productstatuses.list and productstatuses.get.

However, if you want to keep the calls to only display issues from Shopping Ads, we suggest setting the query parameter destinations[] in the productstatuses methods to Shopping.

Learn more about the changes to the product statuses methods in the Content API for Shopping Product statuses documentation.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

Starting on April 14, 2023, there will be changes made to the location targeting settings for Search, Shopping, Display, and Performance Max campaigns in the Google Ads API. We are making this change to simplify the location targeting portfolio and improve advertiser performance. All versions will throw errors if you try to set the location target settings to one of the values shown below.

Campaign.geo_target_type_setting fields
positive_geo_target_type can no longer be set to SEARCH_INTEREST for Search, Shopping, and Display campaigns. The default value is PRESENCE_OR_INTEREST.
negative_geo_target_type can no longer be set to PRESENCE_OR_INTEREST for Performance Max, Search, Shopping, and Display campaigns. The default value is PRESENCE.
The error returned if these values are used is SettingError.SETTING_VALUE_NOT_COMPATIBLE_WITH_CAMPAIGN.

On April 24, 2023, we will start performing any necessary auto-migration of fields to the new default values until no more invalid combinations exist. The auto-migration will occur on a per-campaign basis. You can confirm that the migration is complete for a Google Ads account by checking that these two queries return zero rows.

SELECT campaign.id, campaign.geo_target_type_setting.positive_geo_target_type, campaign.advertising_channel_type FROM campaign WHERE campaign.advertising_channel_type IN ('DISPLAY', 'SEARCH', 'SHOPPING') AND campaign.geo_target_type_setting.positive_geo_target_type = 'SEARCH_INTEREST' LIMIT 1
SELECT campaign.id, campaign.advertising_channel_type, campaign.geo_target_type_setting.negative_geo_target_type FROM campaign WHERE campaign.geo_target_type_setting.negative_geo_target_type = 'PRESENCE_OR_INTEREST' AND campaign.advertising_channel_type IN ('DISPLAY', 'PERFORMANCE_MAX', 'SEARCH', 'SHOPPING') LIMIT 1
Where can I get support?
If you have questions, please reach out to us on the forum or at googleadsapi-support@google.com.

In the Content API for Shopping, your Merchant Center account and the products in it might be disapproved for various reasons. Historically, you have been able to see the status of your merchant center account for free listings and Shopping ads with the accountstatuses service. In Q1 2022 we introduced the freelistingsprogram and shoppingadsprogram services to provide more granular detail. You can now use the requestreview method on the freelistingsprogram and shoppingadsprogram services to request your account to be re-reviewed after making changes to fix your product and account data.

For an in-depth explanation of how to use the freelistingsprogram and shoppingadsprogram services, please refer to the Free listings and Shopping ads guides.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

On September 22, 2022, we updated you on changes to country targeting for shopping products, and how to use the feedLabel field. We’ve made additional changes to help you integrate feedLabel. Here are our previous announcements: What’s new
Merchant Center & Content API
As of November 8th, 2022 we’ve added the ability to manage feedLabel for datafeeds. The feedLabel field is now available in the following resources:
  • products
  • datafeeds
  • DatafeedStatus
You can now see which countries a datafeed explicitly targets in datafeedtarget. This applies when you use feedLabel instead of country in the datafeedtarget configuration.

We’ve also added the targetCountries field for datafeeds, so you can configure targeting for datafeeds directly. You can still configure targeting outside the feed, for example, by setting the shipping attribute of the products resource.

Note: You can’t manage Primary and Supplemental API feeds with the datafeeds service. You need to use the Merchant Center UI.

Behavior changes
Here’s a clarification of new API behavior for feedLabel:

Insert and update
You can now call Products.insert and Products.update with a feedLabel set to any valid string, for example “WINTERPRODUCTS”.

You can now use feedLabel without setting targetCountry during insertion and updates. Errors that used to warn of this requirement have been removed.

If you use both feedLabel and targetCountry in these calls, their values must be the same.

See Use feed labels to advertise products from specific feeds for the definition of a valid string for feedLabel.

Targeting
If you don’t use targetCountry for products, you must either set the shipping attribute of the products resource, or use the targetCountries field for the datafeeds resource to ensure your products target the chosen countries.

Opt out of receiving products and datafeeds without a country
If you’re concerned your codebase cannot handle products and datafeeds without a country, and you want to opt out of receiving them via the Content API for Shopping, fill out the following form: Feed label replaces target country in the Content API for Shopping - temporary exemption.

When you’re ready to support feedLabel, you can opt back in to receiving these offers.

If you have any questions about this change, please visit the Content API for Shopping forum.

On August 10, 2022, we announced a change to country targeting for shopping products with the introduction of the feedLabel field. We’d like to update you on the progress of this change. Here are our previous announcements: What’s already changed

Google Ads:
Any Google Ads account can set the feed_label field in ShoppingSetting for Shopping and Performance Max campaigns. You can set feed_label in the Google Ads UI and the Google Ads API.

Merchant Center & Content API:
As of September 14th, 2022 we‘ve started the gradual rollout of feed labels in the Merchant Center UI. When this feature is enabled in the UI, merchants will be able to create a new feed with feed label set to any valid string. See Use feed labels to advertise products from specific feeds for more information.

In the Content API, you might see the following:
  • Products that have only feedLabel, and not targetCountry, if they were added in the Merchant Center UI.
  • Products with feed labels that aren’t two-letter country codes.
You can now use Products.update to update products by feedLabel. For example, if you had a product with offerId of “111111111” and a feedLabel set to “WINTERPRODUCTS”, you can now update attributes such as salePrice for that product by making the following call:
HTTP request:
PATCH https://shoppingcontent.googleapis.com/content/v2.1/{merchantId}/products/online:en:WINTERPRODUCTS:1111111111
Example request body:
{
  "salePrice": {
    "value": "17.99",
    "currency": "USD"
  }
}
Behavior summary:
Here’s a clarification of the current API behavior for feedLabel:
  • Insertion: You can only call Products.insert on products with a matching feedLabel and targetCountry. Currently, Products.insert might return an error if you don’t provide a matching targetCountry. This behavior hasn’t changed if you continue to use only targetCountry.
  • Targeting: If you set feedLabel to a valid 2-letter CLDR territory code, you must still set the shipping attribute of the products resource to the same country in order to target that country. For example, if you set a new feedLabel to “US”, you must also set the country field in the shipping attribute to “US”. If you don’t set both fields, the product might not be eligible to serve in that country. You can configure targeting for an entire feed in the Merchant Center UI.
  • Get/List: When you use Products.list or Products.get, you might see products that only have feedLabel (and not targetCountry) set if they were added in the Merchant Center UI.
  • Product IDs: Once a feedLabel is set for a product it becomes part of the product Id. This means you can’t modify the feedLabel for that product (this is similar to how language works). If you wish to change the feedLabel you will need to create a new product with a different product Id.
What’s coming next

Products:
Once the gradual rollout of feed labels in the Merchant Center UI is complete, we will accept Products.insert calls with feedLabel set to any string. At this point, including targetCountry will become optional.

Datafeeds:
In late September, we will also update the datafeeds resource to include feedLabel in the Content API for Shopping.

Opt out of receiving products and datafeeds without a country
If you’re concerned your codebase cannot handle products and datafeeds without a country, and you want to opt out of receiving them via the Content API for Shopping, fill out the following form: Feed label replaces target country in the Content API for Shopping - temporary exemption. When you’re ready to support feedLabel, you can opt back in to receiving these offers.
If you have any questions about this change, please visit the Content API for Shopping forum.

We’re starting a phased rollout of a change to country targeting in Google Ads and Merchant Center. The rollout has already begun and will continue into September.

See Feed label replaces target country in Content API for Shopping for how this change impacts the Content API for Shopping.

When the change reaches you, you’ll be able to set the feed_label field in ShoppingSetting for Shopping & Performance Max campaigns in the UI and API. Due to this change, you may begin seeing campaigns with feed_labels set in the UI and API for certain merchants. Campaigns with feed_label not set to a 2-letter CLDR territory code can serve ads in any country as long as the campaign has the appropriate geoTargeting and the appropriate target countries are set in Merchant Center.

This change doesn’t impact the countries targeted by existing shopping feeds. You don’t need to update existing shopping feeds or campaigns.

What’s changing in Merchant Center
Today, Google Merchant Center feeds require you to select a primary country of sale target (sales_country in Google Ads API), with the option to provide additional target countries once the feed has been created. Starting in August 23, 2022, we will make the following changes to how target countries are organized in the Merchant Center UI:
  • The primary country of sale option will be removed in Google Merchant Center. Country of sale will be replaced by the more generic feed_label that can accept any string, including any existing 2 letter CDLR country code.
  • The current additional countries field will be renamed target countries, and will include all countries you want the feed to target.
What’s changing in Google Ads UI and API
The current sales_country field for all available Shopping campaign types, including Performance Max, will eventually be replaced by feed_label. Note that we will keep the sales_country field for backwards compatibility until at least Q2 2023. Right now, you can continue to use sales_country in your campaigns.

You can create a feed_label in Google Merchant Center or the Content API. Feed labels let you group different offers according to a common trait, like language (or a country, as you’ve currently been doing). You can also use feed_labels in Google Ads campaigns to target the relevant offers (all products with the same Merchant Center feed label).

The ads for the offers that match the feed_label will show based on the following:
  1. The countries you selected as target countries in Merchant Center.
  2. Your campaign’s geo targeting. Note: The default campaign targeting behavior (if you do not geo target) is that your products will serve in all your Merchant Center target countries.
How you’re impacted
The phased rollout to enable this feature in Google Ads UI and API has already started, and is expected to be complete by the end of September 2022. For existing feeds, feed_label will automatically be set to the two-letter territory code of the existing sales_country field to avoid interrupting existing targeting.

However, if you want to support new users or new feeds that only have a feed_label and not a sales_country field, we recommend you update your code by August 23, 2022 to accommodate customers who will use campaigns that only have a feed_label (without a sales_country).

If you have any questions or concerns, please don't hesitate to contact us via the forum.

On August 23, 2022 we will gradually start updating the way country targeting works for shopping products. As a result, the targetCountry field for newly inserted products and the country field for new datafeeds may be empty in the Content API for Shopping. While targetCountry and country are now deprecated, there are no plans to remove these fields from v2.1 to preserve backward compatibility. We recommend using feedLabel to name new products and feeds, and using the shipping field to specify the countries to target.

If you're accessing accounts whose product data you don’t have total control over and you are unsure whether the products or datafeeds will have ONLY a feedLabel field beginning in late August, we recommend you update your code to support the feedLabel field.

This upcoming change might impact or break your API integration if your application cannot handle products without a targetCountry or datafeeds without a country.

See Country targeting in Shopping Ads campaigns is changing in August 2022 for how this change will impact Google Ads.

What’s already changed
On August 8, 2022, the Content API for Shopping added the feedLabel field to the products resource. As of August 8, 2022, feedLabel can only accept and return two-letter CLDR territory codes. Products now require either targetCountry or feedLabel. As long as the feedLabel set is a valid two-letter CLDR code, targetCountry will be backfilled for compatibility.

We have changed the definition of the product identifier (the id, i.e. the REST ID). feedLabel now replaces targetCountry as the third component of the identifier, so it is no longer just a valid two-letter CLDR code. You can find an example shown here.

This change to product identifier is backwards compatible, so existing REST IDs for existing products will continue to work without change.

Important: feedLabel doesn’t impact targeting. This means if you use feedLabel instead of targetCountry, you need to specify all countries you want to target in the shipping attribute.

What’s coming next
We’re starting a gradual rollout to all users on August 23, 2022. When the upcoming change reaches you, you’ll be able to create a product or datafeed with any string (not just a two-letter CLDR code) as the feedLabel via the API or the Merchant Center. You’ll still be able to use a two-letter country code in targetCountry for backwards compatibility.

After the upcoming change, if you submit a feedLabel that isn’t a CLDR territory code, the API will return those products without a targetCountry or those datafeeds without a country. Instead, only their feedLabel will be populated. This may break your codebase if your implementation expects a value in targetCountry for products or a value in country for datafeeds.

How you’re impacted
Products
If you continue inserting your products with a targetCountry, you are not required to make any changes at this time, as the feedLabel value in the products REST ID will be identical to the targetCountry you inserted.

However, if you use a feedLabel in Merchant Center or the API that is not a CLDR territory code, we highly recommend you update your codebase to use feedLabels on all product insertions instead of targetCountry to avoid issues with your API integration.

All products inserted with a feedLabel instead of targetCountry, even if the feedLabel is a CLDR territory code, will not automatically target that country. You must explicitly set the countries you want to target via the shipping field.

Datafeeds
Note that starting August 23, 2022, feed label will replace the current country of sale value in the Merchant Center UI. The Content API will be expected to support this change via the datafeeds service starting mid-September. These new datafeeds will only have the feedLabel field set, not the country field, unless you explicitly set the feedLabel to a CLDR territory code.

To support new users, we highly recommend you update your codebase to use feedLabels on all datafeeds instead of country to avoid issues with your API integration.

Recommendation for third party integrations
If you’re a third party or agency that manages your customers' accounts for them, we highly recommend you check your codebase is able handle products without a targetCountry and datafeeds without a country before August 23, 2022.

After the gradual rollout starting in late August, your merchants will be able to modify products directly in Merchant Center to create a product with a feedLabel that is not a valid two-letter CLDR territory code. When this product is returned via products.list, you could encounter issues if your implementation expects a value in targetCountry.

As well, after the gradual rollout in late August, new users will create datafeeds that by default have a feedLabel and no country field. When this datafeed is returned via datafeeds.list, you could encounter issues if your implementation expects a value in country.

How to detect if you have offers without a country in your Merchant Center account
  1. Make a request to products.list.
  2. Filter your products to search for products where the targetCountry field does not exist on the product.
  3. If any products appear, you have offers without a country in your Merchant Center.
Detailed Changes
To view a detailed breakdown of the changes to the Content API by this feature launch, see the guide here.

Datafeeds Service
Starting mid-September the datafeeds service will begin to return feedLabel on all datafeeds, which will be the country value if that is how the datafeed was created. The datafeeds service will also return the country field if the feedLabel is a valid country code for backwards compatibility.

Opt out of receiving products and datafeeds without a country
If you’re concerned your codebase cannot handle products and datafeeds without a country, and you want to opt out of receiving them via the Content API after August 23, then please fill out the following form: Feed label replaces target country in the Content API for Shopping - temporary exemption. Once you have fully supported feedLabel, you will be able to opt back in to receiving these offers.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

As we announced in January and again in March, existing and future Smart Shopping campaigns (SSC) will automatically upgrade to Performance Max campaigns between July and September 2022. The self-upgrade started in April 2022. The automatic upgrade has commenced (related blog post) and should complete by September 30, 2022. This blog post adds details for our API developers.

Starting July 25, 2022, accounts without active or paused SSCs (including new accounts) will no longer be able to create SSCs.

Once an account with active or paused SSCs has been automatically upgraded from SSC to Performance Max, no new SSC creation will be permitted in any surface including the UI, the API, Google Ads Scripts or Google Ads Editor.

The Google Ads API v11 included a new UpgradeSmartShoppingCampaignToPerformanceMaxRecommendation recommendation type to allow developers to upgrade a given SSC to a Performance Max campaign. This can still be applied to an account that has not yet automatically upgraded.

As mentioned in the January blog post, Local campaigns will also be automatically upgraded to Performance Max. An upcoming release of the Google Ads API will include a new recommendation type to allow developers to upgrade an eligible Local campaign to a Performance Max campaign.

Additional information

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

In the Content API for Shopping, Merchant IDs are now 64-bit signed integers. Applications that integrate with the Content API must be able to handle ID values in that range.

Historically, Merchant IDs in the Content API for Shopping were within the maximum value of a 32-bit signed integer, but have recently exceeded this range. In order to avoid any issues, please make sure your applications are fully compliant with IDs within a range of 64-bit signed integer values.

If you have any questions or concerns, please don't hesitate to contact us via the forum.

Beginning May 31, 2022 we will enforce the following limits for custom batch methods in the Content API for Shopping:
  • Maximum entries per request: 10,000
  • Maximum transfer size per request: 32Mb (The payload received from the client)
We’re introducing these limits to enable the fair and stable use of Content API for Shopping. The limits will apply to the following endpoints: After May 31, 2022, calls to any of these endpoints that exceed these limits will begin to fail with the following error:
  • request_too_large
Visit our batching guide to learn more about methods for reducing your batch size. If you are looking for a reasonable batch size to implement, we recommend 1,000 entries per request for each endpoint. Following this means you are unlikely to encounter the limits even if your batch size temporarily increases.

If you have any questions about implementing this change, please visit the Content API for Shopping forum.

As we announced in January, existing and future Smart Shopping campaigns (SSC) will automatically upgrade to Performance Max campaigns between July and September 2022.

As mentioned in the prior blog post, users will be able to self-upgrade in the UI starting April 2022. Developers will be able to self-upgrade in the API before the end of June. We expect the vast majority of accounts managed by the API will opt to wait to self-upgrade once the tool is available in the API in June. However, campaigns may be upgraded manually by advertisers in the UI starting in April. We recommend you implement Performance Max in your application now to ensure support for any new or upgraded Performance Max campaigns.

An upgraded SSC will be marked as REMOVED status (metrics will continue to be available in the legacy campaign for historical purposes). There will also be a mapping from the previous campaign ID to the new Performance Max campaign ID. Budgets, assets, and settings of the existing SSC are preserved.

The prior blog post had April / May 2022 as the estimated availability date for the API's new self-upgrade recommendation type. This will be available before the end of June. There will still be a six week period between availability of the new recommendation type in the API and the start of auto-upgrades.

Note that once a campaign has been upgraded, either by the UI or API, there is no means to revert the upgrade. Metrics will continue to be available in the legacy campaign for historical purposes.

Additional information

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

On February 14, 2022, Google Ads stopped serving standard Shopping campaigns on the Google Display Network, including on Gmail, Discover, and some YouTube placements. As a result, the AdWords API, Google Ads API and Google Ads scripts will make similar changes to their behavior starting the week of February 28, 2022.

AdWords API
The AdWords API will sunset on April 27th, so you must migrate to the Google Ads API by then.

In the AdWords API, the Campaign.NetworkSetting.targetContentNetwork field will always return false for standard Shopping campaigns, which are defined as campaigns where the advertisingChannelType is set to SHOPPING, and the advertisingChannelSubType is unset. If you try to set Campaign.NetworkSetting.targetContentNetwork to true, it will be ignored.

When running reports, the API will stop returning metrics for AdNetworkType1 and AdNetworkType2 of type: CONTENT, YOUTUBE_SEARCH, or YOUTUBE_WATCH for standard Shopping campaigns for date ranges after February 14, 2022. You can still download historic metrics for these fields and values.

Google Ads API
Versions v8 and v9 of the Google Ads API will behave the same way as the AdWords API – the network_settings.target_content_network field will return false, and if you try to set this field to true, it will be ignored. In version v10 and beyond, if you try to set this field to true a CANNOT_TARGET_CONTENT_NETWORK error will be returned.

When running reports, the API will stop returning metrics for these campaigns for segments.ad_network_type of type: CONTENT, YOUTUBE_SEARCH, or YOUTUBE_WATCH for date ranges after February 14, 2022. You can still download historic metrics for this field and values.

Google Ads scripts
If you use bulk uploads to target a standard Shopping campaign for Google Display Network, the server will ignore the setting.

When generating reports, the behavior will be the same for standard Shopping campaigns, independent of the method that you use:
  • With the AdsApp.report() method, reports will stop returning metrics for AdNetworkType1 and AdNetworkType2 of type: CONTENT, YOUTUBE_SEARCH, or YOUTUBE_WATCH for date ranges after Feb 14, 2022.
  • With the AdsApp.search() method, the API will stop returning metrics for segments.ad_network_type of type: CONTENT, YOUTUBE_SEARCH, or YOUTUBE_WATCH for date ranges after Feb 14, 2022.
Historical metrics will still be available.

If you would like to retrieve any existing standard Shopping campaigns before their network settings are changed, be sure to do so before Feb. 28, 2022.

If you have any questions about this change, please feel free to contact us through the forum or at googleadsapi-support@google.com for additional help.