If spending the previous four to five years in the mobile industry has taught me anything, it’s that mobile applications are vastly different than the web. Fundamentally the differences come down to the data: how you present the data, what relevant metrics are used; even how data is collected is a subject of strong debate within the analytics industry.
You wouldn’t treat a CRM like a rolodex, would you?
While on the surface the two solutions may seem similar, the way that you engage with the data and how metrics are calculated are different. You can’t go about the collection process on mobile the same way you have with web. There are many challenges in collecting mobile data, and a lot of assumptions in the desktop world that need to be thrown out when it comes to mobile. For example, unlike desktop, you cannot assume the user is always connected to the internet. Or that their internet connection is even fast enough to send data.
You also must account for users who are on the move. The social butterfly-types that are gallivanting around, connecting to multiple cellular towers. Each tower may have a slightly misaligned time, thus changing the user’s device clock by a couple of seconds with each switch. Suddenly, your data is all out of order, but you thought you were safe basing collection off of the time stamp.
And besides the technical limitations that are beyond your control, you have to also deal with a number of app-specific issues:
- Is your application written completely in native code (Objective-C or Java)?
- Is it a hybrid app built using native code wrapper, such as PhoneGap, to present web content (HTML and JavaScript)?
- Does the application have specific functionality that is unique to a particular device or platform?
Each of the above approaches has unique requirements, and each its own limitations.
The number of factors is enough to confuse anyone.
It’s okay to be overwhelmed. The requirements, the limitations; it’s just too much information, and as a result, most people end up over bloating their app with all the vendor and integration partner SDKs. This approach is rather resource intensive for your engineering teams and introduce additional risk in the stability of the application. All of this ends up frustrating the app product manager, marketing managers, and analysts when they struggle with accessing the proper data needed to make decisions and take appropriate action on the results for efforts such as push and in-app messages, A/B test, and a personalized app experience.
In addition to the impact on the respective teams the result of adding all these SDKs is that your application is going to be sizable before you even get to the frameworks needed for your application to do what it’s intended for!
If this were the web, you would run to your analytics vendor or to one of your third party solution providers and beg for some help implementing a tag management solution.
A true mobile tag management solution doesn’t exist.
Don’t get me wrong, there are some solutions on the market that do come darn close.
Segment has an SDK that can download other vendors’ SDKs, and maps Segment functions to the original SDKs native calls. It’s good enough for a couple of applications that only need to manage two or three SDKs, but it’s still not the same convenience and minimal footprint coveted from tag management solutions on the web.
There are also some companies evolving their tag management solutions, but many times they are still rely on the methodology of the web. Vendors that promise mobile app tag management commonly cite that their solution natively supports event-based tracking, conditional execution, batch uploading, and even device battery level (the latter to show that the tool can access some system level details); however, they typically still do these by calling a hidden web frame and passing the information via a JavaScript-like call.
So does mobile tag management make any sense?
Yes, mobile tag management does make sense, and it does provide similar benefits in mobile as it does in web. That is, if your mobile efforts are purely web-based (sometimes called mDot or m.yoursite.com), or if you have built a hybrid app with a native code wrapper of web content and are you willing to sacrifice some native optimization capabilities.
For native apps and a large portion of hybrid apps, the technology is simply not there yet. In hybrid, you still need to manage your device identification, sessions, and other key portions of data at the native code level, outside the scope of the JavaScript code that is presented to the user.
A success story.
I spoke with Randy Dailey, co-creator of ProximiT, an app designed to help Boston commuters with being timely when getting to the subway platform, to discuss his company’s use of tag management. Randy explained, “We’ve had a good experience using Google Tag Manager for ProximiT, but our implementation is somewhat naive – we’re just using it as a cloud based key/value store. There was no way to dynamically implement our analytics, push, and acquisition tags using GTM.”
ProximiT was still forced to manually include the SDKs of their solution providers, but they were able to use a tag management solution to solve a different problem:
The Massachusetts Bay Transportation Authority, also known as MBTA or “T”, was releasing a new API for Green Line tracking on a certain date. ProximiT was able to submit their app ahead of time, have their users download it, and they could dark launch the feature so that they had day-0 support without having to wait for app store approval.
There was no way to dynamically implement our analytics, push, and acquisition tags using GTM.
They were also able to tune the display of how often ProximiT showed the “Rate My App” message post facto after shipping. And, they kept the key/values to Google Analytics, Localytics, and a mapping of internal event code names to friendly event names in GTM so that we could switch them without having to re-release the app.
“On the SDK side, we shipped the app with a default configuration file that had failover values for all of the key/values and would use the tag manager to update the values of remote devices but the actual tagging of events and attributes still had to be done manually because we are a native app.”
The unfortunate truth for Randy and other mobile app developers is that there isn’t a simple solution that allows them to implement one set of code that would allow them to gather all their mobile analytics data, push, in-app messaging, acquisition management or A/B and MVT tool without manually dropping code in and redeploying their application.
If you are lucky, your mobile development team will write code to simplify the integration of different vendors. This sometimes avoids them having to dig through the code every time, but this is a timely upfront cost that would likely need to be revisited should other functionality be added.
Tag management solutions aren’t a complete throw away for mobile, as they can be used for some good, such as the way ProximiT is leveraging such tools. But the real options for using them just like you would on a website are just not there.
This post was originally published by me on the Search Discovery Blog here: http://www.searchdiscovery.com/blog/mobile-tag-management-the-unfortunate-truth/