Nothing is hotter than mobile right now. 72% of Americans have some sort of mobile device. [1] 62% of digital media time is spent on smartphones and tablets. [2] Mobile apps have also driven most of the growth in digital media usage in the past two years. While these numbers all represent the unique opportunity of mobile and building mobile apps, they also present unique challenges when it comes to native mobile analytics, which refers to data gleaned from a standalone application on a particular platform.

As a mobile consultant, I am often faced with the following questions from clients: will the analytics suite I painstakingly built for my website work on mobile and other touchpoints? How can I take my existing models and apply them to mobile? How do I measure my apps’ effectiveness if my customers are engaging through a text message or another micro moment? What do terms such as library, method, proxy, emulator, and architecture mean? It can all be confusing, especially due to the fact that the mobile landscape is always changing.

To help you better understand native mobile analytics, I’ll review some tools you’ll need to help track your data, as well as some best practices when transitioning to mobile.


A library is a set of code outside the app itself that typically performs key tasks. For example, libraries send text messages, show an ad, send data to a tag management system (TMS), or add the necessary code to build a native mobile personalization and testing campaigns. Libraries can use other libraries and are fundamental building blocks to apps. Adding and removing libraries are a key way to unlock the native mobile experience in the app.


A method is a set code within your app that translates into something noteworthy. These are written by your developers and typically do things such as show a button, grab data from a database, book a flight, or initiate a bank account transfer.

Proxy and Emulator

Proxy and emulator refer to tools that are used to work with your app once it’s built to make sure it works correctly. For example, using Charles Proxy or the Xcode iOS Simulator provides necessary transparency, ensuring you have a functioning mobile program.


Lastly, architecture refers to the fact that native apps do not work the same way as hybrid or web apps, and run on a fundamentally different piece of technology. For example, if you want the same app to run on the web and native, or on different types of phones, you will have to change the app to deal with architecture differences.

Merging Technical Tools with Business Goals

Indeed, the tools and skills required for native mobile are unique and in some cases quite complex. If your team doesn’t have a Java developer, objective-c developer, mobile expert, UX designer, JavaScript developer, TMS lead, and an analytics suite of experts, you may not feel capable of making the leap to native mobile.

Further, it’s not just about the technical aspect of mobile that will help you transition. It’s about looking into some areas of the mobile experience that you may not be thinking about. For example:

  1. All hands in – Native mobile requires buy-in from all stakeholders. It’s not enough to just have the technical teams involved. You need a positive consensus from all corners of your business, from analytics, to sales, to marketing. Due to increased complexity and the projected path of mobile in general, this technology is not optional. Once you’ve committed, you have to commit all the way.
  2. Alignment of goals – Next, you need to get business goals aligned with how you expect on-the-move customers to interact with the brand. For example, airline customers might get a notification based on their location when they might be late to their flight. Your business goals need to reflect this possibility (as well as others), building plans and tools that make them possible.
  3. Touchpoint configuration – It’s also important to align data collection with other touchpoints, which helps make sure you are ready to integrate. Touchpoints to consider include mobile ads, push notifications, and payment screens.
  4. Different KPIs – While the underlying KPIS such as brand engagement, first visits, and conversion are the same on desktop, the mode and metadata associated will be quite different. In other words, considering customer location, push notifications, limited screen size, motion sensor, and other types of input are all unique considerations to mobile.
  5. Gathering insights – Lastly, you need to initiate a native mobile optimization program through generated insights. When you start thinking about mobile optimization and A/B testing, you’ll be able to understand the areas of your mobile program that are excelling, as well as the areas that need improvement.

The ultimate goal here is knowing the customer and understanding their needs. This means merging the technical aspect of native mobile with the business side of the process. This is important because we are not only seeing the shifting preferences of the consumer, we also need a way to track those habits. Aligning your plans can help solve many mobile analytics roadblocks you may face.

While this all may be new (and perhaps even overwhelming), there are plenty of mobile analytics offerings that can give you the tools and expertise you need to make that leap, taking your existing infrastructure and building a world-class vendor agnostic native mobile analytics and optimization program. Understanding these basic elements of native mobile will only make the process easier, helping you to transition into the new world of analytics.