yardley.ca

AdBlock’s acceptable ads won’t be

greg — Tue, 03 Jan 2012 16:26:03 +0000

Like Rob, I’m intrigued by AdBlock Plus’ decision to start letting some ‘acceptable’ ads go unblocked by default. This is a very decent way to make revenue – you can charge advertising companies who wish to be audited – but AdBlock Plus won’t be able to get away with it. It simply won’t be tolerated by the extension’s userbase. Why? People feel the pain of loss more sharply than the pleasure of gain. Ever released a new version of a product that simultaneously added ten wonderful new things and took away a tiny bit of little-used functionality? If you have, you know what I’m talking about.

The correct way to introduce selective ad blocking is to either release it as a completely separate, differently-branded product, or to add it to software that previously lacked ad blocking altogether. Wrap it in ‘make the Internet better’ branding, call it ‘OccupyAdvertising’ or something, and you’re good to go.

Some will argue that AdBlock Plus’ new default settings will win out, because people don’t change settings. Not so. People don’t change most settings because they don’t care about them – if the default search engine’s Bing, it stays Bing. But look at the percentage of people who futz with something they do care about, like Facebook’s obtuse privacy settings – the majority can’t set them correctly, but try to set them they do. If it’s important enough, people will change it. And what’s most important to the users of a extension called ‘AdBlock Plus’?

Setting up Kohana 3.2 on Mac OS X

greg — Mon, 21 Nov 2011 22:58:45 +0000

I’ve been doing more coding than blogging lately. My tool of choice is Kohana, a hierarchical model-view-controller PHP framework – it forces me to follow some rules, and when you’re a relative beginner like me, you need to follow some rules.

While Kohana is powerful, I’ve found it has a bit of a learning curve. The documentation isn’t as strong as it could be, and the extensive changes between 2.X, 3.0, and 3.1 make it difficult to pick up and work with existing tutorials written for older versions. The only long-form book written for Kohana, Packt’s Kohana 3.0 Beginners Guide, was published in August and (while informative) is already a couple of versions behind.

For the beginner, setting up Kohana can be frustrating. This post covers some of the ‘gotchas’ I’ve run into on Mac OS X.

After downloading the Kohana 3.2 framework, unzip it and place the contents of the unzipped folder in the directory where you plan on doing your development. I keep my projects in a ~/Development folder, each in their own directory named after the project. If I were create a project called ‘projectname’, I’d copy the contents of the unzipped kohana-3.2-master-1 folder to ~/Development/projectname.

First, enable Web Sharing from the Sharing pane of your System Preferences.app. That will activate the stock Apache web server included with Mac OS X. (Yes, you could install Apache and PHP independently from the stock versions, but unless there’s a compelling reason I’d rather work with what I’ve got.)

Next, you’ll need to tell Apache to work with PHP5 by modifying Apache’s config file. Open /private/etc/apache2/http.conf with your favorite editor and look for this line:

#LoadModule php5_module libexec/apache2/libphp5.so

Remove the # in front of it to load Apache’s PHP5 module:

LoadModule php5_module libexec/apache2/libphp5.so

While you’re editing Apache’s http.conf, you’ll want to make sure http.conf can be overridden by an .htaccess file in your Kohana directory, which will contain configuration specific to your Kohana application.

Search for the section starting with . In that section, look for the AllowOverride directive. Change this to read AllowOverride All. Now you can save and close http.conf.

You’ll need to restart Apache for these changes to take effect, which you can do with the command sudo /usr/sbin/apachectl restart.

At this point, I encountered a rather cryptic error:

/usr/sbin/apachectl: line 73: ulimit: open files: cannot modify limit: Invalid argument

Happily, someone more knowledgable than me had already solved the problem. Should you have this error, edit the /usr/sbin/apachectl script, and replace ULIMIT_MAX_FILES="ulimit -S -n `ulimit -H -n`" with ULIMIT_MAX_FILES="". You then will successfully be able to restart Apache.

Next, we need to get Mac OS X’s built in webserver to serve the contents of ~/Development/projectname. The default webserver directory on Mac OS X is /Library/WebServer/Documents. We could do this by editing Apache’s http.conf to change this default, but I prefer to create a symbolic link:

sudo ln -s ~/Development/projectname /Library/WebServer/Documents/projectname

This will make your Kohana application accessible at the http://localhost/projectname URL. However, Kohana out of the box expects your application is at webroot – that is, at the http://localhost URL.

Let’s fix this. In your projectname directory, in the file application/bootstrap.php, find this code:

Kohana::init(array( 'base_url' => '/', ));

and change it to this:

Kohana::init(array( 'base_url' => '/projectname/', ));

You’ll also want to set up your local .htaccess file. The rules in .htaccess force all URLs to be redirected to index.php/URL, allowing Kohana to do its magic. Open the example.htaccess file in your projectname directory and change the RewriteBase / line to RewriteBase /projectname/. Then save the file as .htaccess, not example.htaccess.

From this point on, you can follow the usual Kohana installation procedure – opening http://localhost/projectname, looking at the tests, and modifying the application/cache and application/logs directories to be writable with the following commands:

chmod 777 ~/Development/project-name/application/cache chmod 777 ~/Development/project-name/application/logs

And that’s it!

I apologize in advance for all errors – or missed ‘gotchas’ – which are inevitably present. If there’s something that needs correcting, leave a comment.

Viewing your iOS application usage

greg — Sat, 02 Apr 2011 17:24:55 +0000

Since the release of iOS 3.1 in September 2009, Apple’s App Store has a Genius for Apps feature, which recommends apps based on the other apps you use and just how often and how long you use them. If you backup your iOS device, Apple also syncs the database with the info Genius for Apps needs, so you too can view this information – it’s just a matter of knowing where to look and how to read it. I’ve been asked about this a few times by a few people, so I figured this post was due.

Some notes and disclaimers up front: what I’m about to describe requires a little bit of technical knowledge. (Not a lot – after all, I can do it. But it does require some.) It’s also written for Macs, since I don’t own a Windows machine. It’s also only valid at this particular point in time, since Apple isn’t shy about changing things. Finally, I don’t use Genius for Apps. If Genius for Apps is activated, the data stored or the length it’s retained could be completely different. Or it could be identical.

First, you’ll need to find the location of the MobileSync backup you’re interested in. (On my Mac, they live under the ~/Library/Application Support/MobileSync/Backup directory.) You’ll see one directory for each of the devices you’ve synced with your computer, named after each device’s UDID.

In each of these backup directories, there’s a lot of files – my most recent backup contains over 2,000! The files are all cryptically named with universally unique identifiers – long hexidecimal strings. In order to find the file containing the Genius for Apps data, you’re going to have to search for it. Pop open the Terminal, go to the directory of the backup you’re interested in, and type ‘grep daysSince1970 *’. That’ll return one match – the file we’re interested in. This works because the file we’re after uses ‘daysSince1970′ as a column name, unlike every other file in that directory.

The file you’ve identified is a sqlite database, so you’re going to need a way to read it. I’m fond of both MesaSQLite and Base, although there are countless others.

When you open the sqlite file, you’ll see a few tables. The one we want is ‘Scalars’. The Scalars table contains key-day-value triples, where the key is a string combining the type of information being tracked with the application’s ‘bundle identifier’ – information that identifies the application and company. Usually (although not always) you can identify the application from the bundle identifier.

For example, there’s a key in my database that reads ‘appLaunchCount.com.magnetismstudios.citytransit’. This means the row contains information about ‘appLaunchCount’ for the excellent City Transit application by Magnetism Studios.

The day information is stored within the ‘daysSince1970′ column – the number of days since the start of the Unix epoch. There’s lots of sites online for converting this to a comprehensible date – for instance, here. In my row about City Transit, the daysSince1970 contains the value ’15065′ – April 1st, 2011.

The value column is unitless, and you have to try and figure it out from the context given by the key. In my City Transit example, the ‘value’ is ’1′. Since the key contains the string ‘appLaunchCount’, I’m going to take a wild leap and deduce that I launched City Transit exactly once on April 1st.

A few interesting key prefixes in this file relate to app usage:

appActiveTime – likely the length of time the app’s been active. I’d been assuming this is in seconds, but that might be wrong – see appBackgroundActiveTime for details.
appBackgroundActiveTime – the length of time the app’s been running, but in the background? I’ve got a data point here with a value of 153,816 – and since there’s only 86,400 seconds in the day, I’m a bit stumped as to what the units could be. Tenths of seconds? A little testing could make this clear.
appLaunchCount – already covered, the number of times the app launched. But see ‘appActivationCount’.
appActivationCount – I suspect this is the number of times the app came out of the background. The number of times the user started the app on a day would therefore be appLaunchCount + appActivationCount.

Some quick notes on the usage data:

My sqlite database contains a month of data – older data seems to be dropped.
The sqlite database is populated whether you’re using Genius for Apps or not. I suspect this is so Genius has historical data to work from the second it’s turned on. One assumes that while the data is recorded on the phone at all times, it’s not sent to Apple unless Genius is active.
The sqlite database also contains application usage info for Apple’s internal applications, including the phone or IM apps.
While privacy advocates are extremely touchy these days, nothing particularly personal seems to be stored – for instance, this database doesn’t contain the content of your IMs or the phone numbers you’ve called. I suppose it could be an issue if you’re using any sensitive applications – but the applications themselves are already backed up elsewhere on your computer.
Since Genius can be activated directly from the phone, I’m guessing the data’s sent from the phone to Apple and only backed up to the computer.
There’s a lot more information in this file beyond app usage, but (to me) it’s relatively boring stuff like number of writes to the Flash memory. I’ve described those keys at the bottom of this post.

I have no idea whether Apple’s storing the data it receives, or just dropping it on the floor. The usage data could have a number of uses to Apple beyond the Genius for Apps feature. For instance, it could be used to offer a (very basic) analytics product to developers (unique users, session counts, and time spent), to modify how applications are ranked in the App Store, or for iAds targeting.

Although the data could change or vanish at any moment, and therefore is risky to use, it could also be used by companies outside of Apple. Opt-in market research panels – the type operated by comScore or Nielsen – could use this to estimate iOS application usage by the general population. Desktop or web apps could use it to provide better recommendations, in an attempt to out-Genius Genius. (Of course, web apps would require a browser extension or Java applet to access the file system. Some are already doing this, with user permission – mostly just to grab what applications are installed, but at least one is grabbing the usage information as well.) Developers could build tools allowing users to track their app usage over time – a RescueTime for your phone.

—–

SOMEWHAT BORING (TO ME, ANYWAY) APPENDIX: Here’s a rundown of the key prefixes in this table that don’t directly relate to app usage:

appBackupFileCount – specific to individual applications, likely the number of files from that application backed up on that day. For instance, my appBackupFileCount for Facebook is ’30′ – so I’m guessing 30 of the over 2,000 files in my Backup directory are related to Facebook.
appBackupFileSize – specific to individual applications, this seems to show the size, in bytes, of the files that the application backed up on that day.
appRegularTileCount – I believe the number of times the app shows a map tile, since this only shows for apps containing maps.
appReverseGeocodeRequestCount – again, specific to map-using applications. Reverse geocoding involves translating a latitude / longitude pair to a physical address.
appTileRequestCount – again for map-using applications, what I presume is the number of times an app requests a map tile.
com.apple.GameKit… – I don’t use Game Center much, so I doubt I have the complete data here. In a month’s worth of data, all I’ve got are a few ‘com.apple.GameKit.login.appInit’ and ‘com.apple.GameKit.invite.cancel’ keys.
com.apple.MobileBackup.fileCount – what I presume is the number of files backed up that are relevant to a particular function. For instance, I’ve got a ‘com.apple.MobileBackup.fileCount.cookies’ key that’s always set to ’4′.
com.apple.MobileBackup.fileSize – what is likely the file size of the files backed up to support particular functions. For instance, my ‘com.apple.MobileBackup.fileSize.cookies’ key has a value of ’26886′.
com.apple.NANDInfo – a whole bunch of keys relating to the phone’s memory. ‘NumFreeVirtualBlocks’, ‘NumLogicalReads’, ‘NumLogicalWrites’, ‘NumPhysicalReads’, ‘NumPhysicalWrites’, etc.
com.apple.accessibility – a few keys, indicating whether certain accessibility features (‘largefonts’, ‘whiteonblack’, etc.) are enabled.
com.apple.maps – a few keys relating to usage of map features (‘SearchRequestCount’, ‘StreetViewTileCount’).
com.apple.mobileslideshow – a couple of keys showing how many photos and videos are synced with the device.
com.apple.springboard – keys tracking disk space (both used and free), reboots, the number of third party apps, and the amount of time connected to wifi.

The Dickbar worked fine

greg — Fri, 01 Apr 2011 01:04:26 +0000

Twitter’s removed the Dickbar, the little visually-distracting bar that showed trending and sponsored topics, from its iOS client. Because of this, a lot of people are drawing a lot of incorrect conclusions about Twitter’s potential to make a buck. The argument goes something like this: “You can’t grow a mass consumer service without advertising and then add it later – your users will rebel. Twitter grew big, added the Dickbar in order to draw more attention to its sponsored tweets, and its users rebelled. Twitter can’t monetize. Twitter is screwed.”

I don’t have any hard evidence, but I suspect the opposite is true – the Dickbar performed like a champ. Why? Because Twitter said as much in their blog:

We believe there are still significant benefits to increasing awareness of what’s happening outside the home timeline. Evidence of the incredibly high usage metrics for the QuickBar support this.

‘Incredibly high usage metrics’ for an advertising product? Normally there’d be smiles all around. Now you might be a cynic, and not believe what Twitter’s telling you – but I suspect you’re wrong. Baldfaced lies about company metrics are stupid. They require a conspiracy, they hurt the morale of the honest employees who know about the lie, and in a large organization like Twitter’s, they eventually leak to the press. If Twitter says ‘incredibly high usage metrics’, there were incredibly high usage metrics.

So why remove the Dickbar? I suspect it got yanked because it interfered with a more important priority – client share. The silent majority of people, the type that internet cognoscienti consider ‘mouth-breathing buffoons‘, were using the Dickbar in droves, since it was simply reflecting their own tastes back at them. Only a small percentage of people were annoyed or offended – that tiny portion of the world that acts and thinks like we do. But that was enough to throw the Tweetdecks of the world a lifeline, at a time when Twitter would rather they drown.

Long-term control over the client experience is way more important to Twitter than short-term monetization, so the Dickbar had to go, in spite of its effectiveness and general popularity. While we’ll see Son of Dickbar eventually – filtered to match our class prejudices, naturally – Twitter needs to beat the other client companies into submission first. I doubt it’ll take that long.

Steve Blank’s bubble heresy

greg — Sun, 13 Mar 2011 15:12:08 +0000

Albert Camus once said “Every revolutionary ends up becoming either an oppressor or a heretic.” From his recent presentation at SxSW, it looks like Steve Blank’s selected the heretic route.

Lightning recap: Steve Blank codified the ‘customer development’ methodology for startups, which emphasizes iterative business model discovery during a period of low cash burn. This has become the favored methodology for bootstrappers everywhere as they seek profitability. But in his presentation yesterday, titled “New Rules for the New Bubble”, profitability is set aside.

The meat of the presentation starts on slide 118 and runs through slide 127. Here Steve writes that because we’re in a bubble, the best route to liquidity requires customer development, but with user adoption taking priority over profitability. It’s possible to engineer a financial transaction with an acquirer from the beginning by getting as much adoption as possible, focusing on visibility and PR (in other words, hype) and worrying about monetization later.

I’m a long way from Chicago, but I can still hear Jason Fried’s head exploding.

I suspect the rules have changed, and Steve’s strategy is correct, although only for a short period of time. Steve suggests in his slides that the bubble period ends in 2014, which if true makes me wonder if his advice is even actionable – it takes at least a couple of years to blow up a business into something huge, so that’s less than a year to figure out the model.

I would very much like to know why Steve thinks the bubble period is so short. I suspect the only reason we’ve got a bubble in tech is because of the Fed’s zero-interest-rate policy and pumping of money into the market through bond purchases. All that goosing of the economy has created a whole lot of money looking for higher returns, pushing up valuations as it tries to get in on the action.

This bubbly goodness goes away the second foreign investors decide they want better returns on government debt – which might not take too long, considering the rapid increase in our debt-to-GDP ratio. At that time, having a bootstrapped startup with sustainable cashflow will look pretty good – not as good as selling during a bubble, but a hell of a lot better than not selling after a bubble.

There’s no ‘organic’ on the App Store

greg — Fri, 11 Mar 2011 18:37:48 +0000

Some of the top-ranked applications on iTunes purchase application installs.

Recently Chris Dixon discovered this, and expressed interest in seeing an ‘organic’ top list with the paid application installs removed.

Privately, I’ve heard other people ask for this as well. I believe these people want the App Store’s ‘top paid’ and ‘top free’ lists to reflect what people are naturally discovering, liking, and sharing with their friends – in other words, they want the App Store to be a pure meritocracy. At least in America, that resonates with us culturally. These people assume that with a bit of filtering, this organic list could be created from what’s currently ranked on the App Store.

Unfortunately, there is no ‘organic’ in the App Store. Filter out everything that’s not there strictly by merit, and you’re left with almost nothing.

Here’s the apps that make the App Store’s top free or top paid lists:

install-purchasers – a lot of social games, but also a good many you wouldn’t suspect
apps from companies with other apps, who use them to aggressively cross-promote
already-popular brands with large audiences – for example, Facebook, Amazon, eBay, Twitter
apps with already well-known intellectual property – Smurfs, Sims, Katy Perry, MLB
apps with already significant exposure on iTunes, thanks to Apple’s editorial staff

I’m sure someone out there can find an exception, but there aren’t many of them. If you want to be in the top free or top paid list, with all of the glorious exposure that brings, you need to already have an established brand or audience, to have a marketing budget big enough to buy your way there, or be fortunate enough to appear in a hand-curated category like ‘New & Noteworthy’ or ‘Staff Favorites’. That’s it. There’s no underlying list of apps that’ve been naturally ‘discovered’ by the broader community of iOS users.

That’s not to say there’s no meritocracy in the system. However Apple selects apps to feature, I suspect it involves merit. Not every application featured by Apple rises to the top, and not every application that buys their way to prominence can stay there. But it’s that initial front-page App Store exposure that gives your app the opportunity to be judged on its merits – it’s the price of admission to the meritocracy. Without that exposure, the quality of your app doesn’t matter.

When anyone says ‘I wish I could see an organic list of top applications, instead of all this paid install stuff’, what they’re really saying is ‘I like the taste of Apple’s editorial staff.’ Which is fine – I also like the taste of Apple’s editorial staff! I wouldn’t stake my business on my app being aligned with it, though – and that’s why some applications will continue to buy installs. If they weren’t able to do so, they’d find other ways to get placement.

These apps, by the way, are anything but ‘lame‘ – I don’t care how it got up there, if an application hangs in the top free or top paid list for more than a couple of days, it means there’s a real audience for it. Right now, five of the ten top grossing applications on the US iTunes store are Facebook-style, ‘freemium’ social games – not because they paid to be there, but because there’s a whole lot of people who really enjoy playing them.

Privacy protection may do the opposite

greg — Thu, 10 Mar 2011 03:56:18 +0000

A few years back, I argued that aggressive regulation of ad targeting could actually lead to less privacy, if it forced publishers to make opt-in mandatory. Behavioral targeting could go rather quickly from something you could easily opt-out of (these days, I prefer Ghostery) to something you couldn’t avoid, if you wanted to access content.

Today I read through some of the many responses to the FTC’s “Protecting Consumer Privacy in an Era of Rapid Change” report, including the Online Publishers Association’s. I wasn’t particularly surprised to find this:

Online publishers should have the right to offer their content and services on any lawful terms that are explicitly communicated to consumers and withhold access from those who do not agree to such terms. To require otherwise would burden publishers’ First Amendment speech with free riders who enjoy the benefits of access to valuable content without providing fair value in exchange. [...]

Default rules that prevent fair value exchanges of digital content for user data could harm consumer welfare by reducing incentives for some publishers to invest in the production of content and/or creating incentives for publishers to charge or charge more for content that they would otherwise make available for free or at a lower cost.

The Online Publishers Association, of course, is the membership organization for almost every national news organization in America. If the FTC’s privacy regulations impose high enough costs on their businesses, they just might restrict access to the people who explicitly opt-in to being tracked – and if that happens, you and I are going to have to choose between less privacy or less news.

Make your product less useful

greg — Fri, 04 Mar 2011 20:35:53 +0000

Seriously. Reducing functionality could not just allow you to charge more for your product, it could make it seem more useful to your users.

I know that sounds counterintuitive, but I suspect it’s true – it’s related to a cognitive quirk of ours called the conjunction fallacy.

Here’s a product example. At the last place I worked, Flurry, we offered an analytics feature called ‘path analysis’. For any event in an application, we showed what percentage of users went to each of all the other events – or simply quit the app.

Some of our competitors offered ‘conversion funnels’ – for a multistep process, they showed what percentage of users dropped out at each step.

Conversion funnels are a subset of path analysis. I believe conversion funnels are the most useful subset of path analysis, but there’s other things you can do with the data – ‘fallout reporting’, for example, which shows the chunk of your app most likely to get a user to leave.

Imagine my surprise when multiple small competitors, in their marketing materials, started claiming that they offered conversion funnels – and Flurry didn’t. “Alright,” I’d sigh, “we just need to do a better job explaining that conversion funnels are a subset of path analysis.” So we did some of that – but other companies were still signing up paying customers on the strength of their conversion funnels, a feature users could replicate quite easily using Flurry’s free product.

Curious, no? Yet analogous results have been found in a number of experiments. In a part of this PDF (worth reading from start-to-finish), Eliezer Yudowsky describes an experiment conducted on MBA students travelling to Thailand. One group was asked what price they’d pay for terrorism insurance for their flight from Thailand to the US. Another was asked how much they’d pay for terrorism insurance for their round-trip flight. The last was asked how much they’d pay for terrorism insurance covering their entire trip, including their time on the ground.

The narrower and more-restricted the insurance coverage, the more money people were willing to pay. Coverage for only the return flight was valued at $17.19. Coverage for the entire trip, including the return flight, was only worth $7.44.

Why was the subset valued more than the whole? The conjunction fallacy. We think in narratives, and therefore find ‘a terrorist incident on my flight back to America’ a lot more compelling than ‘a terrorist incident during my trip’. That makes us willing to pay more for it.

Back to the products. I suspect that when developers see ‘conversion funnels’, they quickly think ‘yeah, I can see myself using that’, and when developers see the more general ‘path analysis’, they’re at best going to think ‘yeah, I can see myself using some of that.’ The end result – conversion funnels alone are more appealing than a product that does that and more.

Stripping the versatility out of your product and focusing only on the specific problems your users are most likely to have might make your product less powerful, but it’ll make it feel more useful – and therefore more valuable. Startups doing more with less can attack powerful, does-everything incumbents by identifying the parts of their product that are used most often – and then charging more for only that portion.

True worth

greg — Thu, 19 Aug 2010 15:36:57 +0000

At pii2010, it’s frequently argued that privacy is something that you’re increasingly going to have to pay for – and that people will, in fact, pay money to preserve their privacy. (I haven’t seen any evidence for this, but venture capitalists are investing in the space, so it must be true.) This argument is then followed by concern for the poor – since in a world where privacy is paid for, the poor won’t be able to afford it, and therefore will have to trudge along in their not-so-private dystopia. This then leads to talk of regulation and rights.

Let’s assume the cost of preserving one’s online privacy is equal to the value extracted from ‘lack of online privacy’ – by which I mean behavioral targeting for ad serving – plus a little bit more just to eke out a profit. How much money do people think that actually is? I suspect most of us assume our data is dramatically more valuable than it actually is. We’re all good narcissists with healthy egos, after all, and we just don’t want to accept that all that internet browsing we do is worth a few bucks per year at best. So ‘protecting our privacy’ by blocking most targeting, rationally priced, shouldn’t be much more than a few bucks a year – a small expense that even the American poor can afford, considering they pay several times more than that each month for their internet connections. Of course there are billions of people in this world that are poorer still, but their online privacy isn’t worth violating – if they’re even online at all. Marketers don’t target people without money.

It would be useful, and add some rationality to debates around privacy, for some advertising technology firms to estimate the true worth of a typical individual’s behavioral targeting data. With this information, we can figure out what a sensible price for protecting privacy should actually be, and stop worrying so much about whether the poor can afford it. Of course, even sensibly priced, large numbers of people aren’t going to pay for their privacy. But that’s a discussion for another time.

iAds performance – now and later

greg — Thu, 08 Jul 2010 20:49:51 +0000

The Next Web writes that an iPhone developer made $1,372 from his first day running iAds. The developer was kind enough to post the following stats from his Apple dashboard:

$1,372.20 total revenue
$147.55 eCPM
26,651 requests
9,300 impressions
34.90% fill rate
11.80% CTR

From this we can glean quite a bit.

First, note that Apple’s using a rather favorable calculation of ‘eCPM’, basing it on impressions actually served, not ad requests made. Given that 17,351 requests (65.90% of the total) resulted in no ad shown, I’d say the actual eCPM should be $51.49, not $147.55. That’s still impressive.

Second, these numbers are consistent with a 60% revenue share to the developer and a $10.00 CPM + $2.00 CPC cost to the advertiser. 9,300 impressions x 11.80% CTR = 1,097 clicks = $2,194 in CPC charges to the advertiser. 9,300 impressions x $10.00 CPM = $93 in CPM charges to the advertiser. $2,194 + $93 = $2,287 gross. $2,287 x 60% to the developer = the reported $1,372.20. Apple’s charging exactly what they said they would, at least for this campaign.

Third, at >10% the clickthrough rate is freakishly high – iAds are clearly still a novelty for the userbase. If we assume the clickthrough rate drops to a still-high-but-more-standard 1.00% and also assume that pricing stays the same, that works out to an $18.00 eCPM – or, if you take the unfilled inventory into account, a $6.28 eCPM. Still pretty good for independent developers. Not so good for popular, large brands with dedicated sales teams – but excellent backfill for unsold remnant inventory, assuming you can keep it from sabatoging direct sales.

Fourth, at $6.00 CPM + $1.20 CPC to the developer, just a slight improvement in clickthrough rates drives substantial revenue. There’s going to be a lot of iAd units placed really close to the game controls in the near future. At those rates, I suspect click fraud is also going to become an issue.

Fifth, I’ve read that Apple has $60MM in sales commitments. If clickthrough rates are averaging (say) 10% at the moment, that works out to $210 in charges to the advertiser for every 1,000 impressions – $10 in CPM, $200 in CPC. Let’s round those charges down to $200 to keep things simple. At that rate that $60MM buys 300MM impressions and 30MM clicks. How long is that $60MM going to last Apple? That entirely depends on the popularity of iAds – but note that in May 2010, AdMob did 2.75B impressions in the United States on iPhones and iPod Touches, and right now about a third of all traffic is on the iAd-compatible iOS 4.0. If the much-higher-paying iAd runs as many impressions in July as AdMob did back in May, that 10% CTR will burn through the $60MM halfway through the month. No wonder fill rates are low. Keeping up with demand and getting fill rates up is going to keep Apple’s sales team busy.

My biggest takeaway from these iAd numbers? Run, don’t walk, to get iAd-supported applications in the AppStore – it’s clearly ‘put the money in your pocket while the users and advertisers are still behaving irrationally’ time, and it’s not likely to last.

UPDATE: Naturally, right after I write this I see Kenneth’s post with much lower numbers. If the pricing’s consistent, his average of $10.00 – $15.00 eCPM (let’s call it $12.50) implies about a 1.00% CTR. In addition, his fill rate’s far lower – sub-10%, which brings iAd in line with every other ad network out there. I think he’s wrong about his numbers including Apple’s 40% cut, though, since I could only make the above developer’s payout line up with Apple’s announced pricing by adding the 40% to the developer’s figures.

UPDATE 2: Thinking more about the above. The developer with the >10% CTR apparently got it from a flashlight application. If the phone is pointed away from the user in order to illuminate something, of course there’s going to be some accidental clicks on an ad unit. (And incidentally, not so great performance for the advertiser.) So I wouldn’t be surprised if CTR was artificially high, and everyone, including me, is wasting cycles over a freak outlier. But if it’s Kenneth’s CTR that’s typical, the fill rate seems freakishly low – at 1% CTR they’d only be charging the advertisers $30 for 1,000 impressions and 10 clicks, so $60MM would pay for two billion impressions and 20MM clicks, certainly enough to meet more than 10% of the demand.

A few possible explanations for low fill rate: a) the ad campaigns are tightly targeted, so 90% of the audience just isn’t eligible, b) the ad units are tightly frequency-capped, and Kenneth’s app is used much more often per-user than the flashlight, or c) the $60MM in sales includes a lot of campaigns slated to start later, and the complicated ad creative just isn’t ready yet. I’d place my money on the last option – iAds might look great, but they don’t look easy to make. If that’s the case, look for fill rate to increase slightly over time as more ad campaigns come online, but for Apple to ultimately have a lot of trouble keeping up with demand as agencies struggle with creative creation.