In any web 2.0 business, it is important to understand where you new users come from to understand where to put the effort in order to increase your user base. Browser-based services usually embed tracking information in URLs, but things are more difficult when you provide mobile phone applications for your service, because passing tracking parameters through the installation process is all but easy.
When the application is downloaded from your servers, it's rather easy to include tracking information in the downloads. But all application stores such as the iPhone AppStore, Android Market, Ovi and others imply a strong isolation between the application and the link that has been driving the user to the app store. There's no way to pass parameters to the installed application, and so the tracking information is lost.
I have found an ugly trick on iPhone and Android to circumvent this isolation and get back this precious information in the application. The key is to use the phone's browser cookies as an intermediate storage, and the ability provided by these platforms to associate a URL scheme to an application. Here is the process:
- First make sure your application registers its own URL scheme. We used "goojet:" for ours.
- Let ads, affiliate links, partner landing pages, etc link back to your server as would be the case for a regular web site
- When these URLs are called, your server should place a tracking cookie in the user's browser and redirect to the application store so that the user can install the application
- At the very first launch of the application, start the phone's browser, pointing to a "tracking reinjection" URL
- This URL should read the tracking cookie and redirect the user to your application, using it's special URL scheme and the tracking information, e.g. "goojet:start?source=foobar"
You now have the tracking information in your application.
You may wonder if step 3 isn't enough, since it tracks where people come from before being redirected to the app store. It is is not, firstly because you don't know if the user actually installed the application, and secondly because in our case we need the actual source in the application to prepare the new user's environment according to where he comes from.
The drawback of this approach is a visual glitch at first application start, since we start the browser and immediately come back to the application. Another bigger problem on the iPhone is that if there are already 8 tabs open in Safari, a "Too many open tab" alert pops up and it just fails and the user stays in Safari. Android handles this just fine and closes the oldest tab.
Did any of you, dear readers, encounter a similar problem? How did you solve it?
The best would be of course for all the application stores to allow us to propagate a tiny tracking token through the installation process.