SV Android Developer Meetup Notes - AdMob and Flurry

I went to the Silicon Valley Google Android Developers meetup last Wednesday, not so much for Android development (although I did get a trivial hello app running on the phone simulator on my laptop during the start of the meeting), but for the 2 speakers. I was spurred somewhat by the minor Pinch Media privacy controversy.

Assume any errors are mine in scribing, rather than in the speakers' content. Sean Galligan, VP Biz Dev for mobile analytics company Flurry, spoke about their service:

• iPhone is #1 - In terms of analytics events gathered in their system, Android is (a distant) #2 behind iPhone. Depending on the analytic category, iPhone is 64 to 87% of the data, while Android phones are 7 to 22%. J2ME based phones are 3rd. Blackberry is currently bumping around 0%, but their app market just launched. This is ultimately representative of Flurry's community, rather than the complete mobile application market on these platforms.
• Utilization - higher than they forecast. 18 to 51% utilization across all app categories, rather than Flurry's expected 10-15%. Games are around 30%.
• Average Session Length, in minutes, for iPhone games

Days Mins (Paid/Free)

10 3/6

30 4/3

60 6/1

90 3/1

i.e. after 10 days, the average paid app is used for 3 minutes, and the free app is used for 6. If you graph it, the patterns for free and paid apps are basically inverse, i.e. free usage starts high and steadily drops in, while paid starts lower and grows. The same pattern is there for the metric of number of sessions/day.

• App Lifecycle - based on utilization, the basic application "lifecycle" seems to be about 3 months
• Effect of Cross Sellling - a correlation exists of improved sales in both apps when cross selling one app within another and vice-versa
• Freemium Model - Flurry believes that offering a free version increases paid app sales substantially, i.e. there's a fairly linear graph of paid app sales that starts higher on the left and steadily decreases towards the right, but offering the free version leads to a dramatic (85%?) increase in sales around the middle of the paid app's lifecycle, where sales start trending back upwards instead of continuing down. You can use analytics to find the optimal up-sell message placement, i.e point where user drop-off accelerates. A lot of people upsell too late in usage cycle of the free app, i.e. they wait for the user to use their free version too many times before offering the paid version.
• Platform Support - Java, iPhone, Android & BBerry. Purported easy to install "2 lines of code". Agent library is 130k on iPhone. 6-8k in other platforms
• Pricing - No current cost for developer integration. They're investing in building the community.
• Categories in Metrics Package - demographics, usage, performance. Includes frequency, conversion & loyalty metrics. Can do user path analytics (similar to "click streams" in Web analytics). You define trackable events, e.g. how user navigated thru app. Flurry doesn't know CPU or memory load of the system when the app is running.
• No Flurry API Yet - How does a developer pull their metrics over to their own tools? Its all exportable, but no API yet.
• Omniture Support - In process of executing partnership w/Omniture to integrate with SiteCatalyst Web metrics tool
• Bandwidth Use - Their library makes a call to the Flurry server every time the user opens your app. Flurry transmits data about that new session as well as the previous session. This scheme is due to the fact that many people don't logout gracefully, as well as the fact of intermittent network connectivity. They store data on phone in between transmissions. Transmission is approximately 1k (compressed).
• Privacy - UDID and PII - I asked specifically about PII, using UDID as an example. "We are not gathering private information about individuals".
• Privacy - Sale of PII - Would Flurry try to sell the data? "We'll never share individual pubisher data unaggregated"
• Privacy - Logs - You have access to the actual log data for events. You can see each session for user, w/out identifying the user. I need to reconcile this with my other note re tech support use, "can we grab data re a particular user b/c they're having trouble? yes". I can imagine a way such a system could work without recording PII, but for the moment I'll leave that as something to look at when I start testing Flurry. It should be straightforward to run some test sessions and then see what data Flurry records over on the server log.

That aside, this seems like a service worth looking into. Good presenter. No fluff. The second speaker was Mike Fyall, who runs product marketing for mobile advertising company AdMob. This was less directly interesting, since I don't see putting banner ads in the app I'm currently working on. Nonetheless, in presenting to Android developers regarding what has so far been an iPhone-centric product, it presented a useful take on the iPhone world:

• iPhone apps run 50% of AdMob's total presented ads - this is 8x the number of Android-placed ads. On the other hand, there are 8-10x as many iPhones, so the number of ads served is roughly equivalent per phone on both platforms. This suggests to AdMob that there is similiar ad usage across different types of touch devices
• Use In Free Apps - Most AdMob clients are using the service within free apps
• Revenue Example

CPM -> CTR -> #clicks -> CPC -> eCPM
1000 -> 1.5% -> 15 -> $0.10 -> $1.50

For a thousand ad impressions (CPM) with a Click-Through Rate (CTR) of 1.5%, that means there were 15 clicks, at a Cost Per Click (CPC) of 10 cents. That's an Effective CPM of $1.50 in ad revenue for those 1000 ads, which is split 60-40 between developer and AdMob. The bid market somehow determines CPC.

Continuing the example, this time re advertising value per customer:

Given 20 sessions of use of the app, in which you show 5 ads per session, that's 100 ads per user. Given the above-calculated $1.50 eCPM, that's a $0.15 avg value per customer over the life of the app. The "value per customer" calculation also might include the opportunity to upsell the customer under a freemium model, i.e. convert them from a user of the free, ad-supported app to a purchaser of the paid version of the app. Assuming a 5% conversion rate from free to paid, at a price of $2.99 price for the paid app. That comes out to just under $0.15 per customer on average. So the combined value per customer from both ads and freemium upsell would be $0.15 + 0.15 = $0.30/user. So if you have only 1M users, that's $300k :)

My note - this formula ignores the nuance of the combined value in a case where the paid version does not show ads, i.e. ad revenue portion would be lower, b/c some portion of the free app's ad-serving lifecycle would be cut short.

Ads make sense for:

• an app with a large user base or heavy repeat usage
• freemium model described above
• cases where a purely free app makes more sense than paid

Recommendations:

• place ads @ natural tranistion points, e.g. when content is loading
• use an ad background that sets the ad apart from the rest of the app

Context-Based Ads - can AdMob do Google-style context-based ads, a la Gmail, Facebook, e.g. to males 18-34. AdMob is accepting that type of data, but is not offering targeted ads yet.

Reselling Ads - AdMob doesn't run an adserver, i.e. enable you to resell AMob ads. Fyall was also a good, fluff-less rep for his company.