There is new way to monetize, without ads taking up space in your apps.

[MaxApps]

As the performance of my ads started to drop over the summer and with Google´s new policy, I started wondering if there were other ways to make money.
I searched for new ideas and found one that caught my attention.
How about letting someone else do all the advertising, while I make the money?

AppKey

The thing that got my attention was that I would be able to focus on building the app, without the need to accommodate ads that occupy screen space and mess up the layout.
How this works, I will let Jim Vitek from AppKey explain.
I tried to make a wrapper for the AppKey SDK, but found that it would take too much of my time to learn how to make it – Time that I do not have, as I am busy maintaining my 60+ apps while working on new apps.
So I contacted AppKey and asked them, if they would be interested in making the wrapper for me and they agreed.
Within a few days, they had the wrapper ready, and we started testing. During this testing, they have proven to be very helpful.
I am now running one of my smaller apps with AppKey and can already see the potential. So the next step is to try one of my bigger apps, which I am already working on.

I have asked Jim Vitek to come to the forum and explain what AppKey is all about and to answer questions.

I can only recommend that you try it out.

Kind regards
Jakob

AppKey Home Page - AppKey

 

[vitek]

AppKey Introduction & Integration Instructions

Thanks Jakob! It’s been great working with you to get the AppKey wrapper live, and we are eager to start working with other developers to monetize more B4A apps.

AppKey is a new and unique monetization platform specifically designed for Android. It is an android appwidget that displays location-based advertising on the users homescreen. Users who opt-in to the AppKey widget on their home screen receive full paid versions of AppKey network apps at no cost, and app developers earn a share of the revenue. AppKey is the first to combine the hyper-local potential of home screen advertising with the user incentive of free apps.

AppKey is a compliment to the freemium model. The suggested implementation is to keep both free & paid versions of an app in the market, and to integrate the AppKey SDK into the free version so it can unlock the ‘paid’ functionality for AppKey users. This allows you to keep all the revenue from the users who are willing to pay, and monetize users who opt-in to AppKey at a higher level than traditional in-app ads allow. The widget earns more impressions than typical in-app ads because it is typically on the home screen 24x7. Also, because the home screen is seen while the user is mobile (more so than in-app ads), it is a natural fit for location based advertising. We have partnered with several providers of CPA deals and serve them hyper-locally when available, and use typical banners as filler when they are not. Early users have been surprised at our ads (primarily in the U.S.) because they actually save them money.

And last, but not least, AppKey is naturally compliant with the new Google Play policies because it is 100% opt-in. A user cannot get AppKey unless they put it on the homescreen themselves... and that is where developers come in to play.... Apps are the incentive to opt-in to AppKey, so you will earn an install bonus if you convince the user to install it, and a residual share of the revenue it generates as your app is used.

More information and a helpful introductory video is available on AppKey.com. We’re happy to field questions here in the B4A forums for anything that is not clear.

Now for instructions on how to integrate B4A. Integration is different from most other ad networks because AppKey does not use in-app ads. The technical integration should be familiar to anyone who has integrated with the android Licensing Library before (http://www.b4x.com/forum/basic4andr...ur-android-application-licensing-library.html)

How to try AppKey without signing up for anything:
1. Copy the following files to your b4a 'additional libraries' folder (all files are in AppKeyB4A.zip)
- AppKeyB4ALib.jar - The b4a wrapper library
- AppKeyB4ALib.xml - The doclet that provides a description of the library in b4a format
- AppKeySdk-0.0.1.jar - The AppKey SDK itself (from the AppKey.com developer page). This is referenced from within the b4a wrapper so it does not need to be selected in the b4a libraries tab.
2. Load the HelloAppKey.b4a project
3. Run, and look for the sample output in the Log.
Try running HelloAppKey when AppKey is not installed, installed but not running, and when it is running. Note the different messages.

How to integrate AppKey into your app:
1. Visit AppKey and register for an account.
2. Click Add an App and fill out the details for your app. Note the App ID.
3. Copy the following files to your b4a 'additional libraries' folder (all files are in AppKeyB4A.zip)
- AppKeyB4ALib.jar - The b4a wrapper library
- AppKeyB4ALib.xml - The doclet that provides a description of the library in b4a format
- AppKeySdk-0.0.1.jar - The AppKey SDK itself (from the AppKey.com developer page). This is referenced from within the b4a wrapper so it does not need to be selected in the b4a libraries tab.
4. Follow the HelloAppKey example to Dim and Initialize AppKey. Remember to replace the 12345 with the App ID you received when adding your app on AppKey.com.
5. Add the call to CheckAppKey, and note the various Reason codes documented in the popup help of this function.
6. Add ak_Allow method. Include code that unlocks premium functionality for the user.
7. Add ak_DontAllow method. Include messaging to the user for the various Reasons from the .CheckAppKey help.

In the future we may provide some sample user messaging for the various Reason codes. The intent is to motivate the user to install AppKey so you can monetize them. The messaging should make sense in the conext of your app. If you have a game where the premium version has 20 extra levels, tell the user they can get 20 extra levels if they install AppKey.

It is important to note that neither the SDK nor wrapper require any extra permissions.

Please ask questions here so the answers are available for all. We sincerely appreciate your interest and look forward to serving the B4A community.

Jim Vitek

 

[susu]

Hi Jim,

Your network is very impressive. But my users are mostly in Southeast Asian, is there a chance to use your service? How about the performance?
Thank you.

 

[vitek]

Thanks susu. Our focus to date has been on the U.S. We do have partnerships with several sources of ad inventory, and already have the potential to enable Southeast Asia with banner ads on the widget as a start. The revenue from these is likely to be lower than markets where we already offer hyperlocal targeted ads, but you would still receive the benefit of the additional impressions the home screen offers.

Regarding the performance... we are in beta, and do not have a statistically significant sample to report on yet. We're not going to play the eCPM game of claiming numbers we cannot back, and I would argue that what developers should be talking about is revenue per user anyway. What I would suggest is that you mock GPS for locations where your users are (include some major US cities) and try AppKey. We're currently using the passive location provider for battery efficiency, so tickle the GPS with something like foursquare after each location change. If the ad inventory looks like it would be good for your users then test it in one of your apps.

 

[Roger Garstang]

This sounds like a much better model and ads aren't in the way. You need to contact places like GasBuddy and Angry Birds/Rovio as their ads are the most annoying and in the way out of all my apps. I did have a few questions:

1. Is the ad required to be on the main home screen, or can users tuck it away on some distant page they never look at? On my devices I often have just a one page home screen to conserve resources and it is full of only apps I use. I either delete the other pages or leave them empty. If empty I could see how a user could just use it to hide away things like this on a page they never go to.

2. What about other Launchers? Are they supported? Are they tracked? What about possibilities of hiding the widget or sizing it very small, to non standard or clipped sizes, or to 0 in other launchers or even newer Android Launchers? They may even tuck it away in a folder or something if capabilities are there.

3. How does the tracking work? I assume when a full app linked to it runs it checks that the widget is on the home screen and probably sends something saying it is running so that developer gets a share. Does it post/update usage throughout the app cycle so if App A runs for 2 hours and App B runs for 5 min then App A gets a bigger share? Does the widget itself keep track of how long it is active (And perhaps how long it is visible to the user) so someone won't just plop it on their Home Page before running the app then remove it after or if it is never on the screen [See #1 above]? How is the bandwidth usage for all of this for users with limited data plans concerned with it using their data too much?

 

[canalrun]

Thanks susu. Our focus to date has been on the U.S. ...

An interesting idea, but I have to ask how users feel about an Advertising Widget being installed on their homepage while downloading an App.

I know if I downloaded an App and it installed advertising on my homepage, I would be angrier than a wet cat. I would never visit that developer again.

It is similar to these browser "toolbars" that vendors used to install with programs downloaded to Windows - what a pain that was.

How do users feel about Advertising Widgets?
Is it obvious and trivial to get rid of the Widget entirely?

Barry.

 

[Roger Garstang]

It is similar to these browser "toolbars" that vendors used to install with programs downloaded to Windows - what a pain that was.

How do users feel about Advertising Widgets?
Is it obvious and trivial to get rid of the Widget entirely?

Barry.

Used to? Shoot, Everything I install lately wants to add the stupid Ask Toolbar or Yahoo Toolbars. Some even want to install their own anti-virus or other utilities. I hate any of those toolbars. Most of my Anti-Virus apps (The good ones- Not Symantec or other garbage) detect them as unwanted apps and strip them from the installs when they extract. I can't stand the Yahoo Toolbar- It has all kinds of issues, crashing, and even causes many things not to work.

From a user perspective I think I could be ok with it depending on the answers to my above questions. It sounds like it is one shared advertising medium used by multiple apps which is better than every app I use having their own ads taking up space and often running in the background anyway even when the app is closed.

 

[MaxApps]

The AppKey is not installed with your app.
Your app checks if AppKey is present and running. The user has to choose to download AppKey from the marked.

My 1st app, with AppKey. shows Banner ads and push ads, if AppKey is not running.
At startup, my apps shows a screen, that explains the advantages of having AppKey, On that screen there is also a button that links to marked and a "No thank´s" button.
If AppKey is running, my app starts up without ads and with an extra feature, that only users with AppKey will get.

This way the user can get rid of the ads, get extra features if they get the AppKey or if they do not want to have it, they can still use the app, but with ads. either way I get paid

Kind regards
Jakob
MaxApps

 

[vitek]

Many good questions. I’ll address them one by one:

- How do we detect if the widget is installed on the main home screen vs. other pages?
We don’t & can’t because android doesn’t allow it. This is a common request of the android team, but they haven’t acted on it yet. We deal with this limitation with a timeout on the ‘key’. If the user doesn’t interact with the widget within the timeout period, the key will turn red, and the widget will no longer unlock their apps. This is why the ‘red key’ state is passed as a reason code in the DontAllow sub. The apps are the incentive to opt-in to AppKey, and apps are also the reminder to look at it periodically. The idea is that users will eventually get the hint and place it on their primary home screen. We have some other ideas as well, but haven’t tested them yet.

- Does it work with other launchers
We have tested the major ones: Pure android (nexus), Samsung Touchwiz, Motoblur, & HTC Sense. Technically, AppKey is a standard AppWidget that should work in any launcher that implements AppWidgetHost An example of a launcher that cannot support AppKey is Kindle Fire (because it does not implement AppWidgetHost). I realize there are a number of alternatives out there & would appreciate any bug reports if you find it doesn’t work on some of them.

- How does tracking work? How efficient is it on bandwidth?
We currently count uses, not usage duration. Referencing the HelloAppKey sample app... the App ID is passed to the AppKey SDK in the .Initialize method, and the SDK passes it to the AppKey service when the .Check4AppKey method is called. AppKey stores the AppId locally on the device until it detects that 1. It’s been a few hours since uploading data, and 2. the charger is connected. We do this to conserve battery. In fact, the whole application has been designed to be very power efficient because we know users will uninstall it if we degrade phone performance. You (the developer) can choose to call .Check4AppKey as often as you want, but we discard calls that more frequent than once per 30 minutes.
Since revenue generation is disconnected from app usage in this model, we needed a fair way of determining the share of revenue each app earns. We do this by summing the gross revenue earned on each phone for the month (less a % to fund the install incentive & cover AppKey costs), sum the number of launches for each app, and distribute the revenue proportionate to usage of AppKey-enabled apps on that phone. Repeat for all other phones.
The key message here is that we’re pursuing home screen advertising, and using a formula that we believe will share revenue in the fairest way possible. If we discover a more fair way to do it in the future, we will adapt. Sharing based on duration is certainly something we’re considering, but we haven’t gone there yet.

- How will users react?
First, the widget does not auto install. The reasons are both technical & user satisfaction. Technically it is not possible without hacking android. Beyond that, nobody likes it when apps spam your desktop with a unauthorized toolbars, ads, shortcuts, etc. Was it really a surprise to anyone that Google started cracking down on this behavior? Any and all AppKey users have to download the widget from Google Play & manually place it on their home screen. For this to happen, users need to be aware of AppKey AND be motivated to install it. This is where apps come in. Apps are the incentive to install AppKey and to keep it installed.
Opt-out is as simple as dragging the widget to the trash. Easy, done... and then the users apps start asking for money again. Hey... you deserve to get paid for your app.
Regarding user reaction, so far it has been good. It is worth noting that AppKey is not for everyone. Any users who have a problem with AppKey can go pay for the premium version, and ~1% typically do. AppKey is targeted at the other 99% of users who don’t pay. If they don’t care about your premium functionality, they can use the totally free version (with ads & functional limitations). However if they want the premium functionality and don’t/won’t/can’t pay, then you can offer them AppKey as an option. I recommend you check out Jakob’s MaxMoney2 app as an example of how this works. AppKey can be a part of your monetization strategy. It is not an entire strategy in itself.
Additionally, the ads themselves have value. We have CPA deals with tens of thousands of local merchants (in just the US for now) via our providers. Install AppKey and try it for yourself. Use it for a discount on lunch. Many people have and they like it. These ads don't suck

- Angry Birds... For obvious reasons I can’t comment on conversations we’ve had (or not had) with major publishers. I can say that we think there is a tremendous opportunity in the long tail of android apps. The usage-based revenue sharing model was designed to enable fair sharing of revenue between blockbusters and smaller apps with a few thousand downloads. We think it is so critical to the success of home screen monetization that we filed for patent protection on it. (sorry if that offends anyone... strictly business) Think about it... how would smaller developers be able to compete with blockbuster apps for home screen monetization without a fair way to share that valuable space?

Jim

 

[NJDude]

Interesting service, however, the "dashboard" doesn't include an option to remove an app or apps or to close you account, other services do that.

 

[vitek]

NJDude, send us an email from the account you want removed and we'll take care of it. - jim[at]appkey[dot]com

 

[MaxApps]

Hi Jim

Its nice to see, that I am starting to get some number$

Kind regards
Jakob

 

[PaulR]

This looks very interesting, especially hearing about the added value to the user of the ads... eg the locally targetted ads with discounts. Sounds like a win/win/win for devs/users/advertisers to me.

One question....

If somebody installs an app and then chooses AppKey, assuming that the app is the only AppKey enabled one on the device, is AppKey uninstalled when the app is uninstalled?

 

[vitek]

Thanks Paul

>> If somebody installs an app and then chooses AppKey, assuming that the app is the only AppKey enabled one on the device, is AppKey uninstalled when the app is uninstalled?

No. AppKey remains on the device until the user uninstalls it. Because the installation of AppKey is a separate user action, the uninstall also requires a separate user action.

The separate install certainly makes it harder for the app to motivate the user to install AppKey, but there are benefits to this approach. The biggest benefit being that you can* continue to earn revenue even after your app has been uninstalled. This scenario would only happen if there were no other AppKey apps used on the device, and the user continues using AppKey and clicking on ads and/or purchasing the deals shown. I want to qualify this claim very carefully, because if your app is no longer used, and other AppKey apps are, the other app(s) will earn the revenue and yours would not. It's the fairest way we could think of to do it.

 

[MaxApps]

Hi

Have anyone tried this (other than me)?

Kind regards
Jakob

 

[hanyelmehy]

did this lib work with new sdk1.3 version
also what is the payment model (for non us ,apply for all over the world specially for middel east)

 

[vitek]

Not yet. The sdk v1.3 was recently released and we haven't updated the lib yet. We'll do that and repost shortly.

Regarding the payment model... we work primarily on a rev-share basis. AppKey earns revenue via mobile (global) & brick-and-mortar ads (US only for now) shown on the homescreen and in our app. This revenue is passed through to developers that earn the install and help retain the user. If just one AppKey-enabled app is used on the phone, the developer earns the entire rev-share. If more than one are used, the revenue is split based on the measured usage of each app. So user behavior is what determines the rev-share.

We are also testing PPD & CPI models for apps that are a good fit for those. Eligibility is on a case by case basis.

Jim

 

[hanyelmehy]

thank you for your answer
what about non us for PPD Model