Tag Archives: DFP

Kotlin and the Google Mobile Ads SDK

One of the biggest cheers from the crowd at I/O '17 came in response to Stephanie Saad Cuthbertson's announcement that Kotlin would be an officially supported language for Android development starting with Android Studio 3.0. If you're an AdMob or Doubleclick publisher who's been eager to make the leap to a new language, we've got another announcement you might like: now that the new version of Android Studio has launched, we've released bunch of new mobile ads resources to support the Kotlin community.

If you haven't seen Kotlin yet, it's a statically typed language developed by JetBrains that compiles down to the same JVM bytecode that Java does, but includes a number of new features that can make Android development faster and easier. Things like dedicated data classes with less boilerplate, the Elvis operator, lambdas, SAM conversion, explicit nullability for references, and lots of other modern language features come built-in. For more information, see Introduction to Kotlin (also from I/O '17) in which Andrey Breslav and Hadi Hariri code up examples of the language's best features:

When you're done, you can see those same features in action in our new developer resources, which are now available to the AdMob and Doubleclick publisher community.

Samples

The Mobile Ads DevRel team maintains a GitHub repository of Android samples covering our API, and we've pushed Kotlin versions for each ad format. If you been wondering how Kotlin's Android extensions work with AdMob's banner ad layouts, for example, we've got a new sample app that'll show you. If you're curious how native ads work with all the new nullability stuff, we've got you covered with Kotlin samples for those formats as well.

In addition, we've included a new version of our API Demo app, which features a navigation drawer full of individual API demos for things like banner sizes, category exclusions, and more, all in Kotlin.

Implementation Guides

We've also updated our publisher guides with Kotlin snippets wherever code is shown. Similar to the mobile ads guides for iOS (which show either Swift or Objective-C syntax with a click of a tab), the Android guides now let developers easily switch back and forth between Java and Kotlin implementations.

Questions?

If you take a look at the Kotlin guides and samples and find you've got questions about the best way to implement something in Android's first ever new language, stop by our support forum. Our staff there will be happy to help.

 - , Mobile Ads Developer Relations

Kotlin and the Google Mobile Ads SDK

One of the biggest cheers from the crowd at I/O '17 came in response to Stephanie Saad Cuthbertson's announcement that Kotlin would be an officially supported language for Android development starting with Android Studio 3.0. If you're an AdMob or Doubleclick publisher who's been eager to make the leap to a new language, we've got another announcement you might like: now that the new version of Android Studio has launched, we've released bunch of new mobile ads resources to support the Kotlin community.

If you haven't seen Kotlin yet, it's a statically typed language developed by JetBrains that compiles down to the same JVM bytecode that Java does, but includes a number of new features that can make Android development faster and easier. Things like dedicated data classes with less boilerplate, the Elvis operator, lambdas, SAM conversion, explicit nullability for references, and lots of other modern language features come built-in. For more information, see Introduction to Kotlin (also from I/O '17) in which Andrey Breslav and Hadi Hariri code up examples of the language's best features:

When you're done, you can see those same features in action in our new developer resources, which are now available to the AdMob and Doubleclick publisher community.

Samples

The Mobile Ads DevRel team maintains a GitHub repository of Android samples covering our API, and we've pushed Kotlin versions for each ad format. If you been wondering how Kotlin's Android extensions work with AdMob's banner ad layouts, for example, we've got a new sample app that'll show you. If you're curious how native ads work with all the new nullability stuff, we've got you covered with Kotlin samples for those formats as well.

In addition, we've included a new version of our API Demo app, which features a navigation drawer full of individual API demos for things like banner sizes, category exclusions, and more, all in Kotlin.

Implementation Guides

We've also updated our publisher guides with Kotlin snippets wherever code is shown. Similar to the mobile ads guides for iOS (which show either Swift or Objective-C syntax with a click of a tab), the Android guides now let developers easily switch back and forth between Java and Kotlin implementations.

Questions?

If you take a look at the Kotlin guides and samples and find you've got questions about the best way to implement something in Android's first ever new language, stop by our support forum. Our staff there will be happy to help.

 - , Mobile Ads Developer Relations

Simpler mediation with AdMob and DFP

Over the past few months, a couple new projects designed to streamline AdMob and DFP mediation have launched: mediation groups, open source adapters, and network-specific guides.

Open Source Mediation Adapters on GitHub

In partnership with some of our mediation partners, we've open-sourced many of the most popular adapters used with DFP and AdMob mediation. You can see for yourself at our GitHub repos for iOS and Android:

In addition to adapter source, there's also a project containing example adapter and custom event implementations, plus a test app.

Import Mediation Adapters with CocoaPods and Gradle

In addition to open-sourcing the adapters, we've also made importing compiled adapters into your projects simpler by uploading them to Bintray and making them available via jCenter and CocoaPods. Rather than downloading and manually including libraries, publishers can get the correct adapter simply by updating their Podfile with a line like this: 


    pod 'GoogleMobileAdsMediationMoPub'

...or their build.gradle file with a line like this: 


    compile 'com.google.ads.mediation:mopub:11.10.1.0'

With many ad networks choosing to distribute their SDKs in the same manner, it's frequently possible to bring a new mediation network into an app with nothing more that a Podfile or build.gradle tweak. For instructions on which gradle artifacts and CocoaPods to use, check the AdMob Mediation Overview (iOS, Android) and look for networks in the "Open source and versioned" section.

Network-specific guides

Each mediated network is a little bit different. They have their own front-end, their own reporting systems, and their own vocabulary including things like "placement," "location," or "zone." Once you start trying to add a second or third network to your mediation waterfall, things can get confusing in a hurry.

To help publishers navigate through these details, we've created network-specific guides for the mediation partners who have joined our open source repositories. Each one includes step-by-step instructions (with screenshots) that guide a publisher all the way from configuring their account in the mediated network's web site to setting up their mediation stack and importing the right adapter.

For more details, there's no better place to go than the guides themselves. You can find them in the AdMob Mediation Overview (iOS, Android).

Questions?

If you've got questions about our open source adapters or the best ways to get up and running with mediation, stop by our support forum.

 - , Mobile Ads Developer Relations

Brotli Compression in Google Display Ads

Posted by Michael Burns, Software Engineer, Publisher Tagging & Ads Latency Team

Our goal is to help publishers monetize their content and build sustainable businesses through advertising products that allow sites to load as fast as possible to minimize impact to user experience.

Almost two years ago, our compression team announced a new compression algorithm called Brotli. Today, we are happy to announce that the Brotli compression algorithm is now being used to compress Google Display Ads whenever possible. In our experiments, we see data savings of 15% in aggregate over standard gzip compression, and in some instances, a savings of over 40%! This reduces the amount of data sent to end users by tens of thousands of gigabytes every day! This also results in faster page loads and less battery consumption.

We hope results like this will encourage wider adoption and will advance web standards such as Brotli compression.

The Mobile Ads Garage: A new video series about using the Google Mobile Ads SDK

Today, the first episode of the Mobile Ads Garage hits YouTube! The Mobile Ads Garage is a new series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode will cover one aspect of the SDK, break down a feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

The series will make its home on YouTube's Google Developer Channel, where you'll find the first episode in the Mobile Ads Garage playlist along with a sneak peek of the next four.


In addition to being a new way that people can find out about the SDK and how to use it, the series is a way for publishers to let us know what features they'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.

 - , Mobile Ads Developer Relations

Google Mobile Ads fully supports Swift

Since its release a few years ago, Swift has evolved into a dynamic, modern programming language for developing iOS apps. With its growing popularity and open source, we’ve seen an increase in requests from our publishers to fully support Swift in the Google Mobile Ads SDK. We responded by releasing a complete set of example apps built in Swift, adding Swift code snippets throughout our developer docs, and adding Swift API reference docs to our developer sites.

Our GitHub repo now has Swift example apps for banners, interstitials, and native ads for both AdMob and DFP. We’ve also added a Swift version of our API Demo app. The API Demo app demonstrates features of the Google Mobile Ads SDK, such as new ways to customize ad requests, experiment with multiple ad sizes, and compare AdMob and DFP technologies, to help you improve the user experience and maximize ad revenue.

We’ve also added Swift code snippets to our AdMob, DFP, and AdX developer docs. With nicely formatted widgets that display Swift and Objective-C code side by side, you can now easily compare SDK implementations in both Swift and Objective-C.

Finally, we’ve added Swift API reference docs to our AdMob and DFP developer sites, providing full documentation of our iOS Google Mobile Ads SDK. Now you have access to API reference docs for both Swift and Objective-C, making it easier to integrate with our SDK.

The Google Mobile Ads SDK team is committed to supporting Swift, and we’ll continue to update our SDK, developer docs, and example apps to ensure we provide publishers with full support for the latest version of Swift. Whether you currently develop your iOS apps in Swift, or have plans to do so in the future, we hope the actions we’ve taken to support Swift in our SDK will help make your experience with Swift more enjoyable and your transition to Swift a whole lot easier.

If you have any questions or feedback regarding our SDK or Swift support, feel free to contact us through our forum.

 - , Mobile Ads Developer Relations

DoubleClick for Publishers back up and running

DoubleClick for Publishers experienced an outage this morning impacting publishers globally, across their video, display, native and mobile formats. Our team has worked quickly to fix the software bug and it's now back up and running, so our publisher partners can return to funding their content.

AdsPyGoogle Sunset on January, 5 2015

As an avid reader of this blog, you have undoubtedly already seen the announcement that our dear old friend, the client library known as ‘AdsPyGoogle,’ will be sunset on January 5, 2015. Yes—we too at Google are very sad about this.

Fret not! In its place, we have a more than capable replacement in the form of our new GoogleAds Python client library which is more lightweight, has far fewer dependencies, boasts improved utilities and functionality, and perhaps most importantly, supports Python 2.7 as well as 3.x.

If you need a starting point on how to perform this switch, we have a blog post detailing the differences between the two, as well as a nifty migration guide on Github.

As usual, if you have any questions, feedback, or comments, please don’t hesitate to reach out on the DFP or AdWords forums.

 - Nicholas Chen, DFP API Team

Life of a DFP Video Line Item Part II

In Part I, Chris showed you how to create and traffic a video ad. In Part II, you’ll learn how to get that ad displayed before your video content in Flash, HTML5, iOS, or Android.

The IMA SDK requires you to have an ad tag that points to your ad. An ad tag is a URL that returns a VAST response. The VAST (or VMAP) response contains information about your ad, including tracking URLs, clickthrough destinations, and the media files for the video ad. For more information about VAST, see the IAB website.

If you’re using DFP, the UI can generate an ad tag for you based on your line item and ad unit criteria. To generate the ad tag for your line item, follow these steps.

Now that you have your ad tag, let’s take a look at some of the parameters. We’ll use one of our standard sample tags for this exercise:

http://pubads.g.doubleclick.net/gampad/ads?
    sz=640x360&
    iu=/6062/iab_vast_samples/skippable&
    ciu_szs=300x250,728x90&
    impl=s&
    env=vp&
    gdfp_req=1&
    output=xml_vast2&
    unviewed_position_start=1&
    url=[referrer_url]&
    correlator=[timestamp]&
    scor=[timestamp]

sz
The size of the video ad that you’re requesting.
iu
Your “inventory unit” - the ad unit you created in Part I. This is in the format <network_code>/<ad_unit_code path>.
ciu_szs
If your ad unit has associated companion ads, their sizes will be listed here.
impl
The request mode. Here, “s” for “sync”.
env
The environment. Here, “vp” for “video player”. 
gdfp_req
Indicates that this is a DFP request rather than the legacy Google Ads Manager.
output
The type of output you want from your ad request. Typical values are “vast” or “vmap”.
unviewed_position_start
Enables delayed impressions for your ad. This ensures that an impression isn’t counted until the ad starts playing.
url
The URL of the page requesting ads. This will also be automatically filled in by the SDK.
correlator
This randomly-generated value will be filled in by the SDK. It’s used for a number of things, but they all boil down to detecting ad requests that come from the same instance of a page load.
scor
Like the correlator, but refreshed when your video stream changes rather than when the page refreshes. Used to detect ad requests that come from the same video stream instance.
For more info on these parameters, see this DFP help center article.

Now that you have a basic understanding of your ad tag, it’s time to plug it into your IMA SDK implementation. If you’d like to use a video player with the SDK pre-integrated, we have pre-baked solutions for HTML5, iOS, and Android. If you want to do your own SDK integration, check out the quick start guide for Flash, HTML5, iOS, or Android. In each of the sample implementations, you’ll find a reference to at least one ad tag.

For example, the HTML5 ad tag reference is in ads.js and looks like this:
adsRequest.adTagUrl = “YOUR_AD_TAG_HERE”;
Now fire up the sample and request an ad. Voila! You’ll now see the ad you trafficked in Part I serving as a pre-roll to your video content!

As always, if you have any questions feel free to contact us via the support forum.

 - , IMA SDK Team

Introducing Active View reporting in DoubleClick: A foundation for brand measurement

In an important step toward making brand measurement as actionable as the click, customers of our DoubleClick platform globally now have access to Active View reporting. Advertisers, agencies and publishers now have access to a common, integrated metric to evaluate and compare the viewability of impressions across the web.

Digital advertising can provide brand marketers better measurement for their campaigns, but to do so, we must transition to a market where viewable impressions are a standard currency. On March 31, the Media Rating Council took the first step toward making viewable impressions a standard by lifting its advisory to refrain from transacting on viewable impressions as a digital advertising currency. We’ve always been a strong supporter of the viewability standard and we’re excited to roll out our MRC-certified viewability solution Active View to our DoubleClick partners.

DoubleClick clients globally now have access to Active View viewability reporting by default in:
  • DoubleClick for Publishers, for publishers using Google Publisher Tags 
  • DoubleClick Ad Exchange, in the new Query Tool
  • DoubleClick Digital Marketing
    • DoubleClick Campaign Manager, including reach and frequency
    • DoubleClick Bid Manager

From measurement to currency, the future of Viewability
Moving from served impressions to viewable impressions as the standard unit of measurement in the advertising ecosystem will be a huge shift but, leaders in the industry see opportunity ahead.
“The shift toward viewability will bring more brand spend to digital, ultimately benefiting premium publishers,” says David Payne, Chief Digital Officer at Gannett. “Viewability provides us another proof point that shows how our premium content creates highly engaged audiences perfect for branding campaigns.”
"At VivaKi, we’re passionate about viewability because an ad served that is not viewable is an inefficient use of our clients’ resources,” says VP Audience Media Strategy Phil Shih. “In the future, viewable premium inventory will demand a higher CPM than unviewed impressions; but it’s worth it for the sake of growing your brand.”

Providing a common measurement metric is the foundation for a world where we can transact on viewable impressions. But measurement alone does not make viewable impressions a currency. For this, we need to develop technology that allows advertisers and publishers to not only measure, but also transact viewable impressions. We already enable this on the Google Display Network and, we’re also investing in tools on the DoubleClick platform to allow advertisers and publishers to value, buy, sell, serve and optimize to viewable impressions. 

The transition to viewable impressions will not happen overnight, but as more brands, agencies and publishers adopt the viewable standard, we can create a more transparent and actionable display ecosystem for brand advertisers. We look forward to working with our clients and industry bodies to turn viewability into a new currency for the web.

Posted by Sanaz Ahari, Group Product Manager, Brand Metrics


Sign up to receive industry updates from DoubleClick in your inbox. Click here to opt-in to the DoubleClick Digital Marketing Newsletter today.