[go: nahoru, domu]

We're pleased to announce that we'll be holding a series of Display Ads API Workshops in April 2017. These workshops are a half-day of tech talks, group discussions, networking activities, and one-on-one time with Googlers geared toward developers who use the DoubleClick for Publishers API, Interactive Media Ads SDK, or Mobile Ads SDKs.

These workshops offer you the following:

  • A great way for you to meet with the display ads API team to ask questions in person and give feedback directly to us.
  • A great opportunity to meet and exchange ideas with fellow developers in the community.
  • Previews of API and SDK roadmaps and select upcoming features.
  • For the first time, one-on-one office hours with ads API Googlers. Sign-ups will be available on-site on the day of the workshops.

The workshops will be held in the following cities:

For more information on the agenda and a preview of our talks, please see our workshop page.

As always, if you have any questions, feel free to drop us a line on the DFP API forums, IMA SDK forums, Mobile Ads SDK forums, or the Ads Developer Google+ page.

We have added support for AdWords API v201702 reports in AdWords scripts. The major changes in this release are:
  • New conversion fields to help when changing attribution models: CostPerCurrentModelAttributedConversion, CurrentModelAttributedConversions, CurrentModelAttributedConversionValue, and ValuePerCurrentModelAttributedConversion
  • Fields of type Double that don't represent percentages now return without a thousands separator and with two decimal places.
  • The AdGroupName and AdGroupStatus fields of the Audience Performance Report now behave as segments
  • All fields in the Call Metrics Call Details Report now behave as attributes
See the AdWords API release notes for more details.

v201609 will remain the default version for reports until the week of April 24, 2017. This gives you enough time to verify your scripts and make sure they work with the latest report version.

If you use API versioning in your reports, you need to modify your code to use v201702:
var report = AdWordsApp.report(query {
  apiVersion: 'v201702'
});
If you don't use API versioning, no code changes are required. Your reports will continue using v201609 for now, and switch to v201702 when we make v201702 the default version the week of April 24, 2017.

If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.

Are you tired of reading? Do you prefer to learn by watching? Then the latest series of AdWords API Workshop videos is for you! Visit the Ads Developers YouTube channel to discover more.

Recorded as part of the AdWords API Workshops - Fall 2016 events that toured 7 countries around the world, these short and easy-to-digest videos were presented by the experts from the AdWords API team. They cover the content presented in the technical workshop sessions on the following topics: The videos have subtitles available in English, Chinese (Simplified), and Japanese as well as auto-generated options for other languages.

Now you can watch all the Fall 2016 videos at your convenience. Also make sure to look at the associated slide decks that accompany these presentations.

Interested in attending similar workshops? Follow this blog for future workshop announcements.

Have questions? Feel free to visit us on the AdWords API Forum.

Starting this week BudgetOrderService get requests are available for all users, regardless of API version.

Previously, usage of this service was allowed on a whitelist-only basis. Now, you can retrieve your budget orders without being added to the whitelist. This enables you to view the account-level spending limit.

You still need to be whitelisted to modify your budget orders via the API; this new access applies only to viewing existing budget orders. Keep in mind that BudgetOrderService will only work on accounts that have been set up for consolidated billing; otherwise you will get an error.

To get started, check out the BudgetOrderService guide. If you have any questions about this change or other API features, please post on the forum.

We recently launched v3.3.0 of the Google Mobile Ads Unity Plugin with support for ad position offsets and Unity 5.6 compatibility. The updated v3.3.0 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.

Ad positions offsets

Version 3.3.0 of Google Mobile Ads Unity Plugin adds the ability to specify an x and y position for both BannerView and NativeExpressAdView objects. To position ad views outside of the existing AdPosition values, provide x and y offsets instead of an AdPosition when instantiating an ad view, as shown below.

BannerView bannerView = new BannerView(adUnitId, AdSize.SmartBanner, 50, 50);

The code snippet above creates a BannerView offset from the top-left corner of the screen by 50 density independent pixels in the x and y axis. NativeExpressAdView positions can be offset in the same manner, as shown below.

NativeExpressAdView nativeExpressAdView = new NativeExpressAdView(
        adUnitId, new AdSize(320, 150), 50, 50);

Support for Unity 5.6

Although Unity 5.6 is still in beta, the latest version of the Google Mobile Ads Unity plugin includes changes to be fully compatible with the upcoming release.

In addition to the new features outlined above, it is recommended to update to the latest version of the Google Mobile Ads plugin to take advantage of stability and bug fixes. The source code and a sample app for the plugin are available in our GitHub repo, as is the full changelog for this release. If you have any questions about Unity integration, you can reach us on our developer forum.

Starting today, Productstatuses will return all the issues present in the Diagnostics tab of Merchant Center. Historically, only data quality issues from the last 21 days were available from Productstatuses. This means that you may see more issues returned by Productstatuses than before, but the number of issues should now match those available in the Diagnostics tab of Merchant Center.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.

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:

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.

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.

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: As always, if you have any questions about this migration, please contact us via the forum.