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.
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 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:
- UDID/IFA exchange
- first-party cookie
- 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.