Category Archives: Ads Developer Blog

The official blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs

Display & Video 360 API v2 entering general availability

Today we’re announcing the launch of Display & Video 360 API v2 out of public beta, and into general availability, and updates to both v1 and v2. As Display & Video 360 API v2 enters general availability, it becomes our recommended version. Our existing guides have been updated to reflect v2 features and conventions.

The following features have been added to v2:

The following updates have been made to both v1 and v2:

  • Removed the character limit for the description field in InsertionOrderBudgetSegment objects.
  • Increased the max page size of a subset of list requests from 100 to 200. The default page size for these methods is still 100.

In addition to these updates, we’ve also fixed two known issues in v2 regarding enum targeting and the line item bulkUpdate method. More detailed information about this update can be found in the Display & Video 360 API release notes, and updated instructions on migrating from v1 to v2 can be found in our migration guide. Before using these new features, make sure to update your client library to the latest version.

If you have questions regarding the breaking changes or run into issues or need help with these new features, please contact us using our support contact form.

Feed label support added to datafeeds service in Content API for Shopping

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.

Feed label support added to datafeeds service in Content API for Shopping

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.

Optimized targeting launch in Display & Video 360 postponed

The launch of optimized targeting and deprecation of targeting expansion for display, video, and audio line items in Display & Video 360 have been postponed. Optimized targeting was previously announced to gradually launch for all Display & Video 360 partners from November 7 to November 9, 2022.

The changes in Display & Video 360 API behavior that were previously announced have also been postponed. The targetingExpansion field in the LineItem resource will continue to represent the targeting expansion feature.

We will announce a new date for these changes at a later date.

SwiftUI Case Study: Presenting from View Controllers

We are happy to announce the release of an iOS sample application that demonstrates how to integrate the Google Mobile Ads SDK into a SwiftUI-based app. This post covers how we implemented full screen ad formats (interstitial, rewarded, rewarded interstitial) in SwiftUI.

The Google Mobile Ads SDK relies heavily on the UIKit Framework, depending on UIView or UIViewController for each ad format. For example, the SDK currently presents full screen ads using the following method:

present(fromRootViewController rootViewController: UIViewController)

In UIKit, ads are typically implemented in a UIViewController, so it is rather trivial to pass in a rootViewController value by simply invoking self. SwiftUI requires us to diverge from this approach, however, because UIViewController cannot be directly referenced in SwiftUI. Since we can’t just pass in self as the root view controller, we needed to achieve a similar result using a SwiftUI-native approach.

Our solution

We created an implementation of the UIViewControllerRepresentable protocol with a UIViewController property. Its one job is to provide access to the UIViewController reference in SwiftUI.

private struct AdViewControllerRepresentable: UIViewControllerRepresentable {
let viewController = UIViewController()

func makeUIViewController(context: Context) -> some UIViewController {
return viewController
}

func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {}
}

AdViewControllerRepresentable needs to be included as part of the view hierarchy even though it holds no significance to the content on screen. This is because canPresent(fromRootViewController:) requires the presenting view controller’s window value to not be nil.

private let adViewControllerRepresentable = AdViewControllerRepresentable()

var body: some View {
Text("hello, friend.")
.font(.largeTitle)
// Add the adViewControllerRepresentable to the background so it
// does not influence the placement of other views in the view hierarchy.
.background {
adViewControllerRepresentable
.frame(width: .zero, height: .zero)
}
}

To present the full screen ads in our sample app, we leveraged action events in SwiftUI.

Button("Watch an ad!") {
coordinator.presentAd(from: adViewControllerRepresentable.viewController)
}

And our AdCoordinator class does the honor of presenting it from our view controller.

private class AdCoordinator: NSObject {
private var ad: GADInterstitialAd?

...

func presentAd(from viewController: UIViewController) {
guard let ad = ad else {
return print("Ad wasn't ready")
}

ad.present(fromRootViewController: viewController)
}
}

And voila!

An alternative option

Instead of creating a UIViewControllerRepresentable, there was always the option to query the rootViewController property from UIWindow.

UIApplication.shared.windows.first?.rootViewController

We decided against this option for the following reasons:

  1. There is the inherent nullability risk to querying an optional array index.
  2. The default value of rootViewController is nil.
  3. If your app utilizes more than one window, the windows array will have multiple elements and therefore, makes querying the “first” window object unreliable.
  4. windows on the UIApplication object is deprecated in iOS 15 and UIWindowScene now holds the reference to this property.

Conclusion

We know there is more than one way to cook an egg when it comes to writing code in SwiftUI. For our use case, we chose the most low-code friendly option. If you have any questions, reach out to our developer forum.

Try it out!

Recommendations in Google Ads API Roundup

Google Ads API now supports 25 different recommendation types including the most frequently used types. With the wide array of types available and documentation with examples to help you get started, there has never been a better time to get started retrieving and applying recommendations with Google Ads API!

Key suggested uses
Recommendations provide customized suggestions to help increase your campaigns' performance. Recommendations can introduce you to new, relevant features, help you get more out of your budget by improving your bidding, keywords, and ads, and can increase the overall performance and efficiency of your campaigns. Here are a few examples of how recommendations can help with the management of your account:
  • Avoid getting limited by budget this holiday season. With CAMPAIGN_BUDGET and FORECASTING_CAMPAIGN_BUDGET recommendation types you’ll be sure to keep your ads running, so potential customers can see them by preventing your campaign from under-performing due to a limited budget.
  • Expand the reach of your ads with USE_BROAD_MATCH_KEYWORD, which will update your keyword match types to show your ads to relevant potential customers.
  • Upgrade to Performance Max with UPGRADE_SMART_SHOPPING_CAMPAIGN_TO_PERFORMANCE_MAX and UPGRADE_LOCAL_CAMPAIGN_TO_PERFORMANCE_MAX, which will take care of migrating your existing Smart Shopping and Local Campaigns for you.
Implementation guide
To help you get started, check out our implementation guide and YouTube deep dive tutorial for tips.

Code examples
We’ve also put together these code examples to save you time getting up to speed with Recommendations in Google Ads API.

RSA Combination Report Policy Update for Google Ads

What is changing?
Beginning on January 15, 2023, advertisers will no longer be able to retrieve the Ad Group Ad Combination Report (ad_group_ad_asset_combination_view) for Responsive Search Ads for the entire time period that their ad was serving. Instead, the Ad Group Ad Combination Report will return data for a 12 month period ending with the current month on a rolling basis. At any given time, only the data for the twelve month window will be available, and any older combination data will be deleted.

Why is this changing?
To optimize the Ad Group Ad Combination Report for upcoming features.

What do I need to do?
If you want to retain combination data from January 2022 or before, we recommend that you download it before January 15, 2023.

After January 15, 2023, we recommend downloading the combinations report on an ongoing basis if you'd like to retain historical combinations.

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

Removing support for old OpenRTB versions

Starting today, Google’s OpenRTB implementation will be updated to only include fields and messages for the latest supported version, OpenRTB 2.5. This will affect the OpenRTB protocol and any APIs or tools used to configure bidder endpoints.

OpenRTB protocol changes
As a result of supporting only the latest version, the following fields are deprecated and will no longer be populated:
  • BidRequest.imp[].banner.hmax
  • BidRequest.imp[].banner.hmin
  • BidRequest.imp[].banner.wmax
  • BidRequest.imp[].banner.wmin
Additionally, the following fields may now be populated for all bidders:
  • BidRequest.device.ext.user_agent_data
  • BidRequest.device.geo.accuracy
  • BidRequest.device.geo.utcoffset
  • BidRequest.imp[].banner.api: This will support the value MRAID_3.
  • BidRequest.imp[].banner.format
  • BidRequest.imp[].banner.vcm
  • BidRequest.imp[].metric
  • BidRequest.imp[].native.api: This will support the value MRAID_3.
  • BidRequest.imp[].video.api: This will support the value MRAID_3.
  • BidRequest.imp[].video.companionad.api
  • BidRequest.imp[].video.companionad.format
  • BidRequest.imp[].video.companionad.vcm
  • BidRequest.imp[].video.linearity
  • BidRequest.imp[].video.maxduration
  • BidRequest.imp[].video.placement
  • BidRequest.imp[].video.playbackend
  • BidRequest.imp[].video.skip
  • BidRequest.site.mobile
  • BidRequest.test
  • BidRequest.wlang
If a newer OpenRTB specification is published, Google may upgrade the current supported version to match it. Previously deprecated fields that are removed from the specification will also be removed from the protocol. Non-deprecated fields that are removed will be marked as deprecated in the protocol, and eventually removed following a brief deprecation period.

Authorized Buyers Real-time Bidding API changes
The behavior of the bidders.endpoints resource will change. The following enum values for bidProtocol will be deprecated:
  • OPENRTB_2_2
  • OPENRTB_2_3
  • OPENRTB_PROTOBUF_2_3
  • OPENRTB_2_4
  • OPENRTB_PROTOBUF_2_4
  • OPENRTB_2_5
  • OPENRTB_PROTOBUF_2_5
New enum values for bidProtocol will be added to represent the latest supported OpenRTB version in either JSON or Protobuf formats:
  • OPENRTB_JSON
  • OPENRTB_PROTOBUF
If you have existing endpoints with their bidProtocol set to any of the deprecated values above, they will automatically be migrated to either OPENRTB_JSON or OPENRTB_PROTOBUF depending on the format specified by the original value. Additionally, any modifications to your endpoints that would set bidProtocol to the deprecated values will instead set it to OPENRTB_JSON or OPENRTB_PROTOBUF.

Feel free to reach out to us via the Authorized Buyers API support forum with any feedback or questions you may have related to these changes.

Announcing deprecation and sunset of Similar Audiences

On November 1, 2022, we announced our plans to sunset Similar Audiences in 2023 as we work on simplifying our existing product portfolio and strengthening our future-proof solutions in a changing privacy landscape. We expect to roll out this change in two phases for both Google Ads API and Google Ads scripts:
  1. Starting May 2023: New similar audiences segments will stop being generated, and existing similar audiences segments will no longer be added to campaigns and ad groups. Ad groups and campaigns that already have similar audience segments attached will continue to function as expected.
  2. Starting August 2023: Similar audience segments will be removed from all ad groups and campaigns. You will continue to have access to historical reporting data for similar audience segments from past campaigns.
What is the impact on Google Ads API?
Any requests that mutate entities related to Similar Audiences will start failing with errors. This includes: The data retrieved using GoogleAdsService.Search or GoogleAdsService.SearchStream requests will gradually be depleted of any references to Similar Audiences. This includes queries relying on the reports user_list, audience, combined_audience, and any others that are based on targeting, or conversion values segments or metrics. When we get closer to the sunset date, check out the deprecation and sunset guide for the exact errors that will be thrown.

What is the impact on Google Ads scripts?
Any requests that relate to Similar Audiences are impacted. Mutating requests will start failing with errors and reporting requests will start returning data depleted of any references to Similar Audiences. This includes: What should I do?
We recommend that API users manually migrate and stop using Similar Audiences before May 2023 in their calls to avoid any disruptions. You can refer to the announcement and Help Center article to learn more about migration options.

If you have any questions or need additional help, contact us through the forum or at [email protected].

Announcing v202211 of the Google Ad Manager API

We're pleased to announce that v202211 of the Google Ad Manager API is available starting today, November 2nd. This release lays the groundwork for multiple third-party impression tracking URLs. ImageCreative and other creative types replaced the string field thirdPartyImpressionTrackingUrl with the list field thirdPartyImpressionTrackingUrls. Currently only a single URL can be provided in the list.

For the full list of changes, check the release notes. Feel free to reach out to us on the Ad Manager API forum with any API-related questions.