Tagmadvertise

The new madvertise Android-SDK

Three days ago, madvertise, one of my favourite ad networks, updated its Android SDK in a major update to 2.0. So what changed and what’s new? Here is an overview over the major changes.

First of all, get the new SDK here.

How to make it work again: Renamed classes

When updating the new SDK, there are some minor changes a developer has to consider.

In order to make the naming of the SDK for iOS and Android equal, the names of the classes have been changed. Every class that started with ‘Mad‘ before now starts with ‘Madvertise’. So the MadViewCallbackListener is now called MadvertiseViewCallbackListener and the MadView is now called MadvertiseView. Accordingly, the method to set the MadvertiseViewCallbackListener is now called setMadvertiseViewCallbackListener(), not setMadViewCallbackListener().

The MadvertiseViewCallbackListener now has two more callback methods:

public void onError(Exception exception)

which will be called when an exception in the SDK occurs and

public void onIllegalHttpStatusCode(int statusCode, String message)

which will be called when the madvertise-Server returns something different than a HTTP status code 200. The code you will probably see the most is a 204, which means that the device requesting an ad is not yet known to the madvertise-Server.

Also, the banner-type ‘iab’ has been renamed to ‘medium_rectangle’. However, at the moment ‘iab’ still works.
When you included all these changes, everything should work fine again.

New functionality

The update of the SDK adressed some bugs many of you experienced. Here is an excerpt:

  • Requests are now interrupted when a MadvertiseView is destroyed.
  • No reloading of ads when a phone is turned, keyboard is being opened, and so on, anymore.
  • Banners are scaled correctly now.
  • Before, when the request interval was set to <60, it was adjusted to 30 automatically.
  • The width of a MadvertiseView was sometimes not calculated correctly

There are also some improvements where you have to do nothing to activate them:

  • Animated banners: Ads provided as animated GIFs are now played when the device is capable of doing so.
  • Banners are shown automatically now, so you don’t need a MadvertiseViewCallbackListener to make your ads visible anymore.
  • Ads now don’t acquire space in the layout before they are shown.
  • Multiple ads: You can now display more than one ad on a screen, for example one fixed on top and one in a list. However, the total number of ads on a screen should not exceed four.

And there are some new features you should think of when integrating the new SDK:

  • New banner formats – you can now display the following banner types:
    • mma (320×53)
    • medium_rectangle (320×200)
    • leaderboard (728×90)
    • fullcreen (768×768)
    • portrait (766×66)
    • landscape (1024×66)
  • Multiple banner formats – you can now request multiple banner formats in your XML-declaration of a MadvertiseView like this:
           <de.madvertise.android.sdk.MadvertiseView
             android:id="@+id/madad"
             android:layout_width="match_parent"
             android:layout_height="wrap_content"
             mad:isTestMode="false"
             mad:backgroundColor2="#000000"
             mad:textColor="#FFFFFF"
             mad:bannerType="mma,portrait,landscape,leaderboard"
             mad:deliverOnlyText="false"
             />

The list is sorted by priority. So in the above example, when there is no mma-banner available, a portrait-banner will be shown, when there is no portrait-banner, a landscape-banner will be shown, and so on.

  • Animations: Ads can now be animated when they are received. To add an animation, add <attr name="animation" format="string" /> to your attrs.xml file. Now you can set animations in your XML-layout using mad:animation. You can choose between fade (default), left_to_right and top_down.
  • New request parameters: You can set the gender and age of your users by calling MadvertiseView.setGender() or MadvertiseView.setAge(). As these methods are static, it is recommended to call them before your layout is inflated.

 Conclusion

The new madvertise SDK comes with some nice new features and bug fixes. The new formats are suitable for tablets and phones with large screens like the Galaxy Nexus. I’m curious whether the animation banners and animation of new banners will lead to more clicks.

 

Please feel free to leave your thoughts and questions on the new update in the comments below.

Evolution of CPC (Cost per click)

Cost per click or CPC – that’s what its all about when comparing ad networks. There’s a tendency when reading through forums, that the average CPC has dropped noticeable in the last year. I’ve been a user of AdMob and madvertise for some time now, here are my average CPCs:

AdMob

To make a long story short, here’s a diagram:

Evolution of AdMob's CPC

The evolution of AdMob's CPC

As you can see there are ups and downs in the curve but currently, it seems we are more in a boom than in a recession.  The average CPC has been around 4 US-cents, that’s an acceptable value.

madvertise

Here’s the diagram:

The evolution of madvertise's CPC

The evolution of madvertise's CPC

Also madvertise had it’s ups and downs. whil around may this year, CPC dropped to about 10 US-cents, it has increased to almost 20 US-cents since then. It’s remarkable that madvertise’s average CPC was, even at its lowest, still almost twice as high as AdMobs best rate. If they had a better fillrate outside of Europe, I probably wouldn’t had to work anymore.

 

What are your experiences with CPCs? Did you experience some remarkable changes? Please feel free to tell us in the comments.

Android Income Report #5: September 11

Another month is over, it’s time for income facts again. Please excuse the delay, I’ll try to be more on time next month.

If you are new to this series, let me explain it to you: Since Android is an open platform, I decided to be open about the income I’m making with my private Android apps too. In the last report I aimed to reach $1,100 for the last month. You will see if it worked out.

For all income reports, please click here.

Which Apps?

3D Invaders – about 107,000 installs (+7k), 15% active

AL Voice Recorder – about 399,000 installs (+17k), 24% active

AL Voice Recorder Ad Free – 747 installs (+27), 41% active

Droid-Blog.net Android App – 235 installs (+44), 26% active

SmsToSpeech full – 686 installs (+11), 42% active

What did I do?

At about the 20th of September it was clear that I wouldn’t hit my goals. Fortunately I was just in between two projects and was able to invest a day. In that time I reworked the AL Voice Recorder technically and added two new features: A seekbar (finally!) and speech to text for the naming of records. Additionally I did something I should have done a long time ago: I integrated madvertise. I also published a minor update for 3D Invaders, but added no big features.

Advertising Stats

Enough talking, lets start with the facts!

Here are some statistics from the two advertising networks I’m using, AdMob and Madvertise. Please read the second income report for an explanation of the following numbers.

AdMob:

Requests: 348,715 (-90k)

Impressions: 324,318 (-96k)

Fill Rate: 93% (-2.79%)

Clicks: 7,390 (-1k)

CTR: 2.28% (+0.28%)

eCPM: $1.04 (+$0.13)

House Ads: 9,620 (-12.7k)

Adjusted Requests:  358,335 (-102k)

Adjusted Fill Rate: 90,51 (-0,65%)

Madvertise

As I’m not using house ads in Madvertise, no adjusted requests and fill rates are shown here.

Requests: 291,556 (+40k)

Impressions: 53,706 (+300)

Fill Rate: 18% (-3%)

Clicks: 2,292(-582)

CTR: 4,27% (-1.1%)

eCPM: $8,19 (-$2.09)

Performances of both networks were not as good as in the previous month. Since I added madvertise to the voice recorder who worse CTR than 3D Invaders, I can probably expect madvertise’s CTR to drop a little further this month.

How much?

This time I split up my ad revenue to give you a better overview of the potential performance of games vs. tools:

Madvertise:

3D Invaders: ~$398,72

AL Voice Recorder: ~$42,01

Madvertise Total: ~$440.73 (-$109.62)

 

AdMob:

3D Invaders: $134.13

AL Voice Recorder: $204.61

AdMob Total: $338,74 (-$41,94)

 

Market sales: ~$65,32 (-$24,08)

In-App purchases: ~$4.46 (-$3.77)

 

Total: ~$849.25 (-179.32)

I missed my goal big time. The retrogressive growth of my app downloads were clearly visible in my income this time. I hope the changes I made and will make will lead my income into the right direction for this month.

What’s next?

In the second half I hope I’ll be able to do a bit more development on my own apps so that I’ll be able to make some new releases soon. We will see.

Since I missed my goal for the last month, this time it again is $1,100.

 

Please feel free to share your own experiences and hints in the comments. Please also don’t hesitate to tell me if there is anything else you’d like to get some information about.

Where to place ads

Some of the readers of you asked me where to best place an ad. Here is what I know.

The app

We will look at an app that is a simple game it looks something like this:

It has childlike graphics and the hero is a red ball. In each level it has to reach the goal marked by a flag. It can be rolled to the left/right by touching the left/right side of the screen. A simplified heatmap of the clicks on the screen would probably look something like this:


Although I’m using a game for the visualization of the written word, everything I’m writing about ad placement here can be easily transferred to non-games or apps that run in portrait mode.

T he two ways

When optimizing your ad placement, there are two ways you can go: Optimizing for maximum visibility of the app or optimizing for the biggest amount of clicks, which can also be accidental.

Way one: Visibility

This is the first way. When taking it, you try to place your ad in a way that the user can see it well. When the user likes what he is seeing, he probably will click the ad.

So for our example game here, where the player has its hands placed on the bottom and most likely clicks to the left and the right half of the screen, the best position for an ad would be the centered top. When your app can be controlled by one hand and runs in portrait mode, the top left would also be a good place as most people are right handed. If you want to find the best place for maximum visibility of your ad, you can analyse the click behaviour of your user and adjust the ad placement accordingly or just use this little class I wrote to do so. For apps that run in portrait mode, the most times best place for visibility is on top.

The best placement when optimizing for visibility

Way two: Best CTR

The second way targets for both the wanted and the accidental clicks. Here, you place your ad in a way it is more likely that the user might click it by mistake. When applying this tactic, you should be aware of the TOS of your ad provider as most of them prohibit ad placements too close to often clicked areas.

For our example game, we would probably place our ad in the bottom right or bottom left because we can expect the most touch events there. Most portrait mode apps should place their ads on the bottom.

When optimizing for the best CTR, the ad should be placed like this

Which way you choose is up to you. While the latter might cause you to lose a couple of users, it will probably still generate you more money than the first one. When you want your ads to be clicked only when the user is really interested in its content, you should take the first way.

 

Do you have any best practices of ad placement, questions or criticism? Please feel free to share them in the comments.

© 2024 Droid-Blog

Theme by Anders NorenUp ↑