(Translated by https://www.hiragana.jp/)
Google Ads Developer Blog: adwhirl

Today we are excited to introduce a new channel for communication - Ads Developers Google+ Page. It's a place to stay informed, engaged and connected on Ads products and developer tools.

Add our Google+ page to your circles for the latest product and feature announcements, best practices, case studies, as well as opportunities to interact with and learn from Google's Ads Developer Relations team and other members of the developer community.

We look forward to having one place to bring timely updates, concise announcements, and to share information in multimedia formats across all Ads products, as well as to listen and respond to your comments.


We're very pleased to announce the availability of the AdWhirl to AdMob Ad Network Mediation Import Pipeline. This functionality--accessible from mediation.admob.com--will enable you to import all of your relevant configuration data from AdWhirl in just a few clicks!

We're very pleased to announce the availability of the AdWhirl to AdMob Ad Network Mediation Import Pipeline. This functionality--accessible from mediation.admob.com--will enable you to import all of your relevant configuration data from AdWhirl in just a few clicks!

Getting started is simple! Here are the steps you'll want to follow to import a configuration:

  1. Navigate to mediation.admob.com and click the Import Placement from AdWhirl link. Read through the notes.
  2. Click Log in to AdWhirl. You'll be redirected to an AdWhirl authorization page where you should enter your AdWhirl account's email address and password.
  3. Click Submit. Assuming your info is correct, you'll be redirected back to AdMob's Import Placement from AdWhirl workflow, where you can choose a particular placement to pull over.
  4. Mouse over a placement and click the Select to Import button. After confirming things are correct on the Review & Import screen, go ahead and click the final Import button.
  5. Put your feet up, grab a brew; you're done! Take a moment to bask in the warm glow of your accomplishment. The placement will now appear in your AdMob Ad Network Mediation Placements interface.

The AdMob Ad Network Mediation product offers many improvements over AdWhirl, including enhanced stability, support for tablet sizes, revenue optimizations by country, and improved reporting. We hope you give it a look! As always, if you have questions or concerns, you can get a hold of us on our forum.

We're very happy to announce the release of AdWhirl v3.2! This version brings us support for the latest and greatest from several ad networks. In particular:

Android:

  • Support for AdMob v6.0.1
  • Support for Millennial v4.5.1
  • Support for InMobi v350

iOS:

  • Support for AdMob v6.0.4
  • Support for Millennial v4.5.5
  • Support for InMobi v350

As always, you can find the latest SDKs available on our download page. Or, feel free to snag the source: (Android | iOS). If you encounter any issues, don't hesitate to contact us on our forum or during Office Hours--times to be announced on our blog.


We’ve received questions asking us what happens new ad networks are added to an existing AdWhirl application. In this post we’ll explain how older versions of your apps will handle a new ad network configuration.

We’ve received questions asking us what happens new ad networks are added to an existing AdWhirl application. In this post we’ll explain how older versions of your apps will handle a new ad network configuration.

Say you published an application using AdWhirl, configured to use two ad networks. Now it’s time to release the next version, and you’d like to add a third ad network while you’re at it. But how will that affect the ad network request distribution for users running an older version of your application, which doesn’t have the new ad network SDK bundled? Older versions will request the updated configuration for both iOS and Android, but the two SDKs will process the configuration differently.

How the iOS SDK Distributes Ad Network Requests

When the iOS SDK parses the new configuration, it will only consider an ad network valid if it meets certain conditions, including having the corresponding network adapter. If the adapter doesn’t exist, then that network will be ignored. Your ad network percentages will then be normalized based on the total valid percentage of allocations.




Let’s demonstrate this with the above example. Say your original app had two ad networks, Network 1 and Network 2; now you’re adding Network 3 to the next version of your app. If your new ad network configuration sends 30% of requests to Network 1, 10% to Network 2, and 60% to Network 3, users running an app version without Network 3 will send 75% of the total ad requests to Network 1 and 25% of requests to Network 2. Backfill priority will be the same as specified on the server, but it will not include network 3.

How the Android SDK Distributes Ad Network Requests

When the Android SDK parses the new configuration, it will blindly add all networks as valid choices. When it tries to make a request to an ad network whose SDK is not available, the request will fail gracefully. However, AdWhirl will then rollover to your backfill priority. What does this mean for the ad network percentage distribution?




Using the same example configuration, the 60% of requests to Network 3 will fail for users with an older version, and AdWhirl will rollover to your top backfill option. If your top backfill option is Network 2, then Network 2 will consume the Network 3 traffic - you will have 30% of all requests going to Network 1, and 70% to Network 2. This is likely not what you would expect, so be careful when adding new networks to an existing Android application.

In summary, the iOS SDK will respect the percentages given to the valid ad networks (expected), but the Android SDK will send the invalid ad network traffic to the top backfill option (unexpected).

We value your feedback, so please post to our developer forum if you have any questions about AdWhirl.

The AdWhirl SDK provides a framework that allows developers to display banner ads from different ad networks in their iOS and Android applications. You simply tell AdWhirl what ad networks you want to use and the percentage of requests to allocate to each network, and AdWhirl handles the ad requests. But how do you choose an acceptable refresh rate, and what settings should you use for both AdWhirl and your individual ad networks?

The AdWhirl SDK provides a framework that allows developers to display banner ads from different ad networks in their iOS and Android applications. You simply tell AdWhirl what ad networks you want to use and the percentage of requests to allocate to each network, and AdWhirl handles the ad requests. But how do you choose an acceptable refresh rate, and what settings should you use for both AdWhirl and your individual ad networks?

AdWhirl has its own refresh rate; when it comes time to refresh, AdWhirl removes the current network’s ad view, chooses a new ad network, and creates a new ad view for that network. So how is this different from the AdMob refresh rate? Well, the AdMob refresh rate determines when its own ad view will request a new ad.

AdWhirl does not know about the specific ad networks’ refresh rates. Most networks expose the refresh rate on the client side; AdWhirl takes advantage of this by turning off refreshing for these networks. AdMob, however, only supports configuring the refresh rate on the server side. Therefore, AdWhirl must rely on you, the developer, to turn off the network refresh rate. Forgetting to do so may result in unexpected refreshes. This is best demonstrated with an example.

Let’s say AdWhirl has selected the AdMob network for displaying an ad, and your AdMob refresh rate is 29 seconds while your AdWhirl refresh rate is 30 seconds. AdWhirl will load up an AdMob view, and then the AdMob view will request and show an ad. After 29 seconds, AdMob decides it's time to refresh, grabs a new ad on it's own, and displays a new ad. AdWhirl has no idea that AdMob just refreshed. One second later, AdWhirl decides it’s time to refresh (30 seconds have passed), and removes the AdMob view and picks a new ad network from which to show an ad.

In the above example, AdMob displayed a new ad that was shown for only one second--it had virtually no chance of being clicked. This results in extra impressions that reduce your click through rate and confuse your customers. To avoid having AdMob refresh on its own, make sure to turn off automatic refreshing for the AdMob publisher ID you are mediating with!

Please post to the forum for any questions regarding refresh rates. You’re also welcome to attend one of our office hours hangouts.

We’re very pleased to announce the release of AdWhirl v3.1.1 for both Android and iOS platforms. This update heralds support for the Nexage ad network and includes refreshed adapters for Millennial Media, InMobi, and AdMob—ensuring support for their latest SDK versions.

We’re very pleased to announce the release of AdWhirl v3.1.1 for both Android and iOS platforms. This update heralds support for the Nexage ad network and includes refreshed adapters for Millennial Media, InMobi, and AdMob—ensuring support for their latest SDK versions.

Additionally, we’ve taken the opportunity to fix several bugs, specifically:

  • (iOS) Reachability NPE [Issue 118]
  • (iOS) Null dereference error [Issue 179]
  • (Android) Build rules for creating the AdWhirl jar
  • (Android) Fixes for Android 1.5/1.6 crashes [Issue 221]

Go ahead and kick the tires; you can find the zips listed on our downloads page. As always, holler at us on the forum if you encounter any issues.