.app/ads brings ad-space management to a new place. They take on "banner burnout", the phenomenon when users stop paying attention to the ad portion of the app straight on. Evan Rifkin, co-founder and CEO of .app/ads, spent time chatting with me this morning, explaining what makes his service stand out from the rest. "We're creating a better experience for the end-user," he said. "We're not replacing, not competing with the other ad services. Instead, what we're selling is power and flexibility to let application developers manage the ad experience they're presenting to their users."
With .app/ads, developers control what campaigns they present to users, and how often those advertisements can appear. So if an advertisement is set with a minimum 5-minute cut-off, the developer ensures that users will not see a repeat ad within those times. But that's just a taste of what this new service offers.
Developers can target different campaigns a specific regions, and at specific times of day. That means applications can serve the highest earning ads to audiences at only those times they're likely to earn the greatest revenue. Limiting impressions means users are less likely to tune out ads through sheer, repetitive overuse.
And when ad space isn't being used for selling, .app/ads offers ways to excite users with clickable content. The service allows you to create non-revenue generated presentations offering access to twitter feeds, web sites, or complimentary media downloads. So a music app might offer links to the MTV website or a game app could offer extra avatars. Developers create this in-house content using the same API and the same screen real estate used for ads. These non-ad elements help promote the app's ad space, train the users to click, and lessen the impact of an always-on advertising push.
In addition to information links, there's another also-important feature that .app/ads facilitates: in-app purchasing. Developers can present their own click-to-buy functionality that allows them to sell no-ad versions of their apps from that same ad banner space as well as any other Apple-approved StoreKit purchases like level-unlocks or time-based subscriptions. As an example, a "Want to Turn Off Ads" banner (such as that shown to the right) can link directly to a StoreKit purchase routine that allows users to eliminate the ad block from the interface.
"What we provide is the tools to let developers utilize their ad space in the most effective way possible," said Rifkin. "And we do so in a way that provides the greatest flexibility. Developers can pick and choose which ad networks they want to use, without having to add a half-dozen SDKs into their applications. Right now there's, what, six or ten different SDKs out there? Imagine what happens when there are 30?" The .app/ads service acts a middleman between iPhone applications and the various advertising networks. With the Open App SDK platform, developers can compile in a single SDK while retaining access to each of the available networks by selecting which libraries they want to use -- or they can choose from a pre-compiled selection of the most popular ad network combinations.
So how will .app/ads earn their money and stay in business? Like most ad networks, they will be targeting advertisers as well as developers, offering a centralized sales service. Advertisers, like developers, will have access to tools allowing to control how their campaign is controlled over time and location, and so forth
They also will offer a developer-to-developer marketplace allowing targeted campaigns in specific applications, taking a 10% transaction fee from those arrangements. Companies and persons placing ads can pay by impressions (CPM, or per thousand impressions), by clicks (CPC, per click), and by a novel system of payments per installation (CPA, per acquisition).
The cost per acquisition option is innovative, and is powered by their web service and SDK. The .app/ads system tracks all clicks on sales advertisements and attempts to match them against user registrations whenever an app is launched for the first time.
This matching is provided by an anonymous tagging system, according to Software Engineer Aaron "drunknbass" Alexander. (Alexander participated in a recent TUAW live chat about iPhone application development.) When a registered advertising click matches the device tag for a new launch, the developer is credited with a CPA. This technology allows .app/ads to sell verified ad-generated application installs through its marketplace as a product. (TapJoy's similar-sounding pay per install system offers advertisers the option to buy incentivized installs through a virtual currency offering, according to Rifkin.)
I spent some time this morning looking through their website tools for developers. (The advertiser portion of the website has not yet gone live.) On a surface level, it feels very much like existing ad service sites (like Admob) on steroids. Developers have a lot more options, a lot more controls, and a lot more feedback. The Marketplace is, understandably, empty as the service has not really gone live yet. Although the screens are a little intimidating (a screen shot appears at the top of this post), I can easily see myself using this kind of system to add ads to my already advertising-supported applications like MakeItMine. (And on a personal level, let me thank everyone who does click on the ads in that app. You're helping my kids have access to summer camp! Seriously.)
The .app/ads service will be in public Beta for the next few months until they officially launch early next year. I was impressed by the amount of thought that has gone into their service to take the needs of all three parties -- advertiser, developer, and end user -- into account. Their service is adding something new into the iPhone arena. The space that developers devote to advertising can move beyond a single, constant banner and the "banner fatigue" that goes along with it. With content links, in-app upsells, and flexible rule-based campaign control, the new .app/ads option looks like something to keep an eye on.