By Clint Ivy | November 14th, 2012 at 1:52 pm | 3 Comments
Mobile and the Web are the Same, but Mobile More So!
Native mobile applications contain a superset of the problems faced in managing tags on the web. The issues that are similar are more acute because of the mobile environment and there are additional issues to solve.
Page Weight = App Weight
How much your mobile app “weighs,” or how much disk space it uses, is critical because disk space on a mobile device is so much more limited than on your standard home computer. Shaving off just a few KB from your mobile application can have a much larger impact than shaving the same amount from a web page.
Third-party web services, whether a traditional tag vendor (like Adobe SiteCatalyst) or a new generation web service (like Pinterest), are integrated into native mobile applications via a “Software Development Kit” or SDK”. The SDK is a library written in the mobile app’s programming language that contains all of the functions and routines that the vendor needs loaded in order for its service to work.
Each vendor will have its own SDK (if they support native mobile applications at all), and each SDK loaded into your mobile app adds additional weight to it.
Does this sound familiar?
Let’s not forget that just like a web page, the ‘heavier’ an app is, the longer it takes the app to execute any particular action.
Mobile Development Cycles are Harder
Do you think it’s hard to make a tag change on a web page? It’s even harder in a mobile application. If you want to change how the SDK behaves in a single screen within the app, you cannot just change that screen like you could change the tag on a web page. Any change within the mobile application affects the entire thing. That means that the development cycle is more rigorous and that you need more lead time to get changes live.
It’s also not uncommon for companies to outsource their mobile app development, which adds an additional layer of separation between you and the tags you are responsible for.
Bonus Issue #1: Recertification
Every time you make a code change to your mobile application, it must be resubmitted and recertified by the appropriate platform operator (in the case of Android or iOS, for example, this would be Google and Apple, respectively). The recertification process can be problematic because the standards for approval seem to shift, or be applied somewhat whimsically, by the review teams. Recertification, no matter whether it’s a straight shot or involves many iterations of resubmission, only lengthens your time-to-launch for new marketing efforts involving tags.
Bonus Issue #2: Asynchronous Data Delivery
One more thing. Mobile devices aren’t always connected to a network when your customers use them. Can your tag vendors store the appropriate data and then send it when the device is available on a network again?
Tealium & Mobile
This does a few things:
- It makes our SDK incredibly light. All of the heavy lifting happens in the background, just like it does with our web implementations, so that the weight is offloaded from the app itself
- It allows for broader tag availability. We can use a vendor’s standard tag – there is no need to worry about whether or not they have a native app SDK
- Vendor tags are deployed through the Tealium SDK so there is no need to recertify the app for every new or changed tag. The same way that using Tealium iQ bypasses the dev/IT cycle on the web, using it in mobile apps bypasses both the dev/IT cycle and the app recertification process – vastly accelerating your time-to-market on the mobile platform
The only exceptionally different functionality between our SDK and the standard tag is that we’ve built in asynchronous data-handling so that if the app is not connected to a network while being used by your customer, the tag request and its associated data are queued until the next time the mobile device is connected, ensuring no data is lost during collection.
And that’s it! Yes, tag management can have a strong and positive impact on mobile marketing and we’ve built our mobile implementation with the same care for performance and eye for ease-of-use that makes our platform so useful in a web context.