Tag Archives: google_ads

Performance Max: create listing groups using batch processing

What’s New

Starting on October 4, 2023, AssetGroupListingGroupFilters can be created asynchronously using batch processing with the Google Ads API. If you use BatchJobService to create AssetGroupListingGroupFilter entities and other Performance Max resources in a single request, errors in the listing group tree creation will not block the creation of the remaining entities. However, the operations to create a listing group tree will still be atomic. This means that if any operation related to the creation of a listing group tree returns an error, all operations related to that listing group tree will also fail, save a few caveats, which are detailed in this Jobs & listing group filters guide.

This update does not change the behavior of any existing batch jobs that do not include operations that create listing group filters.

Previous Behavior

Prior to October 4, 2023, AssetGroupListingGroupFilters could only be created synchronously using the GoogleAdsService.Mutate or AssetGroupListingGroupFilterService.MutateAssetGroupListingGroupFilters method. Requests using the GoogleAdsService.Mutate method are always atomic when they contain AssetGroupListingGroupFilterOperation operations. This is because partial_failure is not supported for these operations, which means that an error in listing group tree creation would block all other operations in the request. If you tried creating AssetGroupListingGroupFilter entities prior to October 4, 2023 using batch processing, you would receive a MutateError.OPERATION_DOES_NOT_SUPPORT_PARTIAL_FAILURE error.

Change Rationale

Batch processing is a powerful feature in the Google Ads API that allows you to dispatch a set of operations, which may be interdependent, to multiple services without synchronously waiting for the operations to complete. We have made batch processing available for AssetGroupListingGroupFilters in response to your feedback to provide another option for creating listing group trees asynchronously and without blocking other operations in the same request.

Implementation Details

In order to add an AssetGroupListingGroupFilter using a batch job:

  1. Create a MutateOperation containing an AssetGroupListingGroupFilterOperation. This is no different than creating a MutateOperation using the GoogleAdsService.Mutate service.
  2. Add the MutateOperation to the batch job as you would with any other type of operation.

The example below demonstrates the process of adding a single AssetGroupListingGroupFilter to an existing batch job. See the Creating Shopping Listing Groups guide to learn more about creating product partition trees using AssetGroupListingGroupFilter entities.

// Constructs the AssetGroupListingGroupFilter.
AssetGroupListingGroupFilter listingGroupFilter =
     AssetGroupListingGroupFilter.newBuilder()
         .setAssetGroup(assetGroupResourceName)
         .setType(ListingGroupFilterType.UNIT_INCLUDED)
         .setVertical(ListingGroupFilterVertical.SHOPPING)
         .build();

// Constructs the operation to create the AssetGroupListingGroupFilter.
MutateOperation operation = MutateOperation.newBuilder()
     .setAssetGroupListingGroupFilterOperation(
           AssetGroupListingGroupFilterOperation
      .newBuilder()
      .setCreate(listingGroupFilter))
      .build();

// Sends a request to add the operation to the batch job.
AddBatchJobOperationsResponse response =
    batchJobServiceClient.addBatchJobOperations(
        AddBatchJobOperationsRequest.newBuilder()
            .setResourceName(batchJobResourceName)
            .addMutateOperations(operation)
            .build());

The following resources contain additional information to help you with your integration:

Improving Performance Max integrations Blog Series

This article is part of a series that discusses new and upcoming features that you have been asking for. We’ll cover what’s new and how it differs from the current implementation approach.

Keep an eye out for further updates and improvements on our developer blog, continue providing feedback on Performance Max integrations with the Google Ads API, and as always, contact our team if you need support.

Effectively use the Attribution Reporting API for ad measurement

Overview

Historically, ad-tech providers have used third-party cookies (3PC) as a mechanism for conversion measurement, and for attributing conversions to ad interactions. Conversion measurement provides critical ad performance data to advertisers, and helps optimize auction-based bidding strategies.

Currently, the online advertising ecosystem is pivoting towards improved ways to protect user privacy. Chrome’s Attribution Reporting API (ARA), a part of the larger Privacy Sandbox initiative, offers an alternative for measurement after the third-party cookie deprecation in 2024. Ad-tech providers, including Google’s ads platforms, should consider adopting the ARA to maintain high-quality conversion measurement and support the pivot toward user privacy protection.

Google Ads has made significant investments to use the ARA more effectively and to help advertisers achieve more accurate measurement. We encourage other ad-tech providers to integrate with the ARA, configure the integration to retrieve the data they need, and process the ARA's output to help maintain accurate measurement after the planned third-party cookie deprecation in 2024.

Goals of the ARA

The ARA has two goals:

  • Protect users’ cross-site and cross-app identities from ad-tech providers, advertisers, publishers and other entities by using differential privacy techniques, such as aggregation, or adding an element of noise to the data.
  • Provide useful measurement information to ad-tech providers, advertisers, and publishers.

The ARA represents a change to both the format and granularity of conversion data available to ad-tech providers. As a result, ad-tech providers must change their current measurement protocols in order to start leveraging the ARA.

A glimpse into our approach

Ad-tech providers who participate in the Privacy Sandbox initiative receive data from the ARA in two forms: event-level reports and aggregate summary reports. This way, two independent views of the same underlying data are available. We encourage ad-tech providers to configure the reporting settings in the API to optimize for better measurement accuracy without 3PC, as well as improve how these two types of reports can be post-processed and used together.

There are many possible ways to utilize the ARA reports. The methodology that works for an ad-tech provider will ultimately depend on its conversion data and measurement requirements. Google Ads has found that leveraging both report types can help the industry benefit from the strengths of each report.

Google Ads leverages both event types to produce a more complete, ad event-level log. We are committed to sharing our process and engaging with the ecosystem to help our partners and the broader industry transition into a future without third-party cookies.

For more details on how we’re implementing the Attribution Reporting API, please refer to our detailed technical guide.

Deprecating Python 3.7 Support in the Google Ads Client Library for Python

On June 27, 2023, Python 3.7 will reach end-of-life and will no longer be supported by the Python Software Foundation. Once Python 3.7 officially reaches end-of-life status, it will also no longer be supported by the Google Ads client library for Python.

While this will not change the functionality of the client library, any issues or bugs related to the library's compatibility with Python 3.7 will not be addressed, and any documentation related to Python 3.7 will be removed.

We recommend library users upgrade their systems to Python 3.8 or higher as soon as possible.

If you have any questions about this change, please file an issue on the client library repository.

Prepare to test Privacy Sandbox APIs with Google’s ads platforms

Last week, Chrome announced the upcoming general availability of Privacy Sandbox APIs for the ads ecosystem. We welcome this opportunity to test these APIs in Google’s ads platforms, and we invite ad technology partners to get involved and be ready for Chrome’s third-party cookie deprecation in 2024.

We’ve seen encouraging results from our recent interest-based advertising experiments, and we plan to integrate Topics, Protected Audience and Attribution Reporting APIs into our ads products. We’ll use Privacy Sandbox APIs alongside other privacy-preserving innovations to help deliver relevant ads and accurate measurement insights without the need to track people across the web.

We encourage advertisers and publishers to continue to adopt the full range of Google’s privacy-first ads solutions, and encourage their ad technology platform partners to adopt and test Privacy Sandbox APIs.

Through the rest of 2023, we will work with our ad technology partners to test the Privacy Sandbox APIs alongside first-party data and AI-powered solutions, and prepare for Q1 2024 when Chrome plans to deprecate third-party cookies for one percent of its users. The Q1 2024 tests will help us to evaluate the effectiveness of these solutions, and share our findings with Chrome, the UK’s Competition and Markets Authority, and the industry.

We encourage technology partners to review the below guidance to prepare for testing with Google’s Ads solutions:
  • If you’re a Google Authorized Buyer or participant in Open Bidding, see integration guidance for Topics and Protected Audience.
  • If you’re a publisher platform working with Google Ads or Google Marketing Platform (Display & Video 360 or Campaign Manager 360), see integration guidance for Topics, Protected Audience and Multiple seller testing.
  • If you’re a measurement provider working with Google Marketing Platform (Display & Video 360 or Campaign Manager 360), see integration guidance for the Protected Audience API.
  • If you’re a publisher or ad tech provider working with Google Marketing Platform (Display & Video 360, Campaign Manager 360 or Search Ads 360), see integration guidance for the Attribution Reporting API.
We’re excited to continue building privacy-first innovations that help partners drive performance, earn revenue and get accurate measurement insights without third-party cookies.

New Validations for Google Ads Account Names

Starting in June 2023, it will no longer be possible for new Google Ads accounts to contain a URL in the account name.

Specifically, when creating a new Google Ads account in the Google Ads API, or updating an existing account, if a URL is present in the descriptive_name field, an ACTION_NOT_PERMITTED error will be returned and the operation will fail.

The descriptive_name field of existing accounts will not be affected by this change.

If you have any questions about this change, please feel free to contact us through the forum or at [email protected] for additional help.

First click, linear, time decay, and position-based attribution models are going away in Google Ads API

What’s changing?
Google Ads attribution models are used to assign conversion credit to each touchpoint in a conversion path. We currently offer several rules-based attribution models which assign value based on predefined rules. These models don’t provide the flexibility needed to adapt to evolving consumer journeys. Due to a declining usage of these rules-based models and adoption of data-driven attribution, we are simplifying attribution model options. Starting in June 2023, developers will no longer be able to choose the following attribution models for new conversion actions or existing conversion actions that do not use these models: Instead, developers will need to use either data-driven attribution (GOOGLE_SEARCH_ATTRIBUTION_DATA_DRIVEN), last click attribution (GOOGLE_ADS_LAST_CLICK) or external attribution.

What do I need to do?
If you are creating new or updating existing conversion actions using ConversionActionService and you are setting the AttributionModelSettings to one of the deprecated attribution models, you will need to modify your code to use either: data-driven attribution (GOOGLE_SEARCH_ATTRIBUTION_DATA_DRIVEN) or last click attribution (GOOGLE_ADS_LAST_CLICK).

Starting in June 2023, you will begin receiving an error if you attempt to set a deprecated attribution model. Conversion actions that still have these attribution models after this time will be automatically migrated later in the year.

Starting in September 2023, we'll switch any conversion actions still using these models to data-driven attribution. If you don’t want your conversion actions to use data-driven attribution, update your conversion actions to the last click attribution model before September 2023.

You will be able to query the attribution model associated with a conversion action using GoogleAdsService.Search or GoogleAdsService.SearchStream until these rules-based attribution models are no longer available in Google Ads:
SELECT conversion_action.attribution_model_settings.attribution_model FROM conversion_action
If you have any questions, please reach out to us on the forum.

Changes to handling duplicate assets in Google Ads API

What’s changing?
Starting the week of March 28, 2022, the Google Ads API will no longer throw an AssetError.CANNOT_MODIFY_ASSET_NAME in versions v7, v8 and v9 when uploading an asset with duplicate content but a different Asset.name. Instead, the Google Ads API will ignore the new name and return the resource name of the existing asset.

This change affects the following asset types. Background
When creating a new asset using AssetService.MutateAssets, the Google Ads API detects if the uploaded asset has the same content as an existing asset but a different name and raises an AssetError.CANNOT_MODIFY_ASSET_NAME in versions v7, v8 and v9. We observed that it was not easy for users to troubleshoot this error, so starting with version v10, the Google Ads API ignores the new name and returns the resource name of the existing asset if an asset with duplicate content is detected. To keep the API experience consistent, we are making the same changes to versions v7, v8 and v9 of Google Ads API.

What should you do?
Once this change goes live, the AssetError.CANNOT_MODIFY_ASSET_NAME error won’t be thrown when uploading an asset with duplicate content and a different name. If your application handles this error, please review and make changes to match the new API behavior.

If you have any questions or need additional help, contact us using any of the following support options:

Changes in Network Settings for the Google Ads Standard Shopping Campaigns

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 [email protected] for additional help.

Making Google Ads API Client Libraries More Inclusive

As part of Google’s effort to foster inclusivity in our products and communities, we will be changing the name of the default branch to main in the Google Ads API client libraries. This change is a small but important step towards making diversity, equity, and inclusion central to our work on the Google Ads API.

This change won’t affect most client library users who access the libraries through a distribution platform like PyPi for Python or Maven for Java. Users who access the libraries directly from the default branch on GitHub should start using the new main branch once it’s available. We encourage contributors who own forks of these client libraries to update them accordingly.

If you have any questions about this change, please file an issue on the issues tracker for your client library of choice (like Python). As always, please feel free to contact us through the forum or at [email protected] for additional help.

Entity IDs as 64-bit in AdWords API, Google Ads API beta, Google Ads scripts, and Content API for Shopping

In the AdWords API, the Google Ads API beta, Google Ads scripts, and the Content API for Shopping, all entity IDs are 64-bit signed integers. They are of type:
  • xsd:long in the AdWords API
  • INT64 in the Google Ads API
  • number or string in Google Ads scripts
  • string in REST and as INT64 for client libraries in Content API for Shopping
Applications that integrate with the API should handle ID values in that range.

Historically, the following IDs were within the maximum value of 32-bit signed integer, but will soon be exceeding this range. Over the years, all of you have been so productive that we need to make sure 64-bit signed integers are available to allow the creation of more entities with unique IDs. This was announced starting in July 2019. To avoid any issues, please make sure your applications handle these IDs within a range of 64-bit signed integer values. Also make sure that your application is ready to support a 64-bit signed integer for any other entity IDs not listed below.

Which IDs are affected in the AdWords API and the Google Ads API beta?
AdWords API Google Ads API beta
Bidding Strategy BiddingStrategyConfiguration.bidding_strategy_id

BiddingStrategyId (multiple reports)
BiddingStrategy.id
Budget BudgetOrder.id AccountBudget.id

BillingSetup.id
User List UserList.id

CriterionUserList.userListId

CLICK_PERFORMANCE_REPORT.UserListId

AUDIENCE_PERFORMANCE_REPORT.Id
UserList.id
Shopping Campaigns ServiceLink.serviceLinkId

ShoppingSetting.merchantId

SHOPPING_PERFORMANCE_REPORT.MerchantId

SHOPPING_PERFORMANCE_REPORT.AggregatorId
MerchantCenterLink.id

ShoppingSetting.merchant_id

segments.product_merchant_id

segments.product_aggregator_id
Conversion Action ConversionTracker.id

ConversionTrackerId (multiple reports)

ConversionTracker.originalConversionTypeId
ConversionAction.id
Account Conversion Tracking Configuration ConversionTrackingSettings.effectiveConversionTrackingId ConversionTrackingSetting.conversion_tracking_id

ConversionTrackingSetting. cross_account_conversion_tracking_id




Which IDs are affected in Google Ads scripts?
JavaScript can only accurately represent integers up to 53 bits, so it's strongly advised that you begin treating all IDs in Google Ads scripts as string to avoid any possible future errors with high ID numbers.
Google Ads scripts
Bidding Strategy AdsApp.BiddingStrategy.getId()
Budget AdsApp.BillingAccount.getId()

AdsApp.BudgetOrder.getId()
User List AdsApp.Audience.getId()

AdsApp.ExcludedAudience.getId()

AdsApp.UserList.getId()

AdsApp.​ShoppingCampaignAudience.getAudienceId()

AdsApp.ShoppingCampaignAudienceBuilder.withAudienceId()

AdsApp.ShoppingCampaignAudienceSelector.withIds()

getAudienceId() and withAudienceId() for all Targeting -> Audience Search methods.



Which IDs are affected in the Content API for Shopping?
All IDs are returned as string in REST and as INT64 in the client libraries. If you convert IDs to a number in your application, please make sure the application can handle 64-bit signed integers. An example of this is merchant ID that is set in the client library’s configuration or in the REST URL.
Content API for Shopping
Merchant Center AccountIdentifier.merchantId

Order.merchantId

OrdersCustomBatchRequestEntry.merchantId

RegionalinventoryCustomBatchRequestEntry.merchantId

ProductsCustomBatchRequestEntry.merchantId

ProductstatusesCustomBatchRequestEntry.merchantId

AccountsCustomBatchRequestEntry.merchantId

OrderReportDisbursement.merchantId

OrderReportTransaction.merchantId

LocalinventoryCustomBatchRequestEntry.merchantId

ReturnpolicyCustomBatchRequestEntry.merchantId
Shopping Campaign AccountIdentifier.aggregatorId



Where can I get support?
If you have any API questions or need help, you can reach us at: