Posted:

A new episode of The Mobile Ads Garage has hit YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

Did you know that AdMob serves ads to more than two hundred countries and territories? To celebrate, The Mobile Ads Garage presents Episode 8 in two languages! Katie from the Mobile Ads SDK team stops by to help Andrew talk about rewarded video mediation. You'll hear the basics of how and why to use AdMob mediation and the Mobile Ads SDK to show rewarded video ads in both English and Chinese.

Rewarded video is a full-screen ad format in which users watch ads in exchange for something, typically an in-game reward. Because users hold the power of choice, they don't have to see ads they aren't interested in. Plus, publishers can build the view/reward cycle into the mechanics of their games, creating monetization strategies that actually increase user engagement. When you add all that to AdMob's ability to automatically prioritize mediated networks by eCPM, you've got a complete solution.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Posted:
Today we’re announcing the release of AdWords API v201607. Here are the highlights: If you’re using v201601 or v201603 of the AdWords API, please note that they’re now deprecated and will be sunset on August 27, 2016 and October 25, 2016, respectively. We encourage you to skip v201605 and migrate straight to v201607.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201607 migration guide. The updated client libraries and code examples will be published shortly.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

Posted:

On Wednesday, August 31, 2016, in accordance with the deprecation schedule, v201505 of the DFP API will be sunset. At that time, any requests made to v201505 will return errors.

If you're still using v201505, now's the time to upgrade to the latest release and take advantage of new features like workflow progress for Sales Manager. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library and update your code.

Significant changes include:

This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Sunset Announcements group and adjust your notification settings.

Posted:
What’s changing?

As announced yesterday, expanded text ads are now fully available to all AdWords accounts. Expanded text ads feature two headlines and a single long description line, and are optimized for the screen sizes of the most popular smartphones.

Starting October 26, 2016, expanded text ads will become the primary Search network ad type, and creation of standard TextAds will no longer be supported in AdWords. To make changes to text ads after October 26th, you will need to create a new ExpandedTextAd or ResponsiveDisplayAd as announced in the v201605 release. Expanded text ads are the next generation of standard text ads, and responsive ads for Display are the preferred upgrade option for text ads on the Google Display Network. Responsive ads are currently being rolled out to all accounts.

To get started with expanded text ads, check out these upgrade tips. To get started with responsive ads, check out these upgrade tips. The expanded text ads guide and responsive ads for Display guide provide details and code samples in multiple programming languages.

Where can I learn more?
Questions? Visit us on the AdWords API Forum or our Google+ page.

Posted:
Update:This deadline has been extended until January 31, 2017.

The expanded text ad format is now fully supported in Scripts. Expanded text ads are the next generation of the standard AdWords text ad and are optimized for smartphone screen sizes. The new format features two headlines, each up to 30 characters, and one 80-character description line. See our guide on ad types and related code snippets to learn more about using expanded text ads in Scripts.

Along with the AdWords user interface, AdWords scripts will stop supporting the creation of standard text ads on October 26, 2016. If you use the AdGroup.newTextAdBuilder() method to create standard text ads, be sure to update your scripts to use the new ExpandedTextAdBuilder class. Existing standard text ads will continue to serve beyond this date and scripts will still be able to retrieve them.

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

Posted:

A new episode of The Mobile Ads Garage has hit YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

Have you tried AdMob's Native Ads Express? It's a new native ads format open to all AdMob publishers that can help you slim down the monetization code in your apps, plus give you the chance to update your ad layouts without a redeploy. In this episode you'll see sample ads, implementations in Xcode and Android Studio, and details on how to create CSS templates that'll make sure the ads in your apps look the way you want. If you've been considering a move to native ads, this is a great way to get started.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Posted:
We are sunsetting support for the promotion line field of Product Ads in AdWords Scripts, since this feature has been retired in AdWords in favor of automated extensions.

As part of this change, we have marked the getPromotionLine() method of ProductAd and the withPromotionLine() method of ProductAdBuilder as deprecated. These methods will start throwing errors on September 15, 2016. If your script uses these methods, then make sure you review them and make necessary changes to ensure they continue to work as expected.

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

Posted:
We are delighted to announce the introduction of additional Metrics and Dimensions which are now available through the reports resource; the API now returns most of the fields that the UI Query tool makes available.

The Metrics and Dimensions reference page now includes the UI field names to help make conversions simpler.

New Dimensions New Metrics
AD_LOCATION ACTIVE_VIEW_ELIGIBLE_COUNT
ADVERTISER_DOMAIN ACTIVE_VIEW_MEASURABLE_COUNT
AGENCY_NAME ACTIVE_VIEW_MEASURABLE_RATIO
BRAND_NAME ACTIVE_VIEW_VIEWABLE_COUNT
CREATIVE_SIZE ACTIVE_VIEW_VIEWABLE_RATIO
DEAL_ID ACTIVE_VIEW_VIEWABLE_TIME
DEAL_NAME AD_IMPRESSIONS
DFP_AD_UNIT_ID AD_IMPRESSIONS_RPM
DFP_AD_UNITS DEALS_AD_REQUESTS
DFP_REQUEST_SOURCE DEALS_BID_RESPONSES
INVENTORY_OWNERSHIP DEALS_MATCH_RATE
INVENTORY_PARTNER_NAME DEALS_MATCHED_REQUESTS
MOBILE_APP_NAME LIFT_RATE
MOBILE_CARRIER_NAME VIDEO_AD_ABANDONMENT_RATIO
MOBILE_DEVICE_NAME VIDEO_AD_DROPOFF_RATIO
MOBILE_INVENTORY_TYPE VIDEO_AD_QUARTILE_ONE
MOBILE_OS_VERSION VIDEO_AD_QUARTILE_THREE
MOBILE_USER_BANDWIDTH VIDEO_AD_SKIPPABLE_SKIP_RATIO
VIDEO_AD_DURATION VIDEO_AD_SKIPPABLE_VIEWS
VIDEO_AD_DURATION_RAW VIDEO_AD_SKIPPABLE_VTR
VIDEO_AD_FORMAT

Posted:

One year ago we introduced a regular deprecation schedule for the DCM API. Since then, we've been listening closely to your feedback and looking for ways to improve. Today we're acting on this feedback and making a change to our announcement process, to address a common developer pain point.

Starting with the next release, we'll begin announcing sunset dates for the previous version, rather than the oldest version. This means that when v2.6 is released, a sunset date will be announced for v2.5. This small change means that the deprecation period for our releases will increase from 4 to 7 months, allowing developers more time to plan their migrations.

In order to transition to this new schedule, we're also announcing that the current previous version (v2.4) will sunset on November 30, 2016. Note that this version will be the last to provide a deprecation period shorter than 7 months.

As always, we look forward to hearing your feedback. If you think there's something we could do to make this process even better, please let us know on our developer forum.

Posted:
This is a reminder the AdWords API Workshops registration is still open! We've now also published the planned agenda on the Workshops Information and Registration Site. Once again, this is the list of events and their dates:
  • New York (Technical) - August 30th
    • Note: only a few seats left.
  • Zürich (Technical) - August 30th (presented in English)
  • Hamburg (Technical) - September 7th (presented in English)
    • Note: this workshop is now full. Please consider joining us in Zürich instead.
  • San Francisco (Technical) - September 9th
  • Tokyo (Technical) - September 12th (presented in Japanese)
  • Shanghai (Business) - September 13th (presented in Chinese)
  • London (Technical) - September 16th
    • Note: only a few seats left.

The Technical workshops are for experienced API users, and we are going to talk about advanced use cases on a very technical level.

The Business workshops cover use cases, automation, scaling, and tools. There will not be any deep technical content in this workshop, so anyone can attend.

Posted:
The v201601 release of the AdWords API included a new optimizeOnEstimatedConversions attribute of Customer.conversionTrackingSettings that allowed you to opt-in to including cross-device conversions in the Conversions column. With this option set to true, AdWords includes cross-device conversions when optimizing for conversions in an automated bid strategy.

What's changing
  • Starting on August 16, 2016, new AdWords accounts will automatically have optimizeOnEstimatedConversions set to true.
  • During September, 2016, the optimizeOnEstimatedConversions setting will be changed to true on all existing AdWords accounts to give you the most complete view of performance possible.
  • Starting on September 6, 2016, the optimizeOnEstimatedConversions field in the AdWords API will become read-only. If your CustomerService mutate request attempts to modify this field by sending a value other than the current value, the request will fail with RequestError.INVALID_INPUT.
For more information, check out the recent Inside AdWords blog post on cross-device conversions.

What you should do
Prior to September 6, 2016, ensure that your CustomerService mutate requests do not attempt to modify the value of optimizeOnEstimatedConversions. You can also migrate your accounts before the migration by setting optimizeOnEstimatedConversions to true.

If you have any questions, please post on the forum or the Ads Developers Plus Page.

Posted:
Historically, device-specific bid modifiers were supported only for HighEndMobile, and were not allowed on other Platforms. Now, as part of our mobile-first initiative, we're extending this functionality to include support for these bid modifiers for all platforms.

All versions of the API currently permit bid modifiers for Desktop and Tablet criteria to be returned and modified in requests for test accounts only, allowing you to manage these bid modifiers programmatically. We will be rolling out this feature to live accounts for all versions over the coming weeks. These bid modifiers will be allowed on both the campaign and the ad group level.

If you rely on fetching bid modifier information in your app, these upcoming changes will affect you. Once device-specific bid modifiers launch on the web interface, users of the web interface may add them and they will be returned when making requests with the API. This can be particularly impactful if your application has made assumptions that the Desktop bid is a static, base bid, which is no longer the case.

If you have any questions about this change, or other questions about the AdWords API, contact us via the forum.

Posted:

At I/O 2016, AdMob announced Native Ads Express, a new way to implement native ads that offers some useful advantages. With Native Ads Express, publishers create CSS templates with styling information like font names, colors, and so on, and the server uses those templates to create finished ads. Building ads this way means the work of laying out all the elements happens in the cloud, not on the device. The result is an ad format that fits somewhere between a native ad and a traditional banner, but still offers publishers a seamless, natural presentation.

If you watched the AdMob I/O session on native ads, or you've checked out the guides and samples, you're probably familiar with the implementation details at this point. What you might not be sure about, though, is exactly what this new format offers your apps, and how to know if it's right for you, so here are the key benefits of Native Ads Express:

Less mobile code required

Because ad presentation is handled at the server level, a lot of the work is done automatically. Publishers don't need to manually inflate ad layouts, instantiate UIViews, or pull asset data out of ad objects--all things normally done in mobile code on the device. With those tasks gone, there's not that much required code left. For example, the Android sample for Native Ads Express needs just one layout element and two lines of Java to display an ad.

Change ad layouts without redeploying

Your CSS templates live on the server, not within the app itself. That means if you decide you want to tweak a background color or move the call to action button, you can log into the AdMob console and update your CSS code or even switch templates entirely. Hit save, and you'll start seeing the new design in production, with no redeploy to the App Store or Play Store required.

Flexible sizes mean your layouts feel natural across devices

Native Express ad units have size categories rather than rigidly defined sizes. Publishers can use different height and width values to make requests to a single ad unit, and the responsive creative will flex to fill it properly. That means devices with different screen sizes can have an ad that looks just right, with only one ad unit required.

They're great for scrolling content regions

Impressions aren't recorded for a Native Express ad until it's actually displayed, meaning they're ideal for use in RecyclerView- and UICollectionView-based interfaces. Publishers can load Native Express ads in advance of a scroll without worrying that false impressions will affect their clickthrough rate.

The CSS editor features a live preview

After picking a base template for your ads, the CSS editor in the AdMob console shows you a live preview while you customize. If you tweak the font family for one of the elements, you'll see that change take effect on a sample ad right there in your browser. The same goes for colors, sizes, you name it. Plus, the editor can validate the templates for publisher policy concerns. On the odd chance there's an issue, it'll be caught and clearly explained.

We've got a bunch of resources to help

We've got guides for Android and iOS, samples for Android and iOS (including Swift!), and Help Center articles that cover how to create CSS templates and how the creative's HTML code is constructed.

As always, if you have technical questions about the Mobile Ads SDK, you're welcome to stop by our support forum.

 - , Mobile Ads Developer Relations

Posted:
We’re pleased to announce the final round of workshops for AdWords scripts in 2016. The workshops will be held at the following locations:
  • London, UK: 30 August 2016 (register)
  • Hamburg, Germany: 5 September 2016 (register)
This round of workshops will cater to both novice and experienced scripters. We'll have code labs where you’ll build your own scripts from scratch with help from the Scripts team. Bring your laptop and some scripting ideas, and we’ll turn them into reality!

Whether you’re an advertiser who wants to learn about how scripts can automate your account management tasks, a developer who wants to polish your scripting skills, or a scripts enthusiast who wants to bounce around some ideas, you can find it all in these workshops.

Visit our website to check out the full agenda and sign up.

If you have any questions about the workshops, you can post them on our forums. Check out our Google+ page for AdWords Scripts updates.

Posted:

In the past, we’ve thrown AUTHENTICATION_FAILED errors as API exceptions whenever an OAuth2 access token was invalid, expired, or missing. Starting on the release date of v201608, the DFP API will reject these requests as HTTP 401 errors (unauthorized access) instead of as API exceptions for all versions.

If you really break it down, this is a win-win for everyone involved. You don’t waste application quota on authentication requests that are already going to fail, and we can focus on doing what we do best, responding to valid API requests.

What does this mean for you? That’s a bit trickier. If you’re catching the old authentication errors raised by our client libraries, then you’re going to want to shift your integration to catching HTTP errors instead. Since our client libraries are implemented with language-specific practices in mind, you’d be looking for these new occurrences to show up as either errors raised by the underlying HTTP or SOAP libraries or wrapped HTTP errors in the libraries themselves. These failures are generally deterministic and require user action - either to generate a new refresh token, to add a new API user, or to create a valid client - so this is mostly a shift in where to catch the exception rather than wrapping with retry logic.

As usual, if you have any questions or just want to talk about API things, let us know on the developer forum.

Posted:

We have added support for AdWords API v201605 reports in AdWords Scripts. The major changes in this release are:

See the AdWords API release notes for more details.

v201603 will remain the default version of the reports until July 20, 2016. This gives you enough time to verify your scripts and make sure it works with the latest report version.

If you use API versioning in your reports, you need to modify your code to use v201605:

  var report = AdWordsApp.report(query, {
    apiVersion: 'v201605'
  });

If you don’t use API versioning, no code changes are required. Your reports will continue using v201603 for now, and switch to v201605 when we make v201605 the default version on July 20, 2016.

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