I downloaded several apps to my new iPad over the weekend and saw something I’d never encountered before when I opened the Hotels.com app. It was so weird I deleted the app and reinstalled it just to see if it was an accident. It was definitely not an accident, but it doesn’t make sense.
Instead of simply launching me into the app, after tapping on the icon, I briefly saw the app screen, got kicked out of the app into Safari, and once Safari finished loading a blank page, I went back to the app. Later, when I went back to Mobile Safari, the blank page was still there. Somewhere along the way, the UX guys at Hotels.com must have been duct-taped in a closet while someone forced this lousy experience on me and millions of other app users.
If you haven’t seen what I’m talking about, watch this video, it should give you a pretty good idea.
Why would a newly installed app launch Mobile Safari?
I happen to have access to some really smart people at HasOffers, so this is exactly what I asked. The technical reasons behind seeing this user experience are rooted in attempting to apply desktop cookie tracking within the limitations imposed on iOS developers. In industry parlance, this is known as “the switch”.
Here’s what happens. Let’s say I download an app from the iTunes App Store which employs “the switch” for tracking purposes. Once the app is installed on my iOS device, I click on the app icon to open it. The app opens and kicks me over to Mobile Safari where Mobile Safari will look for cookie data that gets compared to an event ID. This is followed by either a URL GET to send data to an external tracking engine or an HTTP POST to log the tracking information.
Since I had an organic install, there won’t be a cookie, but that doesn’t matter. Once the cookie state is verified, I’m returned to the application where I can do what I wanted to in the first place, which is use the app.
A better way to track app installs
Besides cookie tracking, a number of ad networks and publishers utilize Device ID or Mac Address to uniquely identify an app install. When a user clicks an ad, either of these unique identifiers can be collected. An ID can be logged for later comparison against installed applications. Apple has already warned they are eliminating access to Device ID, which means tracking solutions will probably lose Mac Address tracking in the near future as well.
While Device ID and Mac Address tracking solve the user experience problem I’m complaining about, you can’t collect either of them from the mobile web. As a result, mobile app marketers are turning to a broader “fingerprint” tracking solution, like the one we use in Mobile App Tracking, to correlate many pieces of anonymous information from a single device.
Creating this user fingerprint on the mobile web is very different than the process used in tracking transactions that originate from a desktop computer. Not only is the information collected different, but the sandbox restrictions in iOS create unique challenges in matching the data when it gets pulled through the mobile app on install.
Here again, the interruptive user experience created by passing data through Mobile Safari is eliminated.
App Tracking is Necessary
App developers need the ability to track installs. Mobile app tracking allows developers to accurately measure advertising spending. It allows for calculation of cost per install. And it also allows app developers to get important metrics that help improve the in-app experience. That’s the key – tracking needs to support app developers in creating a better experience, not interrupt it.
How do you feel about “the switch”? Would you uninstall an app that launched your browser and left some random tracking URL open in your browser?
This post was provided by a guest contributor. To check out posts by our most frequent authors, subscribe to our blog.