Google AdMob Ads SDK v6 Released!

[Raj Parameswaran]

We've just released v6.0.1 of the Google AdMob Ads SDK for iOS and v6.0.0 for Android.  This version includes our free AdMob Ad Network Mediation solution, as well as new "Smart Banner" formats for dealing with multiple screen sizes.  

Check out this blog post for more information or the AdMob developer site to use these new features. As always, grab the latest release from our downloads page at https://developers.google.com/mobile-ads-sdk/download. 

Cheers, 
Raj

[William Ferguson]

Raj what happens if you have an ad network defined that does not have a corresponding to network SDK in your app?

This will be an issue for users that don't upgrade to a new version of your app, if you add in an network at some future point.

William

[Eric Leichtenschlag]

William,

This is a great question that I plan to write a blog post about at some point.

There are two ways to specify network distribution - eCPM (you define what these values are) and percentage allocation.

Under eCPM allocation, we'll always request what you put as the highest eCPM first, and then go down the line if networks return a no fill.  So for users who don't have a particular network, in their version of the apk, the SDK gracefully fails that network and tries the next one.

Under percentage allocation, we randomly pick a network based on your given percentages, and if that network fails, we choose again with the remaining percentage normalized.  So if you had 60% network A, 30% network B, and 10% network C, then if A is chosen first but the request fails, then it will be 75% chance you'll get B next and 25% chance you'll get C next.

One thing to note: The order of the networks is determined server-side, and the client caches the results for a short period of time.  So if you have 95% network A and 5% network B, don't be surprised if network B gets a few requests in a row on the 5% chance the server chooses network B as the first network on a config fetch.  The percentages of course should even out over time.

Eric

--

Eric Leichtenschlag | Developer Programs Engineer | eleich...@google.com | 650-776-5591

[William Ferguson]

Thanks Eric.

Are there any plans for auto allocation based on eCPM?

It seems strange to manually configure eCPM cutoffs for different networks when it should be possible to determine which network has the highest eCPM for a particular request and retrieve an ad from there. 

William

On Friday, April 20, 2012 11:21:48 AM UTC+10, Eric Leichtenschlag wrote:

William,

This is a great question that I plan to write a blog post about at some point.

There are two ways to specify network distribution - eCPM (you define what these values are) and percentage allocation.

Under eCPM allocation, we'll always request what you put as the highest eCPM first, and then go down the line if networks return a no fill.  So for users who don't have a particular network, in their version of the apk, the SDK gracefully fails that network and tries the next one.

Under percentage allocation, we randomly pick a network based on your given percentages, and if that network fails, we choose again with the remaining percentage normalized.  So if you had 60% network A, 30% network B, and 10% network C, then if A is chosen first but the request fails, then it will be 75% chance you'll get B next and 25% chance you'll get C next.

One thing to note: The order of the networks is determined server-side, and the client caches the results for a short period of time.  So if you have 95% network A and 5% network B, don't be surprised if network B gets a few requests in a row on the 5% chance the server chooses network B as the first network on a config fetch.  The percentages of course should even out over time.

Eric

On Thu, Apr 19, 2012 at 5:32 PM, William Ferguson wrote:

Raj what happens if you have an ad network defined that does not have a corresponding to network SDK in your app?

This will be an issue for users that don't upgrade to a new version of your app, if you add in an network at some future point.

William

On Friday, April 20, 2012 5:35:04 AM UTC+10, Raj Parameswaran wrote:

We've just released v6.0.1 of the Google AdMob Ads SDK for iOS and v6.0.0 for Android.  This version includes our free AdMob Ad Network Mediation solution, as well as new "Smart Banner" formats for dealing with multiple screen sizes.  

Check out this blog post for more information or the AdMob developer site to use these new features. As always, grab the latest release from our downloads page at https://developers.google.com/mobile-ads-sdk/download. 

Cheers, 
Raj

--

Eric Leichtenschlag | Developer Programs Engineer | eleichtenschl@google.com | 650-776-5591

[bilal chaudry]

Haye! Raj , I am facing problem in adding admob 6.0 in one of my iPhone app , when adding publisher id as      bannerView.adUnitID=Publisher id it works, but when adding     bannerView.adUnitID= mediation ID it will not show any Ad :( , Please help me as soon as possible,

Best Regards
Bilal Sattar.

[Emanuel Moecklin]

Hi Raj

That's great news.

While implementing some of the networks I noticed:

1. It isn't sufficient to include the adapter jar of a certain
network. You always need the full sdk additionally to the adapter jar
because the adapter references classes in the regular sdk. Your
documentation states "download and add to your project the adapters
and SDKs of all the ad networks you'd like to serve ads from" but it
can easily be read over (I did ;-).

2. The MobFox sdk references classes in your sdk that aren't there any
more (com.google.ads.mediation.test.providers.AdapterInfoProvider
e.g.) which makes it impossible to use Proguard (well maybe there is a
solution with Proguard but I haven't figured it out yet).

3. The JumpTap sdk defines interfaces with methods that aren't
implemented by the according adapter classes -> the adapter classes
don't compile. The probably updated the sdk but forgot to update the
adapter code or haven't released the updated adapter yet.

Just wanted to share these findings with other developers to save them
some time.

Cheers
Emanuel Moecklin
1gravity LLC

On Apr 19, 3:35 pm, Raj Parameswaran <rajp...@google.com> wrote:
> We've just released v6.0.1 of the Google AdMob Ads SDK for iOS and v6.0.0
> for Android.  This version includes our free AdMob Ad Network Mediation

> solution, as well as new "Smart Banner<https://developers.google.com/mobile-ads-sdk/docs/smartbanners>"

> formats for dealing with multiple screen sizes.
>

> Check out this blog post<http://googleadsdeveloper.blogspot.com/2012/04/build-flexible-app-bus...>for more information or the AdMob
> developer site <https://developers.google.com/mobile-ads-sdk/> to use these

[Eric Leichtenschlag]

William,

We can't do an auto allocation because we don't know what the eCPMs are for any network other than AdMob.  We're only able to report impressions and clicks for all ad networks because we've asked that the 3rd party adapter code notifies AdMob that their ad request succeeded or failed (required for the mediation flow), and when their ad has been cilcked.  We don't know what those clicks are worth though.

Ideally you (the publisher) know who is paying the most, and you can reorder the priority based on this.

Eric

Eric Leichtenschlag | Developer Programs Engineer | eleich...@google.com | 650-776-5591

[William Ferguson]

Ahh, OK, my misunderstanding of the way the distribution using eCPM works.

I had thought that the eCPM the developer set for a network was a lower bound and that ads would be displayed from that network when the network had ads that were paying greater than the lower bound.

But that's not the case is it. It's just a number used to create an ordered list of networks, where the first network that can supply an ad does so. So there is no point in listing any networks after a network that is giving 100% fill rate.

William

On Saturday, April 21, 2012 2:56:58 AM UTC+10, Eric Leichtenschlag wrote:

William,

We can't do an auto allocation because we don't know what the eCPMs are for any network other than AdMob.  We're only able to report impressions and clicks for all ad networks because we've asked that the 3rd party adapter code notifies AdMob that their ad request succeeded or failed (required for the mediation flow), and when their ad has been cilcked.  We don't know what those clicks are worth though.

Ideally you (the publisher) know who is paying the most, and you can reorder the priority based on this.

Eric

Eric Leichtenschlag | Developer Programs Engineer | eleichtenschl@google.com | 650-776-5591

[Jason and Georgette]

How come the new Android SDK does not work with AdWhirl? AdWhirl is catching a NoSuchMethodException and it shows no Ad it gets passed to the next network.

[Eric Leichtenschlag]

Right, eCPM is just determining the order.  They don't have to be actual eCPM values; just the highest eCPM value you input will be the first network we request an ad from.

Eric

Eric Leichtenschlag | Developer Programs Engineer | eleich...@google.com | 650-776-5591

[Eric Leichtenschlag]

The latest AdMob SDK changed the return value for some methods used in the AdMob adapter for AdWhirl.  The AdMob adapter class files are expecting the old return value, and so it can't find the  correct method to use.

We're looking to update AdWhirl at some point to add compatibility for the latest SDK.  In the meantime, there are a couple workarounds:

1. Drop in the new AdMob SDK, and recompile the AdWhirl source yourself

2. Consider switching to AdMob Mediation

Thanks,

Eric

[Awesome]

I am also facing similar issue.

Any update please?

[Josh]

If I drop in the new AdMob SDK into the AdWhirl source project must I edit the adapter? Or just drop in and export?

Thanks In Advance

Jason

[Eric Leichtenschlag]

You should be able to just drop in and export.  The adapter is using setBirthday(string), which was deprecated in 6.0, but it should still run fine.

Eric

[sgabello]

Hey Eric,

One of the feature that I always dreamed of and I've been ableto get only on AdWhirl with a tricky workaround and more recently with MoPub, is the ability to disable the automatic backfill or the normalized percentage after failed requests.

Is there any plan to add this feature in future?

Thanks!

Eric

Eric Leichtenschlag | Developer Programs Engineer | eleichtenschl@google.com | 650-776-5591

[Eric Leichtenschlag]

Hello sgabello,

Could you explain your use case, or what you would like to see?  Right now, we have the ability to normalize percentages when each requests fails in the pipeline (use percentage allocation), or statically order the network order (use eCPM allocation, network with highest eCPM value gets requested first).  If you don't want backfill at all from a particular network, you simply wouldn't configure that network.

Thanks,

Eric

[Andrea Ottolina]

Hi Eric,

The use case is very simple: I don't want to show ads all the time a user is using my app. I'm lucky enough to have a successful app that generates over 3 millions ad requests a day. I have many many competitors but the reason why my app has gone viral is because I've chosen not to be too greedy and put a cap to the number of impressions to be between 10/20% of the total requests. In this way many users don't even see one ad during the whole time they use the app.

Let's face it, Ads are annoying... and if you find two apps that do the same job and have the same functionalities, but the first one has ads and the second doesn't... it's more likely that you will keep the first one.

On AdWhirl I was able to achieve this result by adding a custom event which basically did nothing more than hide banners, and set it to be the first in the backfill. So I had iAd at 90%, admob at 9% and my custom event at 1% (but first in the backfill). iAd has always had a very low fill-rate (around 5% in the past, less than 1% nowdays) and by nullifying the backfill with the custon event, I was able to control the number of ads sent to users.

I've got the same result recently with MoPub, which allows to set the fillrate manually for each ad network. However, even if MoPub gives you great control and the ability to fine-tune your Ad serving, I don't particularly like their SDK (it's very slow) and I sometimes the service is not very reliable.

Therefore I'd like to give AdMob a try... but as it is right now I can't, because I can't set it to behave as described before. And that's a shame because all I need is just a tiny, nice and simple switch to disable the automatic backfill. :)

That's it...

Cheers,

Andrea

[Eric Leichtenschlag]

Hello sgabello,

That's an interesting use case.  So essentially, you want to show iAd all the time if they return ads, but since they have a low fill rate, you want to backfill with AdMob.  But not all the time, since you don't want to spam the users with ads?

You do still have a similar option with the custom event here, which can essentially end the mediation flow and display an empty banner.  But like you said, with normalized backfill, you can't quite achieve the same configuration as you could with AdWhirl.

Did the AdWhirl setup work for you?  You said it was kind of a hack to implement the custom event to effectively stop the flow.  And with that hack in place, is that exactly how you wanted your requests distributed, or was it the best you could do with what was available?

You may consider trying something like 90% iAd, 9% custom events, and 1% AdMob with mediation.  When iAd returns no-fill, there would be a 10% chance that you'd get AdMob afterwards.  There would be a higher chance of hitting the custom event before even trying iAd though, so that doesn't quite satisfy the original requirements.

Eric

On Monday, May 7, 2012 5:06:52 PM UTC-7, sgabello wrote:

Hi Eric,

The use case is very simple: I don't want to show ads all the time a user is using my app. I'm lucky enough to have a successful app that generates over 3 millions ad requests a day. I have many many competitors but the reason why my app has gone viral is because I've chosen not to be too greedy and put a cap to the number of impressions to be between 10/20% of the total requests. In this way many users don't even see one ad during the whole time they use the app.

Let's face it, Ads are annoying... and if you find two apps that do the same job and have the same functionalities, but the first one has ads and the second doesn't... it's more likely that you will keep the first one.

On AdWhirl I was able to achieve this result by adding a custom event which basically did nothing more than hide banners, and set it to be the first in the backfill. So I had iAd at 90%, admob at 9% and my custom event at 1% (but first in the backfill). iAd has always had a very low fill-rate (around 5% in the past, less than 1% nowdays) and by nullifying the backfill with the custon event, I was able to control the number of ads sent to users.

I've got the same result recently with MoPub, which allows to set the fillrate manually for each ad network. However, even if MoPub gives you great control and the ability to fine-tune your Ad serving, I don't particularly like their SDK (it's very slow) and I sometimes the service is not very reliable.

Therefore I'd like to give AdMob a try... but as it is right now I can't, because I can't set it to behave as described before. And that's a shame because all I need is just a tiny, nice and simple switch to disable the automatic backfill. :)

That's it...

Cheers,

Andrea

[sgabello]

Hi Eric,

Yep... exactly... I don't want to spam users with ads! :)

I totally missed the presence of CustomEvents in AdMob Mediation! My fault... thanks for pointing it out.

However, as you said it's still not a perfect solution... but I can at least consider it now.

It doesn't give me the level of control that I'd like... but it's always better than no control at all! :)

If you'll ever add new features to the platform... please take also this kind of stuff into consideration.

Thanks,

Andrea

Slightly OT: I've been asking about issues with House Ads creatives and Retina displays... but I can't see the post anywhere on the discussion board. Shall I send the message again?