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.

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.

Apple’s latest Program License Agreement for iOS contains an interesting clause on data collection for the purposes of advertising – with user consent, collecting certain bits of data are permitted, as long as they’re sent to

an independent advertising service provider whose primary business is serving mobile ads (for example, an advertising service provider owned by or affiliated with a developer or distributor of mobile devices, mobile operating systems or development environments other than Apple would not qualify as independent)

This has been widely interpreted as an anti-Google clause. However, it has wider consequences.

Data collection is a requirement of advertising – it’s mighty hard to run an ad network without tracking clicks on your ad units. Because of this, any iOS-based advertising service will have little value to any acquirer whose primary business isn’t ‘serving mobile ads’ – since Apple could enforce its license agreement and shut the service off at any moment. Participating in the iOS ecosystem therefore comes with an involuntary poison pill – any acquisition (and corresponding loss of independence) makes the acquired asset inherently less valuable.

This new language makes the iOS platform less attractive to venture capitalists – less potential acquirers for a company equals less acquisitions at lower valuations. This lack-of-attractiveness won’t just be confined to advertising-related startups – for all startups raising money, ‘Apple changing the terms of service to make us less valuable’ is now a substantial risk factor. I therefore expect less venture capital to go to the platform in the future. Which is a problem for startups – but it’s also a problem for Apple. For ecosystems like iOS, venture capital is free research & development, outsourced innovation. Less of this on iOS will gradually make their ecosystem weaker – and in what’s shaping up to be a long war with Google, that’ll end up being a lot more significant than depriving Google of a few advertising dollars.

Blippy, a service that lets you share your purchases with others, was just called out by Mashable for exposing its users’ credit card numbers to a search engine. Since Mashable is widely-read, I start hearing from all over that Blippy released all of its users’ credit card numbers to the world, and since that’s a pretty epic failure, I go to check it out.

I’ve never used Blippy, but after two minutes of digging, it’s obvious that the story’s completely overblown. Every credit card number indexed by Google was in a paragraph beginning with “The purchase appears on your statement as:”, followed by the actual text of the line entry from the statement. It looks like Blippy has a feature that lets you automatically import your credit card statements, but didn’t realize that in rare cases, certain banks put the full credit card number in the description of the transaction. The vast majority of Blippy users have nothing to worry about – this is an unfortunate and embarrassing corner case, which a little regex could’ve caught, but it’s not the ‘OMG EVERYONE’S CC # WAS LEAKED!!!1!’ disaster Mashable’s making it out to be.

Stories like this are why I hate the tech ‘press’. Like a fifty-foot toddler, all they do is stumble around, make a lot of noise, and shit all over everything. Not one in ten of them knows enough about technology to properly evaluate whatever they happen to bump into, and the traffic they drive from their sites to your startup is ephemeral and useless. It’s gotten to the point where when I read an ‘expose’ of Company X, I think ‘poor Company X – I wonder how that blogger screwed them over, and how much time they’re going to have to waste on this.’ Today, I’m feeling sorry for Blippy.

UPDATE: Blippy’s official response. Yep, I was right.

So iAd was announced, as expected. The first thing I thought of when I saw it is Xzibit saying “yo dawg, I put an app in your app so you can app while you app,” but that’s just because I read too much Reddit.

The second thing I thought is ‘damn, this is mighty similar to Medialets and some of Greystripe’s stuff.’ It’s not quite the same thing – both of those companies have a multiplatform strategy and Medialets also has an analytics product. We also don’t know anything about targeting or reporting, although of course there will be some because iAds, ultimately, is Quattro, and Quattro has targeting. In the end this will probably be good for those startups. Agencies will treat iAds like it’s the new black because it’s Apple, the iAds will get built in HTML5, and building an ad unit that can’t be used anywhere but the iPhone stinks. So these startups – or other startups – will come along and say ‘hey, run your HTML5 iAds in Android using our SDK’ and they’ll do just fine. It’ll likely impact their efforts over the short-term, though. Fine if they’ve got runway, not fine if they don’t.

The next thing I thought was ‘that Toy Story 3 ad looked like it was the normal 320×50 banner size, before it expanded.’ So, this is fine for every ad mediation system out there (think Mobclix and Burstly and AdMob’s Adwhirl) – iAds will just become another source of supply, and they can successfully and probably rightly argue that a whole bunch of ad sources plus iAds outperform iAds alone. There’s only an issue if Apple starts selling ads with a non-standard footprint – which isn’t so likely, because standard-sized ad space is already baked into a lot of existing applications.

The 60/40 revenue split is interesting – this is a perfectly normal revenue share for a high-touch ad network, but it’s higher than the 70/30 split for application sales and in-app purchases. Because of this, Apple’s going to have to deal with developers thinking that they’re gouging them (including developers who mistakenly assume the other ad networks are passing along 100%.) Other ad networks will also have some opportunity to compete on price – although premium ads at 60/40 will likely outperform remnant at 100/0, being able to claim you share more revenue than Apple has a nice psychological effect. So why 60/40? My best guess – it’s because Apple wants iAds to be big, but not so big that paid-app developers switch en masse. At 60/40, there’s a little bit of a psychological barrier to trying out advertising that wouldn’t necessarily be there at 70/30. But this is just a guess.

There’s still big unanswered questions around brand safety and ad scarcity. Having an ad framework baked into your SDK will imply to developers that everyone can get ads – after all, every developer can do everything else that’s in the SDK. However, most brand advertisers don’t want to run alongside Jiggling Asian Schoolgirls 3.0. Just because you want some awesome high-paying Nike video ads for your application doesn’t mean you’re going to get them. In addition, advertisers have budgets, and those budgets can run out, especially if you’re selling a new medium at high rates. What happens if Apple doesn’t sell enough high-quality ads for even the respectable applications? Will the impressions just be left unfilled? Will direct marketers get a chance to hawk herbal lose weight patches by the click?

The biggest loser today was unambiguously Flash. Rich media advertising is one of the biggest uses of Flash – but now agencies are going to start developing rich media ads using HTML5. ‘HTML5′ is the important part. If the ads were built with Objective-C, Adobe would shrug. But HTML5 will run everywhere there’s an HTML5-capable browser – both on other phone OSes and on desktop browsers. Desktop-focused ad servers will serve HTML-based ads just fine. Once agencies start realizing that they can either build an ad unit twice (once in HTML5, once in Flash) or just do it once in HTML5 and forget about it, Adobe risks ending up as nothing more than an HTML5 authoring tool, and then only if they move quickly.

I’m off to download the developer preview of the iPhone 4.0 SDK, to see if I can glean any more information – which I likely won’t write about, since these things are generally under NDA. But there’s my initial thoughts on the iAd portion of today’s announcement.

Andy Atherton’s recent post in AdExchanger about a futures market for advertising is interesting but flawed, primarily because of problems with the terminology.

Let’s start with forward contracts. A forward contract is just a contract for the future sale of something. Guaranteed advertising buys are forward contracts, for example. A forward contract doesn’t imply that you can go and trade that contract with anybody else – you can’t promise to buy 10MM impressions from Yahoo in March for $1.00 CPM and then sell your right to those impressions to a third-party for a $2.00 CPM. The same is true for offline advertising. When Andy writes that “Futures market buying (e.g., the TV “upfronts”) is the standard practice offline for Brand advertisers”, he should be saying that “Forward contracts are the standard practice offline for Brand advertisers.”

Now, a futures contract. A futures contract is just a standardized forward contract that’s guaranteed by a clearinghouse. So we now need to understand both standardization and clearinghouses.

First, standardization – that means that the contracts being traded are identical in every aspect, and the underlying good is a commodity. You could create a futures contract for (say) new iPhone 3G S phones with 16GB of RAM, but you couldn’t create a futures contract for ‘iPhones’ – the latter’s too vague to be a commodity. You could create a futures contract for delivery of a good on the first business day in March, but you couldn’t create one for delivery in ‘March’ – the latter’s too vague to be a standard contract term.

Next, the clearinghouse. This is a financial institution that acts to guarantee the future transaction will occur, by acting as the buyer to every seller and the seller to every buyer. The clearinghouse reduces friction in the market by eliminating the need for you to care who the particular buyer and seller is – their creditworthiness isn’t your problem, it’s the clearinghouse’s problem. (The clearinghouses themselves keep those not creditworthy from trading and mitigate their risk by collecting collateral – the ‘margin’.)

A true futures market exists when the only thing you have to care about is the price of the contract. You don’t care about the terms of the contract because they’re standard. You don’t care about the good underlying the contract because it’s a commodity – everything’s the same as everything else. You don’t care who’s selling to you and they don’t care who’se buying from them, because the clearinghouse takes care of all that. And because no one cares who the buyers and sellers are, there’s no need to take delivery of the good – you can buy the contract and then resell it.

Now that our terminology’s clear – what Andy’s arguing for sounds a whole lot less like a futures market and a whole lot more like expanding the use of forward contracts by helping publishers sell more guaranteed inventory, which is how brand advertisers and agencies traditionally have liked to buy. Which makes a lot of sense, when it’s put plainly. No need to mention futures or forwards at all.

The online advertising industry has made a lot of analogies between it and financial institutions in the past, and they’ve been useful for relaying high-level concepts quickly. But we shouldn’t overextend them to the point where the analogies break down, or try to claim we’re doing things the government highly regulates when we’re not. There’s enough regulation already without asking for more by claiming you’re selling a financial instrument.

Recently some guy got an inactive Tumblr username, ‘pitchfork’, jerked from him by Tumblr and given to Pitchfork Music. Pitchfork handled the incident with exemplary style. Nothing worth commenting on – until some other guy wrote that this was a non-story, because Tumblr reserved the right to do this in its terms of service.

Less than a year ago I would’ve been offering to fist bump that guy, because I do think that people should be responsible for (and actually read) the agreements they agree to, and that if an action’s permitted in the terms that person agreed to, that person doesn’t have a lot of cause to complain about it. However, since then I’ve learned that what I think is totally, completely irrelevant – things simply don’t work that way.

In the real world, your terms of service don’t exist. Neither does your privacy policy. Your users don’t read them and they don’t care about them. Yes, you do have to have them, in case someone particularly litigious decides to sue you, but they don’t make your website exempt from the unwritten, unarticulated, shifting set of expectations of what a user’s rights should be – and if you violate any of these expectations, the resulting PR backlash for your company can make you wish someone just up and quietly sued you instead.

The recent Google Buzz backlash is a terrific example of this in action – it wasn’t because Google did anything against anything in their terms of service or privacy policy, but because they inadvertently violated this unwritten set of community norms. I feel a bit sorry for Google, because I suspect they internally tested the hell out of Buzz before releasing it – but because Google is a bit of a ‘special’ place, very few of their own employees shared the same norms as their community of users. (Is Google even capable of successfully testing a social product internally? Are any of us?)

Ah, product design is fun sometimes.

Just read this post by Andrew Parker (who, along with his colleague Eric Friedman, has helped me out more times than I can count) about Google Buzz’s location within the GMail interface. Andrew thinks the location in the GMail interface is the thing that’ll make Google Buzz a killer feature, like GChat. I think it’s a sign that Google’s losing it’s way – that Google Buzz splash screen I ran into last night annoyed the hell out of me. But perhaps that’s because I also don’t consider GChat a killer feature – I use it, sure, but as part of Adium, my IM client of choice. In my GMail interface, GChat is always closed and never signed into.

Online or offline, products should do what they’re designed to do. GMail is an e-mail client. It does e-mail very well. But when I’m e-mailing, I don’t want to be distracted with IM, and vice versa. When I’m doing various ‘social’ things on Facebook or Twitter, I’m in another place entirely, and I don’t want e-mail or IM to interrupt my goofing off.

By adding all this interface cruft to GMail, Google’s doing it’s best to increase adoption of an unproven product – but they’re putting their existing product at risk. Don’t force me to access different functions simultaneously – if it destroys the productivity gains of the core product, I’ll just go use something else.

Apple recently published a developer tip that said applications accessing location information primarily for advertising targeting would be rejected – applications had to provide users with ‘beneficial information’. Gizmodo picked up on it, and claimed – referencing a tweet from Craig Hockenberry – that Apple would be keeping location-based advertising for itself, no doubt powered by the Quattro acquisition.

Divining the future intentions of Apple from their present external behavior reminds me of Sovietology papers from the 70s – complex theories about shifting intentions and attitudes, all based off of who was standing closest to Brezhnev on the dias at the May Day parade – but I didn’t read the same thing into this at all. While Apple’s certainly paying more attention to mobile advertising on the iPhone, that developer tip is to protect the user experience. No user should be asked to share their location without any visible benefit to them in the app – it wastes the user’s time and it gets the tinfoil hat crowd wondering what exactly sharing that location was for. Analytics providers do use location data to produce some city-level aggregated stats, but they generally stress that location shouldn’t be sent if it’s not already a natural part of the application, because of this impact on the user.

If Apple really wanted to lock down location-based mobile advertising, the tip would’ve likely been written differently – “applications using Core Location for the purposes of ad targeting will be rejected.” We’ll see how this goes, but I think the many location-based advertising startups can breathe a sigh of relief. And I suspect larger ad networks don’t have to be concerned at all – I believe their campaigns are largely targeted to the country level, and that can be done pretty reliably just from the IP address.

BRIEF UPDATE: Heh, and now TechCrunch is writing about the same issue, calling it ‘geo-spam’. Looks like it’s mountain out of a molehill time. Unless Apple’s going to block geolocation for ad targeting altogether, none of this matters much – since campaigns generally aren’t more local than a DMA (designated marketing area), any ad network with a modicum of competence and a bit of reach already knows enough about your location from your IP or your use of other applications.

A couple of days ago, the regulatory compliance firm Better Advertising announced that it had acquired the web-bug-tracking Firefox addon Ghostery. It got mentioned in a couple places but was under-discussed, given its potential importance.

Ghostery as a Firefox extension is important because it has an opt-in database of web bug usage, collected from its users. That plus users’ ability to selectively block web bugs creates interesting opportunities for community pressure – opportunities that more scorched-earth extensions like AdBlock lack. People that block all advertising are useless; people that selectively block advertising are worth monitoring closely. (I touched on this earlier here.)

Better Advertising as a company is important because it’s on the unpopular side of a popular bet – whether the government’s going to regulate online advertising or not. Most companies have been operating like they wouldn’t; it increasingly looks like it will. Should government regulation occur (I’ve called this ‘the adpocalypse‘ before, given the amount of technical effort that could be wiped out), Better Advertising’s in a great position to profit.

Together, Better Advertising+Ghostery can act as a direct conduit between the end users and the online advertising industry – connecting the acted upon and the actors. It’s a big open question which group will influence the other more, and who Better Advertising will favor – while they don’t have a business model yet, it’s likely that the advertising industry will pay their bills. But if they do it right, installing Ghostery and selectively making blocking decisions could have a direct impact on the practices of the ad industry as a whole. That’s something new.