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.
QualityScore
--
get
query
Conversions
getCustomers
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.
- Chris Seeley, DFP API Team
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.
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
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.
- Jonathon Imperiosi, DCM API Team
true
optimizeOnEstimatedConversions
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:
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.
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.
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.
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.
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 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.
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.
- Nicholas Chen, DFP API Team
We have added support for AdWords API v201605 reports in AdWords Scripts. The major changes in this release are:
unknown
KeywordId
CAMPAIGN_PERFORMANCE_REPORT
CAMPAIGN_PLATFORM_TARGET_REPORT
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.
v201603
If you use API versioning in your reports, you need to modify your code to use v201605:
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.
- Anash P. Oommen, AdWords Scripts Team
