Got Hitched on Valentines Day

It’s official! The press release went out this morning, Metaresolver has been purchased by Millennial Media. And no, this doesn’t mean I’ll be moving to Baltimore, but I appreciate the concerns :-) I’ll be working out of the San Francisco office.

What we’ve focused on at Metaresolver is mostly different than what Millennial has been working on to date. We’ve been focused on programmatic media buying, assuming that the evolution of mobile will follow the evolution of online. And we’ve been focused on performance advertising, customers who are looking to drive a goal like an application download or a purchase.

Once we started talking to the folks at Millennial we found that those areas were really high on their priority list too. Some of them had already been started and just needed some extra gas, others need to be strategized and spun up. So initial conversations led to some pretty deep dives, and after the conversation got going it was pretty obvious where it would end up – with us signing paperwork to get hitched on Valentines Day. How sweet!

The end result should be that we get to keep executing on the vision we were originally going after, making mobile advertising more effective for both advertisers and publishers. But now we get to do it with unique access to some of the most highly desired inventory in mobile. A bunch of advertisers we were already working with were chomping at the bit to get access to the Millennial network via different mechanisms than they had available. That made a lot of sense to us. And it made a lot of sense to Millennial. When we set out to make that happen I admit we didn’t anticipate how it would end up, but I’m still going to assert we nailed it :-)

I’m sure it’ll take a while to figure out how to get everything stitched together. Most of the team is out in Baltimore currently starting off conversations about that. And once we have some of those plans I’ll probably reach back out to a bunch of people we currently have on hold. But if I miss someone and it seems like this shift should have us reconnecting please let me know!

Update: Jim Payne from MoPub posted some excellent commentary and perspective on programmatic buying in mobile on their blog.

Posted in Business, Metaresolver | Leave a comment

Swapping Ad Creative with a Proxy

Like I mentioned last time I’ve been hacking around with some richer creative styles on mobile. Nothing that should be all that amazing, but I’ve been finding the existing tools and techniques a bit rough. To do some of the base testing I started out with compiling the test programs on iOS and Android that MoPub provides in their open source SDK.

Those are awesome tools to have, but it’s pretty difficult to get folks who work on web stuff to compile test applications for mobile. And what about all the SDKs that aren’t open sourced? Recompiling apps isn’t really an option for a lot of cases.

Instead I’ve been playing around with using a node.js based HTTP proxy to test out some of the other stuff. On iOS at least it’s really easy to set the HTTP proxy for a wifi connection, and it applies to all apps. Then you just need a simple rule to swap the host and path to point to what you want to serve. I have a PHP script that works with MoPub in the MRAID testing repo I put up a little while ago. Then you just need a rule when you start hoxy to direct ad requests to your script instead:

request: if $host eq "ads.mopub.com", $host.set-to("test.com") $url.replace("/m/ad", "/serve_mraid.php")

Then instead of needing to use your test app just configure the device to point to the proxy. You can see the creative in any existing publisher property, which makes it really easy to do some screenshots for clients. And you don’t have to resort to hacky production config overrides.

Since this is running as a node.js service it’s pretty easy to just stick it on a public server. That way other folks in the office can use it, or you can even send it to people outside so they can interact with the ad instead of having to rely on screenshots. Plus it works for swapping in test creative for the cases where you don’t have access to the ad SDK code to try things out. I still need to fold some test harnesses for the other networks into the MRAID testing stuff, but that’s a project for another day.

Posted in iPhone, Metaresolver, Open Source, Software, Technology | 2 Comments

Testing Mobile Ad Creatives

So far a lot of what I’ve been using lately in terms of mobile advertising has been banners. Images. Simple to deal with, but probably not long-term a fantastic way to go. Especially for mobile, where the ads are supposed to be highly relevant and context aware. More and more advertisers are looking at how to tailor their ads to the user, or to the current location. Not a crazy idea apparently, as there was just an update to the Mobile Rich Media Ad Interface Definitions (MRAID) released a few weeks ago. Seems like a good time to figure out how to use this stuff.

However, after some digging around I found mostly stuff like this completely neglected Quora question. There’s an online MRAID tester that a few folks from Crisp put together. An awesome idea, but I really needed to see the stuff on devices. (Plus, I had trouble getting the MRAID webtester to work with any of the MRAID samples I had, so I must be doing something wrong still)

Fortunately however, the MoPub SDK has MRAID support. And it’s open source, so I figured there had to be a way to trick it into showing what I wanted instead of fetching stuff from the exchange. And as it turns out, there is. For the MRAID stuff almost trivial I would say, just injecting a few extra headers to make the SDK happy (actually fetching and delivering the ad isn’t covered by the MRAID spec). I’m sure it’s going to be almost nearly unusable by anyone except me at this point without some real hackery, but I decided to push the script up to GitHub with some instructions just in case.

Right now using it means you have to have a working dev environment for iOS and/or Android. And you have to go in and hack that script to change the creative you want to test with. And I’m not inserting all the headers correctly so that stuff like impression recording and click event reporting work correctly. Which is a pain, but in my opinion less of a pain than testing by actually flighting an ad and then figuring out if it works where you want it to. And now I can play around with expandable banners and all that jazz, so I’m happy at least. Just need to figure out how to get this stuff properly supported on our platform.

If you need to test MRAID creatives – I’ve open sourced this under the same permissive BSD license that MoPub has their stuff under, so feel free to do nearly whatever you want with it. It is in pretty pre-alpha shape though. So I don’t assure it will work, it might take some work to just get it functioning. And of course it comes with no assurances. It might crash your server, it might brick your phone, it might slap your mama and stomp into the kitchen to start smashing plates. Might. It hasn’t done any of those things for me.

I’m thinking there’s probably some nice way to package this stuff up. Like add the hostname and path to pull the creatives from as a setting in the iOS and Android versions, and then publishing it as a free app. Then anyone wanting to test MRAID doesn’t have to have dev environments setup. Then put the server side stuff together into a form easy to deploy onto a hosting service, with some nice forms for setting up the different creative styles and a way to spit out ad tags once you’re happy.

Mostly though, I’m wondering why this stuff isn’t already out there? So if I’m completely missing some kind of simple solution or testing tool, let me know.

But assuming I’m not there’s the open question of how to run these kinds of tests using the other non-opensource mobile ad SDKs. Seems like that might be something of an issue, but turns out my willingness to resort to DNS hackery might actually be paying off there. That’s a topic for another post.

Posted in Android, Business, iPhone, Metaresolver, Open Source, Software, Technology | 8 Comments

Mobile Advertising Attribution

The 500 pound gorilla in the room when it comes to most mobile advertising discussions is attribution. This is something that doesn’t really exist as a problem in the online advertising world, it’s really a quirk of models wrapped around the app store. So after harping somewhat on the need to diversify the spend going into mobile in my last post it is a bit of a reversal to talk about mobile app store models. But that spending is such a significant chunk of what happens now that it’s worth spending some time on. But I promise to get on to more expansive stuff again soon.

So what is attribution and what makes it significant in mobile? When folks talk about attribution they’re normally talking about being able to figure out which users came in as a result of which marketing campaigns. In the online world this is a trivial task. Say for example that I’m running an advertising campaign on Facebook and also doing a bunch of AdWords promotion, looking to drive folks to this blog. Normally the click URL would be just the URL of the property (http://www.thisismobility.com/blog/). If I wanted to figure out how many users I was actually seeing off each of those services and figure out which was sending me users who did more interesting things, it would be pretty trivial to do that. I would just add a parameter to the click URL I use for each, and in one case send users to http://www.thisismobility.com/blog/?source=facebook and in the other send users to http://www.thisismobility.com/blog/?source=adwords. From there website analytics takes care of the rest.

That question about where your users came from, and really then tracking the lifetime value of those users, is pretty well ingrained in most online advertising. It’s one of the primary advantages to using a “trackable medium” like online. It allows someone spending dollars online to derive a hard and fast number for what the return on investment for that dollar was.

Take that over to mobile though. This only really applies to iOS by the way, cause on Android there’s an actual Play Campaign tracking system that you can use to figure out how marketing run through the Play store is converting. So assuming I have an iOS application I would like to drive downloads for and that I would like to drive downloads using multiple sources just like in the online example. In this case it’s not as simple as just adding an extra parameter to the click URL. The click URL is the iTunes store URL. And at least in the current form there’s no simple way for me to tag a user outside of my application on iOS and figure out what that tag was inside of the application. The simplest mechanism, assuming the advertisement appears is another iOS application, is to use the device identifier to match up the click on a given piece of media with the first launch of the application. So if you’ve been wondering about what this whole kerfluffle about UDID on iOS and what the big deal about tracking is, this is really at the core. It’s not about tracking your own users and doing local analysis. It’s about paid media and being able to figure out where your spend is effective.

However lots of folks have been concerned about the use of UDID for a while and wanted to keep it out of their systems. And there are a bunch of situations under which using the UDID doesn’t work well (like driving users off the web into the app store for example). So there’s a whole industry that’s sprung up around alternative mechanisms for figuring out where a user came from when they first launch your app. It’s one of the areas that I feel really needs attention to make the environment work better. The same way that mediation layers helped publishers by providing a tool to work around the high switching cost of moving to another advertising network, I think there’s an additional layer of tooling that we could really use on the attribution side to work around similar issues in paid media. Obviously, I have a biased take on this, working on paid media.

One of the common questions is “why can’t you just use cookies?” The technology used to deliver mobile ads is effectively the web browser, why can’t you just set a cookie when someone clicks on the ad, and then check the cookie once the application has been downloaded? A system design principle called sandboxing makes that ineffective. Sandboxing means that each application, even if that application is using what’s called a web view to display some bit of content, is actually using a different store of information. So if the ad view running in Angry Birds writes a cookie, and then I try to read a cookie back out in my fart app, I can’t see the cookie that’s been set in Angry Birds. Because those applications are strongly segmented from each other, which is a fantastic idea from a security standpoint, it makes it difficult to share the information we would like to. At core all the techniques for “providing attribution information” effectively boil down to working around the sandboxing mechanism.

The first workaround is something most folks call a first-party cookie system. If you can force the cookie you want to use to live in the browser you can use the URL registration mechanism to get the information you need back into the downloaded application. The process looks something like this:

  • As the click URL in your advertisement use an intermediate like http://rowehl.com/redirect?source=admob.
  • When that URL is fetched it sets a cookie for rowehl.com that records source=admob, and then redirects to the App Store.
  • The user then downloads the app from the store and some time later runs it for the first time.
  • The application registers a URL to be handled by the app, which iOS takes care of by passing any request for that URL to the app instead of trying to load it in the browser. In this case we’ll say the URL is http://appowner.com/appapi.
  • If the application hasn’t already checked the source of the install yet it launches the browser with http://rowehl.com/getsource.
  • The browser has access to the source=admob cookie, which it uses to immediately redirect back to http://appowner.com/appapi?source=admob.
  • Because that URL is registered by the app, instead of loading the URL in the browser it gets passed as a launch event to the application.
  • The application can handle the parameter in that URL by passing it off to the analytics system and the app owner can start figuring out lifetime value per marketing channel.

The downside to this mechanism is that it can be a bit jarring in terms of user experience on first launch (the versions I’ve seen all pop up a browser, literally, so you see the app transition on screen), and it can only be used when connected. This was actually something we played around with at Chomp as well, but we were thinking about using it more for recording what the user was looking at on our web site, and then taking them to the same content in the app if they use the “download the app” button. We thought it was too ugly of a hack to use in our project. Now people have whole businesses based around the mechanism. Go figure.

The other major technique I’ve seen is fingerprinting. There are a bunch of different ways to try to find enough bits of information to make identifying a device unique, a real in-depth discussion would be enough for a whole series of posts itself. The techniques start with simple stuff like using the IP address plus simple identifiers like the language the device is set to and the exact version of OS release. And they range through using the clock drift. Obviously, how you actually generate that set of unique identifier info is hugely important to the technique, cause it puts limits on the number of devices you can actually uniquely identify. But the important assumption for the purposes of this discussion is that you can grab a bunch of info from the device, and mixed all together that info provides you with a unique identifier that’s the same for the device no matter what sandbox it gets executed in. Once you’ve picked a technique for deriving that fingerprint it’s pretty easy to setup a web service which can get/set values based on the identifier, and as long as you have network access you again have a way to move information from one sandbox to another.

There’s another minor technique in there, which works around the visibility through the app store instead of the sandboxing model. If you sign up as an iTunes affiliate you have the ability to effectively add some data into your click URLs. The affiliate program providers have special hookups to the backend systems, so as an affiliate you can actually get more detailed info that does expose how inbound clicks are mapping to spend. You don’t get exactly the info that most folks want, but at least you get something. And it really only returns somewhat useful data for paid applications, or where your target is an in-app purchase (which the affiliate program covers, which is actually really cool, though with a set window for the conversion event). But for a subset of app publishers this is close enough to “user value” information. So the hack is to sign up as an affiliate, and then use the affiliate program to wrapper your own download URLs and include marketing channel in the affiliate URL, and use the affiliate reports to figure out user value per channel. And as a side-effect, you get affiliate revenue on downloads/in-app purchases for your own app.

Of the three major techniques I’m seeing actually used on iOS:

  1. UDID/IFA exchange
  2. first-party cookie
  3. device fingerprinting

each requires some kind of presence in the advertiser application. Generally that means there’s some kind of SDK to include. And just like on the monetization side with mediation layers to abstract away networks, having something that keeps you from getting tied into one provider would be a good thing. For stuff like this it feels like an open source set of tooling would actually be most appropriate. When I’ve been on the application publisher side before we setup our own systems to track what we needed, and I’m pretty sure a bunch of that stuff could be factored into tooling that should require very little overhead to run. It seems like a lot of the big app publishers I’ve spoken to have already spotted this issue and built something on their own. Unfortunately that leaves the publishers without deep pockets somewhat stuck. Not to knock the systems themselves, the folks at Flurry, Ad-X, and HasOffers are doing awesome stuff. I just believe that any time you need to put something into an app that needs to go through the review cycle it’s in your best interest to abstract the interaction through something with server side controls. So I’m thinking about dusting off some of the stuff I’ve worked on in the past, along with a few techniques I’m pretty sure no one has caught onto yet, and trying to put together a package folks can use on their own infrastructure or spin up really simply on Heroku or something.

Posted in Browser, Business, Community, Metaresolver, Technology | 3 Comments

First Six Months of Metaresolver

We just launched Metaresolver this past week. I’ve held off on talking publicly about a lot of the decisions that went into the process, cause I was never sure when we would find some new chunk of info that would make me completely reverse my thinking. But when sitting down recently to talk through the process with my trusted friend and advisor Saad (thanks for everything Saad!) he pushed me to start blogging again about some of the things we’ve learned. Then I found myself writing a bunch of emails and discussing the same issues over lots of coffee with friends and colleagues. So it seems the time is right.

When talking with Seamus about the ideas that would become Metaresolver our hypothesis was that mobile advertising isn’t really delivering the value it should be able to given how much time folks spend on their phones. And we had a feeling that getting clean data into the hands of advertisers was the way to solve that. The setup around the opportunity in mobile advertising is well documented, so no reason to really spend much time there. It’s worth spending a bit of time on why that gap persists and how the mobile advertising world compares to online.

First off it’s important to understand how the online advertising components have evolved. In online ad serving I hear that a majority of display ads are now served through a set of services that provide realtime bidding (RTB). I don’t have any hard stats to point at for that one, but I’ve heard it from a few folks active in the environment and it seems to match up with logic and personal experience.

The nice thing for the publishers about moving inventory through RTB is that the advertisers can pay a price inline with their value for the individual impression. For impressions appropriate for retargeting the value can be much higher than the average value. The setup for RTB also allows for moving around third party sources of information called data management platforms (DMP) which raise the value of the inventory on the whole.

Sometimes an advertiser will have a source of info they directly want to hook up for marketing, but a lot of times the advertiser will want to tie into a third party source of information like BlueKai. The information can be anything from demographic info or credit score to purchase history – data which drives a huge amount of value for a marketer. Moving the data so it can be used with RTB requires a pretty complex set of machinery to populate and sync cookies.

Over the last few years the infrastructure in mobile, the operational systems, have quickly moved in the same direction as online. Thanks to some companies with fantastic vision like MoPub and Nexage the mobile side has actually moved a lot faster than the online world did. Probably because there was already a model system architecture to emulate and some standardized APIs like OpenRTB to build on. However, the business models don’t quite match up and there are some gaps in the mobile version.

The fact that folks spend most of their time in apps instead of in the browser is at the root of many of the issues. Since each app is generally sandboxed off from others, and there isn’t a consistent way to apply techniques like third-party cookies to deliver information, it makes it very difficult to hook into a data management platform or apply techniques like retargeting when working in mobile. Those techniques drive a lot of the value that comes out of using realtime bidding. So some folks have tried to use workarounds like using the UDID on iOS, which is a constant source of a lot of noise and discussion. And has led to Apple introducing an explicit identifier for advertising, which it seems for most people has just confused the issue even more even though it seems like a great step in the right direction. These techniques at least allow for the use of retargeting in mobile, even if there’s still a lot of work to make it consistent without being invasive for the user.

Another major difference that crops up in a bunch of different areas is the lack of visibility into application content. This was something we spent a lot of time poking at with Chomp, cause we were trying to figure out how to classify apps and understand their functionality. On the web this is much easier. You do what Google does and you crawl the pages and use the links between pages to make assumptions about the meaning and role of what the user is looking at. In applications you can’t crawl the content, and there are no links to use. The whole AdSense advertising model is based around that index of keywords and being able to match up an advertiser with what the user is looking at. There’s no equivalent to this in the mobile world as well. Not to mention the lack of ability to crawl the app content making the advertisers uncomfortable about putting their ads next to “unknown” content.

That’s all the downside stuff, things that make the current system of advertising in mobile end up less profitable than it otherwise could be. Fortunately they mostly stem from trying to jam the online model directly into mobile. So while we’ve been doing some bits to try to help solve those problems it’s all been fit into the overall framework of trying to detail the context of the user. And when I say context of the user I don’t mean just where are they, but also the device capabilities and constraints needed to paint the full picture of who this user is and what should match their current interest and intent.

This is all stuff that has long been held up as the promise of mobile advertising, but which we’ve never quite achieved as an industry. It was stuff we were talking about at AdMob in 2006, so it’s been a really long time coming. But this is all necessary for getting real commerce flowing through mobile, something we need to focus on to keep mobile healthy and on-track. We’re still at the narrow edge of the wedge when it comes to mobile services. Mobile has already touched a huge number of areas, but it hasn’t brought about the transformation I know is possible. There are even greater changes coming, and it’s time to start building for them.

Posted in Business, Metaresolver, Technology | 1 Comment

Mobile Advertising Mediation

The topic at Mobile Monday Silicon Valley was “Make Money with Mobile Ad Mediation”. Great topic, there’s a lot of activity around mobile advertising right now. Overall my take on mobile advertising high level remains what it was a few months ago: that we have a long way to go before we’re really delivering on the promise of what mobile could be. I’ve started chipping away at a few of those issues with a new project, and in the process dug into the details of the current mobile ads business a lot more deeply than I have in a while. There’s been a lot of attention paid to the supply side of mobile, so it was good to get a nice summary dump all at once. I normally take a pretty geeky take on things, and there were a few points that the discussion glossed over I just wanted to pull back out.

The mobile advertising world has matured pretty quickly. It was really simple to start out with, but it’s since evolved in the same direction as online advertising. So if you’re looking to understand what’s going on with mobile ads currently it wouldn’t hurt to familiarize yourself with how ad serving works online. Picking up on how realtime bidding works is a good idea too, cause RTB is one of the hot button items in mobile. Everyone is spinning up an exchange.

Mediation is a supply side technology. Generally speaking the folks who use mediation in the online world are at the upper end of media sophistication. They have particular constraints, such as having an in-house sales team that sometimes commits to high value campaigns. For them the mediation layer takes care of swapping inventory between what they sold themselves and what they want to put out on the general market.

Users of mediation in mobile range all over the place though, not just the upper end. The particular technical requirements in mobile, and mobile applications in particular, have a lot to do with that. One of the initial reasons for developers putting mediation in their apps was so that they could experiment with different ad networks without having to wait for an app approval cycle. In the online world if I want to try out a different ad network it’s a relatively easy thing for me to put the new ad network code up on my web servers and the swap is almost immediate. However in mobile if I want to try out a new ad network in my iOS app I might have to wait a week or longer for the app to go through Apple approval. And even then, if users don’t update they still see the old advertising setup. Some users update their apps very infrequently, some users not at all. In the mobile world the mediation layer is playing a bunch of additional roles it doesn’t necessarily have to fill in the online world.

Even though a lot of the discussion around mediation is around maximizing fill rate and increasing your effective payout, keep in mind the base tech requirements if you’re looking at doing a mobile service and considering how to setup advertising. This is the point that the Google mediation services for AdMob seem to really drive at. That you can start out with AdMob, and then turn on mediation down the line. Which doesn’t really seem like a huge deal, but keep in mind that approvals time and upgrade cycle for consumer apps and it sounds more appealing. You can do the same effectively with some of the other services. Just pay attention to the need to install the SDKs for other networks along with the mediation tool – if you have to that’s a signal that you might not be getting as much flexibility as you would like.

The really important point to underscore is that if you abstract the decision of how to serve ads and offload it to a server right off the bat instead of baking it into your binary you’re potentially saving yourself a headache.

Posted in AdMob, Business, Mobile Monday, Technology, ThisIsMobility | 1 Comment

Nook Developer Fail

With a few new entries into the market recently from Android tablet providers there’s been a lot of noise in developer circles about the potential of the new platforms. For instance, the Nook folks had appeared at the Appcelerator developer conference and done a Mobile Monday recently to tell us how much they love developers and want us to be successful. And they spun a pretty decent tale about how developing for their platform is a good way to cut through the noise and hit some unique demographics – there are a lot of compelling conceptual points. So I figured I would put that to the test. If you’re looking for the short version, the punchline is they didn’t do well at all. And I would not recommend to anyone trying out the platform in the shape it’s in now. If you want the longer version read on.

A lot of times it’s tricky to get real information about a platform. The folks who really understand the internals have a vested interest in seeing the platform succeed in market, and they’re concerned with their relationship with the platform provider. Lots of developer programs are actually run by marketing departments, so they can do a really good job of tempting folks to a platform. And unfortunately there isn’t always someone there to call bullshit and save independent developers from dumping their time into a lost cause. That doesn’t really seem fair at all. Thought it might not seem like it I am actually sorry to harsh on B&N. I’m sure there are some good folks over there who genuinely want to make the world better. But as it turns out I feel way more obligation to the developer community than I do to a retail outlet.

The way this actually started out was my curiosity about what application distribution numbers on the Nook devices would look like. I have visibility into stats from lots of different apps across different platforms, devices, and markets. But I had absolutely no info about the Nook. I do however have a few super simple testing apps sitting around, and some of them are already Android versions. So I thought: “How about I just package up one of the Android ones and release it for the Nook just to get myself some numbers?” Seemed like a simple enough proposition. So I grabbed myself a Nook Color and checked to make sure the stuff I was thinking about releasing wasn’t an exact clone of something already in the market. Nope, it wasn’t.

My first tip off that things weren’t going to he happy shiny in Nookville was the signup process. Just in order to signup as a Nook developer there was a really detailed set of questions to fill out. It was free though, so I just wrote the process off as them being hungry for information about their developers. And I was approved within the timeframe they predicted (I forget how long, important thing is that it wasn’t a surprise). It’s all Android stuff, which I’m pretty comfortable with. So despite some hiccups with their developer mode activation and this completely oddball multibutton process they have for launching sideloaded apps, it only took me an afternoon to get an app together, tested on the actual hardware, packaged up, and ready to go. That’s where it went all sideways.

When I first went in to check on the binary uploader it said I couldn’t upload anything cause my account was pending. I assumed that was just a quirk of creating a new developer account. But as it turns out it was cause I had to enter detailed user account and banking info, even after the details from the initial signup, and even though I only at this point wanted to distribute a free app. So I filled out the details and submitted them. And waited. And waited. And waited. Eventually I started up a support ticket to try to figure out what went wrong (screenshot of an excerpt below). As of right now it’s been a month since I started trying to get my app out, and the support ticket has been open for 24 days. Apparently there’s actually nothing wrong with my info. They just can’t get their systems working.

I’m just assuming at this point that my account is never going to get approved, and that B&N is just going to shut down their Nook experiment well before they get around to clearing up the developer account queue. So just keep this in mind when you’re thinking it sucks having to deal with Apple or Google: at least those systems work.

Since I wasn’t able to actually get an app released I don’t have any hard numbers to share. But there were a bunch of really obvious shortcomings in poking through what was there if you’re planning to build a business. It’s possible that these shortcomings are undone by the power B&N has in marketing your app. They really tout their physical world presence, and their ability to feature apps in-store in addition to on the device. They could be right about that making a difference. They also have an audience that skews female, which could be really interesting if you were able to get an app released. But I suspect the winners on the Nook platform are going to be the ones that have a strong brand already, with “must have” apps getting put in front of a new audience for the first time.

In terms of obvious problems, in giving up the Marketplace you also give up in-app purchase. So the model that almost everyone has adopted to make a profit on the dominant platforms isn’t going to apply if you want to develop for the Nook. It’s paid distribution and thats it. Another glaringly obvious missing feature is remote push notification. You can always hack this in with a background thread polling for updates the way we did pre-Froyo. I haven’t tried that, but I assume it works. It might not really be an issue however. The business reason for drawing users back to an app in terms of revenue model is to expose them to advertising (hopefully not your MAIN reason for drawing them back, but that’s a whole other discussion). However, cause Nook is a closed system that doesn’t allow for promotions for services outside of the Nook marketplace, I assume you’re not going to be able to run any of the existing in-app advertising solutions. Maybe you could run mobile web ads only?

So as far as I can tell this isn’t going to be a winning platform for the average mobile dev. It’s probably a profitable distribution strategy for folks who have a lot of recognition and are looking to get maximum coverage – like Rovio. But most of us are not Rovio.

What about the obvious final question: what about your Nook Color Miker, do you actually like it? Well, now that it’s running Cyanogenmod 7.1 instead of the stock firmware, why yes, I do like it! I’ve been running CM from the SD card, which makes it easy to swap back to booting stock. I’m pretty sure I’m going to be flashing the rom to internal memory though, since I see no reason to boot back to stock any more.

UPDATE: Looks like there are a bunch of issues, and they might even spin off the Nook business unit.

Posted in Android, Business, Community, Software, ThisIsMobility | 3 Comments

webOS Open Source

I wasn’t planning to weigh in on HP deciding to open up webOS, cause like I’ve said before tectonic shifts with little short-term impact aren’t really that important to startups. However, I’ve been doing open source stuff for a whole lot longer than I’ve been doing mobile stuff, so I have some particularly strong feelings on this one. And since I’ve already thrown my snarky knee-jerk response out there, I should probably be quasi-serious for a few minutes and try to help out. I don’t have much free time though, so this is going to be short – which usually ends up being somewhat smartass at points.

First off it’s necessary to understand how businessy folks view open source. I have no idea how many of you who read this blog were around for it, but this was a huge raging debate in the early 2000s. How could it possibly make sense for a company to just give away something that it had sunk a huge number of hours into, and potentially represented some significant chunks of intellectual property? The argument that really won the day centered on a concept called commoditizing your compliments. See this blog posting from Joel Spolsky for a bit of background on the economic principle. In terms of software it means giving away the stuff that won’t make you much money so you can make more money on the stuff with good margins. If anyone out there can make an alternative argument for why HP would open up the OS have at it. But I’m going to stick with the assumption that they’re positioning for a market shift in which the stewardship of the mobile OS itself is a commoditized low-value position.

So what’s the complement of a ‘platform designed from the ground up to be mobile, cloud-connected and scalable‘? Traditionally hardware has been the mainstay for HP. And it would make a kind of sense if they were looking to open up the OS and have folks integrate their own platform components in order to be able to make more hardware work together. They could be looking at the suite of iPad, iPhone, Apple TV, and iTunes and be thinking “Uh oh, Apple is starting to lock up the whole electronics space though integrated media components.” Which means if they want to keep playing in those markets they have to be able to catalyze a similarly optimized delivery channel if they want to keep a seat at the table. Possible. But I don’t think it’s the most likely one.

Another complement to webOS would be the stuff sitting on the other side, the cloud-connected part. That end would certainly line up with the software is eating the world idea that Marc (one of their board members) has been putting forth. Plus, it’s generally a bad idea to attack someone head-on when they’re in the kind of position of power that Apple is in. You try to look down the line to where their model extends and try to find a weakness. And while Apple has been fantastic on the merchandising side of the iTunes/App Store world, generally speaking their efforts to expand their cloud service offerings have fallen flat. If I were backed into a corner and forced to try to find a gap in the armor when competing with Apple, it’s the place I would go.

Since the full webOS stack is actually Linux under the hood, I assume it has an opportunity to capture a chunk of the Linux embedded system market the same was as Android has. As someone who spent way more time than I care to remember configuring and rebuilding Midori systems, I assume the more we can do on that part of the market the better. My fear though is that this opening of the platform is really just an attempt to try to get some free development. I’m sure that the folks involved at the top (like Marc) genuinely have a vision for everyone benefitting from opening up webOS, however it’s really easy to spoil an open source community down in the details even if your heart is in the right place.

If I put my rose colored glasses on and try to look into the future for webOS I see a future where the inherently web-connected OS manages to pull us out of this siloed mobile experience we’ve ended up in. It takes the best of what we’ve learned about putting services together as “apps” and reapplies that to the open web distribution model, and mixes in the deep platform capabilities from Android (for instance, I can write an app that accesses call log info. iOS GAH!).

However, to end up at that future we need an awesome technical platform AND distribution power. Products don’t win in market just for being the most technically awesome hacks. Otherwise we would all still be running BeOS today ;-) Unless there are a bunch of devices out in market running webOS it doesn’t make sense for third party developers to target the platform. And without a bunch of third party developers to write apps it’s hard to get a bunch of devices out into market (no one wants a phone without apps any more). So while I see a lot of awesome stuff that webOS COULD be, I still don’t see an obvious way to take it from where it is to where it needs to be. I don’t disagree with the open sourcing of the platform in general. It may be the right step along a roadmap. But because I have no idea what that roadmap is, I remain underwhelmed.

Posted in Community, Open Source, Technology, ThisIsMobility | Leave a comment

What’s With the Recent QR Code Abuses?

I’m seeing a lot of QR codes spread around, popping up in TV commercials and in print advertisements. And in general they’re horrible campaigns. My favorite are the commercials that flash a QR code on the screen for a few seconds, and before I can even get my phone out of my pocket the code is gone. Luckily I could use my DVR to rewind and catch it.. only to find out it won’t scan from where I’m sitting. Not like I have a small TV. But I get up and scan it anyway cause I’m curious – only to get taken to a full web version of a site that really offers me no benefit for pulling it up on my phone.

Like we were talking about last week, mobile advertising as a whole really isn’t delivering on the promise of the platform. So it’s great in concept that advertisers are willing to try out something new to find the value they’re looking for. But there are so many blunders in the campaigns from the delivery of the code itself to the post-click content… makes me feel like the last few years worth of mobile advertising hasn’t yielded any learning at all.

So here are some things to keep in mind. First off, when QR codes were first making the rounds even most of the higher end phones still had tripple tap text input when we were inputting URLs. So having a scannable code saved us some painful typing if the URL was long. And since folks were on their phone it made the most sense to link people directly to some specific resource to save them from having to navigate around. If folks were going to be scanning codes anyway, and the codes could store a decent amount of info, the advertiser could also include some additional tracking info in the URL so they could more easily segment their inbound traffic. Things are different now. That’s not to say there’s no reason to have QR codes at all, but their role has to be different.

First off, lots of us are on phones with keyboards (software or hardware) and very comfortable typing on them. Show a nice short url along with the QR code. It used to be user hostile to have to enter a URL, now it’s more user hostile to ask us to download a QR code to follow a link. Second, it doesn’t make sense to save me typing when entering a URL if you’re then going to take me to a full desktop version of a web page with a half-dozen fields on it. Third, it’s fine if you want to do some extra tracking of inbound clicks, but don’t force inconvenience on me in order for you to be able to track. I’m just not going to engage with your campaign at all.

Frankly, I think a lot of the uses I’m seeing are really misuses. Abuses even. The sarcastic side of me can’t keep from thinking there’s some advertising agency somewhere looking to crank up their bill with no regard for the benefit they’re providing the the advertiser or the experience of the user. But I’m going to be positive and not “attribute to malice that which is adequately explained by stupidity.” And hope that this is an opening where we can learn a bit and find some additional ways to get value out of everyone having a phone in their hand these days.

Posted in Technology, ThisIsMobility | Leave a comment

What’s Working and What Needs Work

We had a great discussion in the morning at Appnation, big thanks to the panel for participating and Drew and company for making it happen. The point of the panel was to try to distill a few concrete principles and lessons for folks trying to make sense of the environment, as well as call attention to anything that requires caution. Everyone was really bullish about the current environment, but there were definitely some interesting points to pull out.

One of the first areas that always pops up for me when we talk macro level trends is mobile is advertising. Mostly cause I was wrapped up in AdMob early on, but I’ve also been involved in the previous iterations of online advertising (early banner ad plays back in the mid 90s, Overture back when it was called Goto, and RSS advertising). There’s currently a big disjoin in the understanding of mobile advertising because the health of the system differs depending who you ask.

If you ask someone at a mobile ad network how things are going, they are genuinely happy. They’re making more money than ever. However, if you talk to the people doing the advertising they’re generally unhappy. Cost of acquisition is really high and they have trouble getting value out of the users they’re able to drive. For the publishers they’re making less and less off their inventory cause there’s so much supply side surplus. So generally folks are left confused, cause they see numbers for the industry as a whole saying mobile ads are generating a ton of money – but the folks trying to make a living off running those ads are having a tougher and tougher time.

That’s the first shift to take notice of. At one point it was possible to put out an app for free, get a decent amount of sticky users, and make a pretty good chunk of money just running ads from a network. That doesn’t work any more. The folks who are actually pulling in significant money from advertising have setup custom arrangements because they have some unique traits to their traffic. And for the rest of the folks out there, because there are so many more apps out there also running ads, even if you generate a huge amount of views it’s increasingly difficult to break even.

Mobile advertising as a whole needs a lot of work to deliver on the promise of the medium. There are some great folks out there working on making that happen, so I’m sure it will change eventually. But in the meantime don’t get caught on the wrong side of the trend.

The second major area of discussion was around games and in-app purchases. This is one area of the mobile app store environment that consistently generates money. There are some nice repeatable models being run in mobile games. Should those of us not doing games try to borrow a page from the games folks and attempt to put together models that shadow the successes?

Definitely, there’s a lot to be learned from what’s working in gaming. However, most folks tend to hop right to “game mechanics” as the major takeaway. Trying to slap some level/badging system on top of an existing system doesn’t really drive any benefit. The pieces that we should be pulling out of the gaming world are the attention to user funnels, where to put your monetization events, and how to break down your offerings. The result of paying attention to those metrics generated the game mechanics and virtual goods based system that’s become the norm in games. Outside of games the same principles generate systems like Dropbox. The takeaway is replicate the process used to distill the model, not the model itself.

The third big area of discussion was the online/offline models. The folks like HotelTonight and GigWalk and TaskRabbit. They’re models where a lot of the value to the business is created outside of mobile, but mobile has provided them with a channel that wouldn’t have been possible (or as effective) via desktops. Most of us agreed that this is one of the most interesting areas. The folks working in these spaces are pulling in a lot of new value to the system, and they’re likely to end up with more robust businesses less at risk from platform changes.

However, the models here are just starting to shake themselves out. There’s lot of infrastructure to these services that hasn’t yet been packaged and replicated. Payments is probably the most obvious area, where payments for offline goods stands in stark contrast to the in-app purchase systems available through the stores. But as we see more instances of the model there will definitely be additional areas where common tools and services could help.

There are two real takeaways from the online/offline models. The first is that if you’re looking at a model like this you should put your major focus on solving a problem and figuring out how mobile helps you address the problem most effectively. The contrast being starting with the technology and existing systems and working backward to a solution. The second is that there are some huge opportunities in doing infrastructure for these kinds of models. They’re hard to do, and “messy” cause they tend to have to deal with nasty real world problems. A lot of the problems we’ve been tackling at Churn Labs recently fall into the online/offline category, and a few of them have really knocked us for a loop. But there’s obviously a lot of value you can capture if you can pull a system together.

Actually, there was a lot more we talked about. And some great tidbits like Rich calling out that lots of the interesting “enterprise” stuff in mobile, like Dropbox and Evernote, are things that are used in the enterprise but not sold to the enterprise. But it’s getting late and I have a whole lot of programming to do tomorrow.

Posted in Business, Community, Technology, ThisIsMobility | 3 Comments