If spend­ing the previ­ous four to five years in the mobile indus­try has taught me anything, it’s that mobile appli­ca­tions are vastly differ­ent than the web. Funda­men­tally the differ­ences come down to the data: how you present the data, what rele­vant metrics are used; even how data is collected is a subject of strong debate within the analyt­ics indus­try.

You wouldn’t treat a CRM like a rolodex, would you?

While on the surface the two solu­tions may seem similar, the way that you engage with the data and how metrics are calcu­lated are differ­ent. You can’t go about the collec­tion process on mobile the same way you have with web. There are many chal­lenges in collect­ing mobile data, and a lot of assump­tions 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 inter­net. Or that their inter­net connec­tion is even fast enough to send data.

You also must account for users who are on the move. The social butter­fly-types that are galli­vant­ing around, connect­ing to multi­ple cellu­lar towers. Each tower may have a slightly misaligned time, thus chang­ing 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 collec­tion off of the time stamp.

And besides the tech­ni­cal limi­ta­tions that are beyond your control, you have to also deal with a number of app-specific issues:

  • Is your appli­ca­tion written completely in native code (Objective‑C or Java)?
  • Is it a hybrid app built using native code wrapper, such as Phone­Gap, to present web content (HTML and JavaScript)?
  • Does the appli­ca­tion have specific func­tion­al­ity that is unique to a partic­u­lar device or plat­form?

Each of the above approaches has unique require­ments, and each its own limi­ta­tions.

The number of factors is enough to confuse anyone.

It’s okay to be over­whelmed. The require­ments, the limi­ta­tions; it’s just too much infor­ma­tion, and as a result, most people end up over bloat­ing their app with all the vendor and inte­gra­tion partner SDKs. This approach is rather resource inten­sive for your engi­neer­ing teams and intro­duce addi­tional risk in the stabil­ity of the appli­ca­tion. All of this ends up frus­trat­ing the app product manager, market­ing managers, and analysts when they strug­gle with access­ing the proper data needed to make deci­sions and take appro­pri­ate action on the results for efforts such as push and in-app messages, A/B test, and a person­al­ized app expe­ri­ence.

In addi­tion to the impact on the respec­tive teams the result of adding all these SDKs is that your appli­ca­tion is going to be sizable before you even get to the frame­works needed for your appli­ca­tion to do what it’s intended for!

If this were the web, you would run to your analyt­ics vendor or to one of your third party solu­tion providers and beg for some help imple­ment­ing a tag manage­ment solu­tion.

Now for the unfortunate truth…

Laser Tag
A true mobile tag manage­ment solu­tion doesn’t exist.

Don’t get me wrong, there are some solu­tions on the market that do come darn close.

Segment has an SDK that can down­load other vendors’ SDKs, and maps Segment func­tions to the orig­i­nal SDKs native calls. It’s good enough for a couple of appli­ca­tions that only need to manage two or three SDKs, but it’s still not the same conve­nience and minimal foot­print coveted from tag manage­ment solu­tions on the web.

There are also some compa­nies evolv­ing their tag manage­ment solu­tions, but many times they are still rely on the method­ol­ogy of the web. Vendors that promise mobile app tag manage­ment commonly cite that their solu­tion natively supports event-based track­ing, condi­tional execu­tion, batch upload­ing, and even device battery level (the latter to show that the tool can access some system level details); however, they typi­cally still do these by calling a hidden web frame and passing the infor­ma­tion via a JavaScript-like call.

So does mobile tag management make any sense?

Yes, mobile tag manage­ment does make sense, and it does provide similar bene­fits in mobile as it does in web. That is, if your mobile efforts are purely web-based (some­times 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 sacri­fice some native opti­miza­tion capa­bil­i­ties.

For native apps and a large portion of hybrid apps, the tech­nol­ogy is simply not there yet. In hybrid, you still need to manage your device iden­ti­fi­ca­tion, 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 Prox­imiT, an app designed to help Boston commuters with being timely when getting to the subway plat­form, to discuss his company’s use of tag manage­ment. Randy explained, “We’ve had a good expe­ri­ence using Google Tag Manager for Prox­imiT, but our imple­men­ta­tion is some­what naive — we’re just using it as a cloud based key/value store. There was no way to dynam­i­cally imple­ment our analyt­ics, push, and acqui­si­tion tags using GTM.”

Prox­imiT was still forced to manu­ally include the SDKs of their solu­tion providers, but they were able to use a tag manage­ment solu­tion to solve a differ­ent problem:

The Mass­a­chu­setts Bay Trans­porta­tion Author­ity, also known as MBTA or “T”, was releas­ing a new API for Green Line track­ing on a certain date. Prox­imiT was able to submit their app ahead of time, have their users down­load 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 dynam­i­cally imple­ment our analyt­ics, push, and acqui­si­tion tags using GTM.

They were also able to tune the display of how often Prox­imiT showed the “Rate My App” message post facto after ship­ping. And, they kept the key/values to Google Analyt­ics, Loca­lyt­ics, and a mapping of inter­nal 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 config­u­ra­tion 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 attrib­utes still had to be done manu­ally because we are a native app.”

The unfor­tu­nate truth for Randy and other mobile app devel­op­ers is that there isn’t a simple solu­tion that allows them to imple­ment one set of code that would allow them to gather all their mobile analyt­ics data, push, in-app messag­ing, acqui­si­tion manage­ment or A/B and MVT tool without manu­ally drop­ping code in and rede­ploy­ing their appli­ca­tion.

If you are lucky, your mobile devel­op­ment team will write code to simplify the inte­gra­tion of differ­ent vendors. This some­times avoids them having to dig through the code every time, but this is a timely upfront cost that would likely need to be revis­ited should other func­tion­al­ity be added.

Tag manage­ment solu­tions aren’t a complete throw away for mobile, as they can be used for some good, such as the way Prox­imiT is lever­ag­ing such tools. But the real options for using them just like you would on a website are just not there.

We can help.

Data collec­tion, analyt­ics, opti­miza­tion, and messag­ing, can be confus­ing and ponder­ous. The team at Search Discovery regu­larly helps clients navi­gate through these chal­lenges. We would be more than happy to discuss how we can help you over­come the frus­trat­ing chal­lenges of mobile and other aspects of your analyt­ics, media, and SEO needs.