Hey guys… just want to jump in here and bulk answer some of the questions from the past couple of days including @adforandroidapps and @Steve.
Regarding what makes TapContext unique: There’s one huge thing that makes us unique, and several smaller things that (we think) make us better. Our huge difference is that we are contextual. Our patent-pending contextual ads are shown in response to either a user action or a device state. These ads are much more relevant to the user. And, by extension, enjoy a significantly higher rate of engagement.
For example, imagine you’ve created an awesome tower defense game. With a traditional ad network you place a “run of network” ad that can show up in virtually any other app at any time. On the one hand, you can get a boatload of impressions. On the other hand, those impressions are very (very) inefficient. And it ends up not being a good way to distribute your app. And the more specific (or niched) your app is, the worse the traditional ad networks are.
But what if you only showed your ad to users who already have “Radiant Defense” (my personal favorite) installed? Or maybe they just installed (or uninstalled) “Robo Defense”? The quality of your ad goes up significantly, even if the volume of your impressions goes down significantly.
I know that most of the developers here are more interested in the revenue side than the distribution side of TapContext. But the advantage is the same to developers who embed our patent-pending SDK. Higher ad engagement = higher revenue. It should also lead to a more positive user experience with more relevant ads (and that’s definitely something that we’re still trying to balance and improve).
Smaller things that are cool, but complimentary, are our “live” ads that embed real functionality in the ad distribution. Think of it as a lite-lite version of specific functionality. That same functionality creates very interesting and unique ways that you, as a developer, can integrate with our SDK to drive even higher engagement.
We also have some features that, while not unique amongst ad networks, are beneficial. For example, the fact that you can use TapContext completely without sacrificing any UI real estate is an advantage over purely traditional display ads. That also helps when you have a low-engagement app (think flashlight app, for example) where traditional display ads simply won’t work. TapContext uses the operating context of the device itself as your engagement mechanism. For low-engagement apps (which are the vast majority of apps), this is a huge plus. You get reach and coverage without requiring the user to be actively engaged with your app.
Keep in mind that we’re still very young as a network. There are still a lot of features and partnerships we’re working on to improve the experience for developers (you), users, and advertisers. For example, we’re working on traditional IAB display ads for the next version. Even though they don’t get the engagement of notification-based ads, they are an important part of the Android ad ecosystem. Other things, such as first-class support for alternate development platforms (i.e. Unity, Corona, Xamarin, Air, etc.) will expand your development options for using TapContext.
And, being young and aggressively focused on growing our developer base, we feel like we are listening to developer feedback at a higher level than the larger, more established networks. That’s just our opinion, of course. But we try hard to back that up with responsiveness and developer-driven changes to our platform.
Regarding non-market app sales: It is acceptable to use your own merchant processing or alternate payments methods (movend.com was an example given earlier) as long as your app is not distributed through Google Play. If you distribute through Google Play, you must use one of their authorized payment providers (which, at the moment, is only Google Wallet). The obvious upside to non-market distribution is the flexibility in payment processing and elimination of the 30% fee. For most app publishers, however, this is more than offset by the expense of creating your own distribution channel. Typically, the Play Market is (and should be) the preferred way to go for app publishers (IMO). But that’s not to be confused with the only way to go.
It may be helpful to note, that, at the moment, any of our advertisers that currently promote out-of-market distribution must also have an in-market alternative. This is because requiring an in-market product goes a long way towards weeding out potential scams and bad apples (although it’s neither foolproof nor the only vetting process we have).
Also, as @Steve mentioned earlier in this discussion, if you watch other ad networks such as AirPush or Leadbolt (and many others), you’ll see the same type of out-of-market apps being advertised. It’s not an uncommon practice. I think TapContext makes you, the developer, more aware of it because the ad is preceded by something like a threat scan. But the concept and ultimate ad behavior is similar to what you’ll find on other networks. It’s just initiated in a different and unique way.
Regarding RPMD: It does, indeed, take a bit of time for some of your metrics to “season” and stabilize. For example, based on our internal numbers, we know that there are times of day and days of the week where users tend to install more apps than others. Given the contextual nature of TapContext, that means your users might not see a scan ad, for example, until they’ve had your app installed for several days.
This is natural. Because of how we trigger ads (in response to user actions and device state), it takes a little longer for your metrics to mature compared to traditional networks. In contrast, you’ll likely also find that the “tail” of TapContext is significantly stronger than traditional ad networks.
Also, it should be noted that RPMD can vary greatly from app to app depending on demographics, geographies, how long your app stays installed, which features you’ve enabled in TapContext, how you integrate interstitials, etc. Like any ad network, we see some apps and publishers with very high RPMD, and some with very low RPMD. There are a lot of factors involved. And that also means that TapContext may not be a perfect fit for every app.
I would suggest 3 things… One, give TapContext some time to season and mature in your app (i.e. don’t integrate it and ditch it 48 hours later). Let it run until your RPMD (or whatever metric you want to focus on) stabilizes. Two, compare it to what you can get with other networks. Of course, make sure you’re comparing apples to apples. Compare it to what you actually get with other networks. Three, choose whichever network is best for your app. If that’s TapContext, then awesome. If that’s Leadbolt, then awesome. And so on. Whichever network works best for your app is the network you should choose.
If you find that TapContext is not performing as well for your user base and app as it is for other apps, and you have ideas on how we can improve, please let us know. We’re very focused on what makes TapContext great. We also know we can’t be everything to everyone. And, at the same time, if we can help you improve your earnings and it fits with our vision, we’d love to get to your feedback and see if we can improve our performance for you.
I think this answers what I’ve seen here since my last reply. As always, thanks for your feedback. It’s appreciated, and it definitely helps improve TapContext for everyone. Please keep it coming.