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:

• Country targeting update for products in Content API for Shopping and Google Ads API.
• Feed label replaces target country in Content API for Shopping.
• Country targeting in Shopping Ads campaigns is changing in August 2022.

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.
Ian Ballantyne, Content API for Shopping Team

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.
- Trevor Mulchay, Display & Video 360 API Team

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!

 - Justin Malandruccolo, Mobile Ads Developer Relations

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.
- David Stevens, Google Ads API Product Manager

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.
Bob Hancock, Google Ads API Team

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.
- Mark Saniscalchi, Authorized Buyers Developer Relations

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:

• Creating or updating logical user lists using UserListService.MutateUserLists or audiences using AudienceService.MutateAudiences.
• Setting targeting at campaign-level using CampaignCriterionService.MutateCampaignCriteria or at ad group-level using AdGroupCriterionService.MutateAdGroupCriteria.
• Setting conversion value rules using ConversionValueRuleService.MutateConversionValueRules.

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:

• Accessing or updating similar or logical user lists using AdsApp.UserList.
• Accessing targeting using AdsApp.Targeting, AdsApp.CampaignTargeting, or AdsApp.AccountAdGroupTargeting.
• Reporting from the Google Ads API reports user_list, audience, combined_audience, and any others that are based on targeting, or conversion values segments or metrics.

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 googleadsapi-support@google.com.
Pierrick Voulet, Google Ads API Team

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.
- Chris Seeley, Ad Manager API Team

On November 7, 2022, optimized targeting will gradually begin replacing targeting expansion for display, video, and audio line items under a Display & Video 360 partner, with the new feature launched for all partners by November 9, 2022. We will be making changes to the Display & Video 360 API to reflect this. These changes may impact the existing configurations of your resources, and the behavior for your currently successful requests.

Read the optimized targeting and targeting expansion guides to understand the differences between optimized targeting and targeting expansion. Optimized targeting is not available for over-the-top line items, or line items that use fixed bidding.

There will be no structural changes to the existing targetingExpansion field or TargetingExpansionConfig object in Display & Video 360 API LineItem resources. Once optimized targeting replaces targeting expansion for your partner, these fields will be used to manage optimized targeting in the following manner:

• The targetingExpansionLevel field will only support two possible values:
  • NO_EXPANSION: optimized targeting is off
  • LEAST_EXPANSION: optimized targeting is on
• NO_EXPANSION will be the default value for the targetingExpansionLevel field and will be automatically assigned if you do not set the field
• If you set targetingExpansionLevel to one of the following values, it will automatically be reset to LEAST_EXPANSION:
  • SOME_EXPANSION
  • BALANCED_EXPANSION
  • MORE_EXPANSION
  • MOST_EXPANSION
• excludeFirstPartyAudience will continue to set whether first-party audiences should be excluded from targeting. This will now apply to optimized targeting instead of targeting expansion.
• If you turn on optimized targeting for an ineligible line item, the request will not return an error and the change will persist. However, you must update the line item to be eligible before it will use optimized targeting when serving.
• Optimized targeting will not automatically be turned on for eligible line items created or updated by the Display & Video 360 API.

We will also be updating the configurations of existing line items as follows:

• The targetingExpansionLevel and excludeFirstPartyAudience fields for existing line items will be set to NO_EXPANSION and false, respectively, if one of the following applies:
  • It is an over-the-top line item
  • The line item uses fixed bidding
  • targetingExpansionLevel is already set to NO_EXPANSION
  • targetingExpansionLevel is unset
• For all other line items, the targetingExpansionLevel field will be set to LEAST_EXPANSION and excludeFirstPartyAudience will remain unchanged.

To prepare for this change, it is recommended that you turn on automated bidding for line items currently using fixed bidding with targeting expansion before November 7, 2022 to continue using audience expansion to improve campaign performance.

If you have questions regarding these changes or need help with these new features, please contact us using our support contact form.
- Trevor Mulchay, Display & Video 360 API Team