If spend­ing the pre­vi­ous four to five years in the mobile indus­try has taught me any­thing, it’s that mobile appli­ca­tions are vast­ly dif­fer­ent than the web. Fun­da­men­tal­ly the dif­fer­ences come down to the data: how you present the data, what rel­e­vant met­rics are used; even how data is col­lect­ed is a sub­ject of strong debate with­in the ana­lyt­ics indus­try.

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

While on the sur­face the two solu­tions may seem sim­i­lar, the way that you engage with the data and how met­rics are cal­cu­lat­ed are dif­fer­ent. You can’t go about the col­lec­tion process on mobile the same way you have with web. There are many chal­lenges in col­lect­ing mobile data, and a lot of assump­tions in the desk­top world that need to be thrown out when it comes to mobile. For exam­ple, unlike desk­top, you can­not assume the user is always con­nect­ed to the inter­net. Or that their inter­net con­nec­tion is even fast enough to send data. 

You also must account for users who are on the move. The social but­ter­fly-types that are gal­li­vant­i­ng around, con­nect­ing to mul­ti­ple cel­lu­lar tow­ers. Each tow­er may have a slight­ly mis­aligned time, thus chang­ing the user’s device clock by a cou­ple of sec­onds with each switch. Sud­den­ly, your data is all out of order, but you thought you were safe bas­ing col­lec­tion off of the time stamp.

And besides the tech­ni­cal lim­i­ta­tions that are beyond your con­trol, you have to also deal with a num­ber of app-spe­cif­ic issues:

  • Is your appli­ca­tion writ­ten com­plete­ly in native code (Objec­tive-C or Java)?
  • Is it a hybrid app built using native code wrap­per, such as Phone­Gap, to present web con­tent (HTML and JavaScript)?
  • Does the appli­ca­tion have spe­cif­ic func­tion­al­i­ty that is unique to a par­tic­u­lar device or plat­form?

Each of the above approach­es has unique require­ments, and each its own lim­i­ta­tions.

The number of factors is enough to confuse anyone.

It’s okay to be over­whelmed. The require­ments, the lim­i­ta­tions; it’s just too much infor­ma­tion, and as a result, most peo­ple end up over bloat­ing their app with all the ven­dor and inte­gra­tion part­ner SDKs. This approach is rather resource inten­sive for your engi­neer­ing teams and intro­duce addi­tion­al risk in the sta­bil­i­ty of the appli­ca­tion. All of this ends up frus­trat­ing the app prod­uct man­ag­er, mar­ket­ing man­agers, and ana­lysts when they strug­gle with access­ing the prop­er data need­ed to make deci­sions and take appro­pri­ate action on the results for efforts such as push and in-app mes­sages, A/B test, and a per­son­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 siz­able before you even get to the frame­works need­ed for your appli­ca­tion to do what it’s intend­ed for!

If this were the web, you would run to your ana­lyt­ics ven­dor or to one of your third par­ty solu­tion providers and beg for some help imple­ment­ing a tag man­age­ment solu­tion.

Now for the unfortunate truth…

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

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

Seg­ment has an SDK that can down­load oth­er ven­dors’ SDKs, and maps Seg­ment func­tions to the orig­i­nal SDKs native calls. It’s good enough for a cou­ple of appli­ca­tions that only need to man­age two or three SDKs, but it’s still not the same con­ve­nience and min­i­mal foot­print cov­et­ed from tag man­age­ment solu­tions on the web.

There are also some com­pa­nies evolv­ing their tag man­age­ment solu­tions, but many times they are still rely on the method­ol­o­gy of the web. Ven­dors that promise mobile app tag man­age­ment com­mon­ly cite that their solu­tion native­ly sup­ports event-based track­ing, con­di­tion­al exe­cu­tion, batch upload­ing, and even device bat­tery lev­el (the lat­ter to show that the tool can access some sys­tem lev­el details); how­ev­er, they typ­i­cal­ly still do these by call­ing a hid­den web frame and pass­ing the infor­ma­tion via a JavaScript-like call.

So does mobile tag management make any sense?

Yes, mobile tag man­age­ment does make sense, and it does pro­vide sim­i­lar ben­e­fits in mobile as it does in web. That is, if your mobile efforts are pure­ly web-based (some­times called mDot or m.yoursite.com), or if you have built a hybrid app with a native code wrap­per of web con­tent and are you will­ing to sac­ri­fice some native opti­miza­tion capa­bil­i­ties.

For native apps and a large por­tion of hybrid apps, the tech­nol­o­gy is sim­ply not there yet. In hybrid, you still need to man­age your device iden­ti­fi­ca­tion, ses­sions, and oth­er key por­tions of data at the native code lev­el, out­side the scope of the JavaScript code that is pre­sent­ed to the user.

A success story.

I spoke with Randy Dai­ley, co-cre­ator of Prox­im­iT, an app designed to help Boston com­muters with being time­ly when get­ting to the sub­way plat­form, to dis­cuss his company’s use of tag man­age­ment. Randy explained, “We’ve had a good expe­ri­ence using Google Tag Man­ag­er for Prox­im­iT, 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­cal­ly imple­ment our ana­lyt­ics, push, and acqui­si­tion tags using GTM.”

Prox­im­iT was still forced to man­u­al­ly include the SDKs of their solu­tion providers, but they were able to use a tag man­age­ment solu­tion to solve a dif­fer­ent prob­lem:

The Mass­a­chu­setts Bay Trans­porta­tion Author­i­ty, also known as MBTA or “T”, was releas­ing a new API for Green Line track­ing on a cer­tain date. Prox­im­iT was able to sub­mit their app ahead of time, have their users down­load it, and they could dark launch the fea­ture so that they had day-0 sup­port with­out hav­ing to wait for app store approval.

There was no way to dynam­i­cal­ly imple­ment our ana­lyt­ics, push, and acqui­si­tion tags using GTM.

They were also able to tune the dis­play of how often Prox­im­iT showed the “Rate My App” mes­sage post fac­to after ship­ping. And, they kept the key/values to Google Ana­lyt­ics, Loc­a­lyt­ics, and a map­ping of inter­nal event code names to friend­ly event names in GTM so that we could switch them with­out hav­ing to re-release the app.

On the SDK side, we shipped the app with a default con­fig­u­ra­tion file that had failover val­ues for all of the key/values and would use the tag man­ag­er to update the val­ues of remote devices but the actu­al tag­ging of events and attrib­ut­es still had to be done man­u­al­ly because we are a native app.”

The unfor­tu­nate truth for Randy and oth­er mobile app devel­op­ers is that there isn’t a sim­ple solu­tion that allows them to imple­ment one set of code that would allow them to gath­er all their mobile ana­lyt­ics data, push, in-app mes­sag­ing, acqui­si­tion man­age­ment or A/B and MVT tool with­out man­u­al­ly 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 sim­pli­fy the inte­gra­tion of dif­fer­ent ven­dors. This some­times avoids them hav­ing to dig through the code every time, but this is a time­ly upfront cost that would like­ly need to be revis­it­ed should oth­er func­tion­al­i­ty be added.

Tag man­age­ment solu­tions aren’t a com­plete throw away for mobile, as they can be used for some good, such as the way Prox­im­iT is lever­ag­ing such tools. But the real options for using them just like you would on a web­site are just not there.

We can help.

Data col­lec­tion, ana­lyt­ics, opti­miza­tion, and mes­sag­ing, can be con­fus­ing and pon­der­ous. The team at Search Dis­cov­ery reg­u­lar­ly helps clients nav­i­gate through these chal­lenges. We would be more than hap­py to dis­cuss how we can help you over­come the frus­trat­ing chal­lenges of mobile and oth­er aspects of your ana­lyt­ics, media, and SEO needs.