If you've created a Native Express ad unit recently, you may have noticed a new template format alongside App Install and Content: Video App Install. In the past few weeks, AdMob has rolled out support for video assets in Native Ads Express, giving publishers a new way to create more engaging presentations for their users.

How to get started

Enabling video demand for a Native Express ad unit is easy. Just open the ad unit's settings in the AdMob console, and look for the Ad type checkboxes at the top of the editor:

Check the checkbox marked "Video app install," and save the change. In a short while, your ad unit will start serving video creatives alongside the other two formats, with no code changes to your app required. That means you can update your existing apps to display this new format without redeploying to the Play Store or App Store.

An important thing to note is that video creatives are only available for ad units using the Large template size. The video player needs a certain amount of space, and the Large template ensures that it's available.

Customizing the experience

While there's no mobile code required to take advantage of Native Express Video, AdMob has introduced some new features to the API that allow publishers to customize the user experience. In particular, a new video options class (VideoOptions on Android, and GADVideoOptions on iOS) gives publishers a way to influence how the ads behave.

For example, the following code will cause video ads appearing in an Android NativeExpressAdView to begin playing with their audio on:

mAdView = (NativeExpressAdView) findViewById(R.id.adView);
mAdView.setVideoOptions(new VideoOptions.Builder()
    .setStartMuted(false)
    .build());

Staying in the know

App publishers can retrieve information about the video assets in their ads through the use of a video controller object (VideoController on Android, GADVideoController on iOS). The ad view classes for native express have been updated to include video controller properties that apps can grab and query for info like whether a video is present in the ad, and what its aspect ratio is. Even if the ad doesn't contain an video asset (or no ad has been loaded at all), you'll always get a valid reference to the ad view's video controller.

For example, here's a Swift snippet that shows how to check if an ad that just loaded contains a video asset:

func nativeExpressAdViewDidReceiveAd(_ nativeExpressAdView: GADNativeExpressAdView)
{
  if nativeExpressAdView.videoController.hasVideoContent() {
    print("Received an ad with a video asset.")
  } else {
    print("Received an ad without a video asset.")
  }
}

More Info

Native Express is designed to make implementing native ads easy, but if you have questions about how to get up and running or how you can best put it to use in your apps, stop by our support forum. The Mobile Ads Garage recently released an episode covering Native Express Video as well, with feature details and screencasts for iOS and Android:

 - Andrew Brogdon, Mobile Ads Developer Relations

Accurate click accounting is a critical aspect of any campaign. However, traditionally it often came with a high cost to the user experience: the user has to follow one or more HTTP redirects, or is forced to wait for a synchronous logging request to complete before they can navigate to their destination. The Beacon API addresses these shortcomings:

• Beacon requests are prioritized by the browser to minimize conflict with other time-critical operations, like reacting to user input.
• Beacon requests are guaranteed to be initiated before a page is unloaded and are allowed to run to completion without requiring blocking requests or other techniques that block processing of user input.

In short, Beacon provides a fire-and-forget API that ensures logging requests are queued and completed by the browser, without the need for blocking requests or additional redirects. This allows users to be taken directly to landing pages without waiting on the click account requests to complete, greatly reducing latency.

AdWords recently switched from redirects to the Beacon API to account for some of the ad clicks on Google.com. This resulted in significant latency improvements. For example, for ad clicks pointing to Google Maps pages, the median latency dropped by 250ms and the 90th percentile latency dropped by more than 1,000ms.

You do not need to take any action at this time to benefit from SendBeacon. Chrome, Firefox and Edge all support SendBeacon, accounting for over 72% of worldwide traffic. We are planning to leverage Beacon API in more of our products in the future, and we encourage everyone else to take it out for a spin.

Posted by Saurabh Mahajan, Leo Sei and Ilya Grigorik

AwReporting is an open-source Java framework optimized for large-scale retrieval of AdWords API reports.

We’ve just released a new major version of the tool that encompasses the full suite of AdWords API Reports and their fields. As mentioned in our pre-announcement, "aw-reporting-server” and “aw-reporting-server-appengine” modules were removed.

You can find the latest release on GitHub. Please find the full list of changes in the ChangeLog, and follow the migration guide to upgrade from the current version of the tool.

Feel free to ask questions or give us feedback via the forum or the project’s issue tracker.
Allison Greene, AdWords API Team

AdWords API v201605 will be sunset on March 28, 2017, after which all v201605 API requests will begin to fail. This version was deprecated on July 28, 2016. If you are still on v201605, we recommend that you skip v201607 and v201609 and migrate directly to v201702. Please be sure to migrate prior to the sunset to ensure your API access is unaffected.

We've prepared the following resources to help you with the migration:

• v201702 migration guide
• v201609 migration guide
• v201607 migration guide
• Release notes

As always, if you have any questions about this migration, please contact us via the forum.
Nadine Sundquist, AdWords API Team

Today we’re announcing the release of AdWords API v201702. Here are the highlights:

• Batch job support for shopping BatchJobService in all versions of the AdWords API now supports AdGroupCriterionOperations that modify shopping ProductPartitions. Check out the updated Batch Processing guide for details.
• Current attribution model reporting Several fields were added to reports to allow you to view historical stats using your current choice of attribution model.
• Message extensions You can now create message extensions via extension setting services to let customers send you a text message from your mobile ads.
• Affiliate location extensions You can now create affiliate location extensions to include the locations of stores where your product is sold in your ads. The updated Location Extensions guide has step-by-step instructions to help you get started.
• More policy details The new policySummary field of AdGroupAd provides additional details behind the approval status of your ads. For example, you can now differentiate between Approved (limited) and Approved ads.
• Showcase Shopping ads The AdWords API now supports Showcase Shopping ads which help customers discover what to buy and where to buy it. More details are in the updated Shopping Campaigns guide.
• Enhanced CPC for maximize clicks bidding strategies You can now opt in or out of enhanced CPC on standard TARGET_SPEND bidding strategies.

If you’re using v201605 or v201607 of the AdWords API, please note that they are now deprecated and will be sunset on March 28, 2017 and June 27, 2017, respectively. We encourage you to skip v201609 and migrate straight to v201702.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201702 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.
- Josh Radcliff on behalf of the AdWords API Team

At the moment, location extensions in AdWords can be sourced from two different places: a Google My Business account that is linked to your AdWords account or - for legacy users - manual location extensions created as feed items in AdWords.

What’s changing?
We’ll sunset manual location extensions on May 20, 2017 for all legacy users. You’ll no longer be able to manually create and manage Feed and FeedItem with a corresponding FeedMapping of placeholderType 7 (location extensions) and placeholderType 77 (location targeting) after this date. Instead, create your locations in Google My Business and link them to your AdWords account as outlined in our Location Extensions guide. You can use the Google My Business API to manage your business locations at scale.

What you should do
Please migrate your code before May 20, 2017 to avoid being impacted by this transition. See our guide for managing location extensions for further details, including an end-to-end code example. We recommend migrating your existing legacy locations alongside your code in order to have full control over your Google My Business account structure, test your setup, and avoid any downtime in location extension management. If you're not concerned about downtime, let us migrate your existing manual location extensions for you (you still have to migrate your code).

Auto-migration
All unmigrated manual location extensions stored in AdWords will be gradually auto-migrated starting from May 22, 2017.

• For each Customer Account with unmigrated manual location extensions, we'll pick all Manager Accounts at the lowest level of the manager hierarchy.
• For each such Manager Account, we'll create a single Business Account in Google My Business managed by the administrative users of the original Manager Account and its managers. The name of this Business Account will be ‘AdWords (<cid>)’, where <cid> is the AdWords Customer ID of the original Manager Account.
• We’ll also create Business Accounts in Google My Business for Customer Accounts not linked to any Manager Account. Those will be managed by the administrative users of the Customer Account.
• For each unmigrated location in the Customer Account, we'll create a new unverified business location in that Business Account and label it with its AdWords Customer ID. The original manually created feed items representing that location in AdWords will be removed.
• We'll replace all unmigrated location extension and location targeting feeds with new feeds linked to the shared Business Account created in Google My Business. In each feed, we'll set up a labelFilter based on the Customer ID to map each location to its original account.
• Any existing CampaignFeed and AdGroupFeed will be recreated to match the original setup, including their matching functions.

If you have questions while you’re upgrading, please reach out to us on the AdWords API forum.
- Timo Bozsolik, AdWords API Team

Starting in March, DoubleClick Campaign Manager (DCM) will be undergoing scheduled maintenance to make important updates to our systems. Every DCM account will be assigned a single maintenance window. However, these windows may be on different days for different accounts. More information about how this will affect the DCM product can be found in our help center.

How will this affect API users?

Maintenance is expected to last up to 8 hours per account. During that time DCM Trafficking will be read-only. While in read-only mode, all API delete, insert, patch, and update methods requiring the DCM Trafficking scope will be disabled. See the Scheduled Maintenance page on our developer site to learn more about the methods that will be impacted and the errors you may encounter.

What can API users do to prepare?

If your application accesses a single DCM account, we recommend simply planning ahead to avoid running workflows that use affected API methods during your account's maintenance window. Details of when this window will occur will be communicated in advance via in-product notification.

If your application accesses multiple DCM accounts, you may be subject to multiple maintenance windows. If it's not possible to plan around these windows, you should prepare your application to catch and handle maintenance related errors. Recommended error handling strategies include:

• For user initiated requests, return an error to the user along with instructions to wait up to 8 hours before retrying the request.
• For server initiated requests, retry automatically using an exponential backoff strategy. For example: pause 30 seconds before the first retry, 1 minute before the second, 2 minutes before the third, and so on up to a maximum of 8 hours. This strategy helps ensure you're not calling the API too aggressively and that your request quota is not being wasted.

Questions about this or anything else DCM API related? Contact us via our support forum.

- Jonathon Imperiosi, DCM API Team