Category Archives: Ads Developer Blog

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

SIMID support in the Interactive Media Ads SDK

The Secure Interactive Media Interface Definition (SIMID) is a new ad format for interactive video ads. It was designed to be the successor of the Video Player Ad-Serving Interface Definition (VPAID) according to the Interactive Advertising Bureau. SIMID addresses many of the issues with VPAID, including slow loading times, security limitations, and being difficult to debug with only a single error code (901).

SIMID support is available in the HTML5, Android, and iOS IMA SDKs for client-side ads starting with the following releases:

Improvements in the SIMID API Model over VPAID

Unlike VPAID, the code for SIMID ad creatives runs in a secure sandbox so that it cannot access other resources on the page. With SIMID, the player maintains control while the creative sends messages to the player about which actions are needed to perform its functions. This is demonstrated in the diagram below:

As a result, SIMID offers the following advantages over VPAID:

  • Improved security by sandboxing the ad from the publishers page
  • Improved asset transparency by including the media file in the VAST response
  • Support for pre-caching
  • Faster load times
  • Improved error reporting from more granular error codes

Using SIMID with the IMA SDK

SIMID creatives are ready to be used within VAST ad-tags. To get started, see the IAB’s example on GitHub or test it yourself using this SIMID ad tag. If you have questions about the IMA SDK, see the SDK documentation or reach out to us on the IMA SDK forum.

Update on the Google Ads API Beta

Since our last announcement in July, we've made several updates to improve the performance of the Google Ads API. Your feedback was essential to us in making these improvements and will continue to be throughout the remainder of the Beta.

What has been fixed?
Over the past several months, we've rolled out performance improvements to Google Ads API read and mutate functionality. Some of these updates are visible in recent versions of the API, such as the launch of GoogleAdsService.SearchStream() in v3_0, while other improvements have sped up the response times of existing services and methods.

What's next for the Google Ads API Beta?
It is our top priority to get the Google Ads API ready for general availability. This involves rolling out features for key user journeys, for example: a service for asynchronous batch updates. If you have any feedback on the API's readiness to address your tool's requirements, we'd like to hear from you!

Which API should I use?
Throughout the remainder of the Beta, the AdWords API will continue to be the primary API for programmatically accessing and managing Google Ads campaigns. When deciding whether to use the Google Ads API Beta to run production systems, please keep in mind that we may release updates in preparation for general availability. As a reminder, changes will be released in new versions of the Google Ads API Beta. They will not affect your existing code unless announced otherwise on this blog.

If you have any feedback or questions regarding the performance, feature availability and overall usability of the Google Ads API Beta, please contact us at [email protected].

Sunset of the Ad Manager API v201905

On Monday, June 1, 2020, in accordance with the deprecation schedule, v201905 of the Ad Manager API will be sunset. At that time, any requests made to this version will return errors.

If you’re still using this version, now is the time to upgrade to the latest release and take advantage of new functionality like CustomPacingCurves on LineItem objects and performing actions on CMS Metadata Values.

When you’re ready to upgrade, check the release notes to identify any breaking changes, like Activity and ActivityGroup IDs changing from type int to type long in v202005.

Then, grab the latest version of your client library and update your code. As always, don't hesitate to reach out to us on the developer forum with any questions.

Reviewing ad issues in mobile apps with the Google Mobile Ads SDK

In order to help mobile app publishers review ad issues (e.g., out-of-memory caused by graphic intense creatives, violations of Ad Manager policies, or AdMob policies and restrictions) in production apps, we have recently added an ad response ID to the ResponseInfo and GADResponseInfo objects in the Google Mobile Ads Android SDK (v. 19.0.0) and iOS SDK (v. 7.49.0). An ad response ID is a unique string for each ad response from the AdMob or Ad Manager server, regardless of ad formats. If the same ad is returned more than once, the ad response ID will differ each time.

You can look up an ad response ID in the Ad Review Center (AdMob, Ad Manager) to find and block the offending ad. You can also report problematic ads to Google using the ad response ID, especially when it is difficult to capture a mobile ad's click string.

The screenshot above shows an ad response ID in Android Studio logcat.

If you use Firebase, you can refer to the Firebase Crashlytics Android (AdMob, Ad Manager) or iOS (AdMob, Ad Manager) guide for logging the ad response ID. This technique can be useful for debugging production app crashes as you would have both the SDK symbols and the ad response ID data in the same log.

We hope this new feature makes it easier to troubleshoot ad issues.

If you would like to give us feedback on this feature, please post your comments and questions on our Google Mobile Ads SDK Technical Forum.

Reviewing ad issues in mobile apps with the Google Mobile Ads SDK

In order to help mobile app publishers review ad issues (e.g., out-of-memory caused by graphic intense creatives, violations of Ad Manager policies, or AdMob policies and restrictions) in production apps, we have recently added an ad response ID to the ResponseInfo and GADResponseInfo objects in the Google Mobile Ads Android SDK (v. 19.0.0) and iOS SDK (v. 7.49.0). An ad response ID is a unique string for each ad response from the AdMob or Ad Manager server, regardless of ad formats. If the same ad is returned more than once, the ad response ID will differ each time.

You can look up an ad response ID in the Ad Review Center (AdMob, Ad Manager) to find and block the offending ad. You can also report problematic ads to Google using the ad response ID, especially when it is difficult to capture a mobile ad's click string.

The screenshot above shows an ad response ID in Android Studio logcat.

If you use Firebase, you can refer to the Firebase Crashlytics Android (AdMob, Ad Manager) or iOS (AdMob, Ad Manager) guide for logging the ad response ID. This technique can be useful for debugging production app crashes as you would have both the SDK symbols and the ad response ID data in the same log.

We hope this new feature makes it easier to troubleshoot ad issues.

If you would like to give us feedback on this feature, please post your comments and questions on our Google Mobile Ads SDK Technical Forum.

Reviewing ad issues in mobile apps with the Google Mobile Ads SDK

In order to help mobile app publishers review ad issues (e.g., out-of-memory caused by graphic intense creatives, violations of Ad Manager policies, or AdMob policies and restrictions) in production apps, we have recently added an ad response ID to the ResponseInfo and GADResponseInfo objects in the Google Mobile Ads Android SDK (v. 19.0.0) and iOS SDK (v. 7.49.0). An ad response ID is a unique string for each ad response from the AdMob or Ad Manager server, regardless of ad formats. If the same ad is returned more than once, the ad response ID will differ each time.

You can look up an ad response ID in the Ad Review Center (AdMob, Ad Manager) to find and block the offending ad. You can also report problematic ads to Google using the ad response ID, especially when it is difficult to capture a mobile ad's click string.

The screenshot above shows an ad response ID in Android Studio logcat.

If you use Firebase, you can refer to the Firebase Crashlytics Android (AdMob, Ad Manager) or iOS (AdMob, Ad Manager) guide for logging the ad response ID. This technique can be useful for debugging production app crashes as you would have both the SDK symbols and the ad response ID data in the same log.

We hope this new feature makes it easier to troubleshoot ad issues.

If you would like to give us feedback on this feature, please post your comments and questions on our Google Mobile Ads SDK Technical Forum.

Reminder about sunset, creation of target spend field for Maximize Clicks strategies in Ads APIs

On July 31st, 2019 we began to sunset the target spend field for Maximize Clicks bidding strategies. At the time, the feature was only removed from the UI, and the Google Ads APIs were not impacted.

Starting on June 30th, 2020, we will continue to sunset the target spend field in the Google Ads APIs as per our original blog post. This will affect all versions of both the AdWords API and the Google Ads API. The following behaviors will be blocked:
  • Populating the target spend field on existing standard and portfolio strategies
  • Attaching portfolio strategies that have the deprecated field set to campaigns
Read on to see how this will affect your API usage:
Affected Target Spend Fields
Google Ads API campaign.target_spend.target_spend_micros
bidding_strategy.target_spend.target_spend_micros
AdWords API Campaign.BiddingStrategyConfiguration.TargetSpendBiddingScheme.spendTarget
SharedBiddingStrategy.TargetSpendBiddingScheme.spendTarget

Change Description
Any mutate operations that set a target spend field for the first time will return an error. You will be able to update a target spend field that currently contains a value, but you cannot set previously empty fields to a new value. Additionally, any operation attaching a bidding strategy to a campaign where that bidding strategy has a value set for a target spend field, will throw an error. To manage Target Spend on any new campaigns, we recommend using campaign budget. In each of these cases an error will be thrown.

Performing any of the actions listed above will generate one of the following errors:
  • OPERATION_NOT_PERMITTED_FOR_CONTEXT
  • UNSUPPORTED_FIELD_IS_SET
If you have any questions about this change or any other API feature, please contact us via the forum.

Postponement of DBM API v1 and SDF Download Service Sunset

We’re officially postponing the planned sunset of the Doubleclick Bid Manager (DBM) API v1 and the DBM API v1.1 Structured Data File (SDF) Download service.

Originally scheduled for June 15, 2020, we are delaying the sunset indefinitely in order to account for the difficulties many users are facing due to COVID-19. We’re hoping that this postponement frees up room for users to address more immediately pressing issues. An updated sunset schedule will be announced at a later date.

Although a sunset date is no longer scheduled, these services are still deprecated and migrations to DBM API v1.1 and the Display & Video 360 (DV360) API are recommended.

Announcing v202005 of the Google Ad Manager API

We're happy to announce that v202005 of the Google Ad Manager API is available starting today. This version adds new functionality to several use cases, like managing video ads.

For video ads, v202005 allows you to set competitiveConstraintScope and thirdPartyMeasurementSettings on video LineItems. Also, you can now get the duration of video metadata Content for better targeting. Additionally, you can manage your CMS metadata values by marking them as active or inactive.

Another improvement that v202005 brings is that ActivityGroup.id, Activity.id, and Activity.activityGroupId fields have been changed from type int to type long. So if your API integration is strongly typed, be aware that you might need to make changes for this update.

This release also includes a number of Beta features, like reporting on Nielsen Digital Ad Ratings, creating Makegoods for ProposalLineItems, and managing child networks through Multiple Customer Management. For the full list of API changes for v202005 and all other active API versions, check the release notes.

Feel free to reach out to us on the Ad Manager API forum with any API-related questions.

Announcing v3_1 of the Google Ads API beta

Today we’re announcing the v3_1 release of the Google Ads API beta. To use the v3_1 features, please update your client library. If you are upgrading from v1 or v2, some of your code may require changes when you switch to the new v3 endpoint. Please see the migration guide for more information on breaking changes.

Here are the highlights: Where can I learn more?
The following resources can help you get going with the Google Ads API: The updated client libraries and code examples will be published next week. If you have any questions or need additional help, please contact us via the forum.