How I Mostly Came to Stop Fearing App Measurement
June 19, 2017 -
Professionals who have been doing the same thing for a long time tend to take a lot of simple things for granted. No matter what analytics tool I’m using or what sort of website I’m working with the rules of the road are basically the same. I’m used to driving on the right side of the road, but driving on the left only takes some minor adjustments because the task of driving is still based on a basic set of assumptions about driving and how do it.
The first time I worked with Google Analytics for a mobile app, I thought I was climbing into that seemingly familiar car. Sure, I was expecting to drive on the left side of the road but I was confident that I’d be working from familiar territory. It’s all GA after all, isn’t it?
Instead of the same familiar car, I got myself into a boat. A lot of the fundamental assumptions I had about core functions weren’t what I was expecting, and it took a bit of adjusting to get moving again.
Apps are not websites
This really deserves saying. Fundamentally, you have an entirely different product. Your audience in an app, their behaviors, and your goals are going to be different than the audience, behaviors, and goals for your web traffic. This is especially important where an app has been developed that reflects your existing website experience with few modifications. You need to adjust your expectations as well as your approach to measurement.
Below, I’ve outlined some of the common areas where I’ve helped our clients learn about app tracking in Google Analytics, and how to start taking advantage of some of the opportunities in app analytics.
Google Analytics for apps – What you get out of the box:
- The number of users and sessions
- Session duration
- Operating systems
- Device models
That’s it. You have the ability to add a lot of functionality onto the base implementation, but the baseline functionality for apps is significantly less than what it is for the web. This means you need to get your head around how to measure success without a lot of the things you’re used to working with.
Web measurement fundamentals that don’t translate well to apps
Many apps are built to reflect the look and feel of an existing website. Often, there will be the temptation to treat page consumption as the same type of activity between the website and the app.
In the mobile SDK you don’t have pages; you have screens. Pageviews don’t come for “free” like they do on the web. Each screen needs to be assigned a name. This can be labor-intensive and challenging to govern. All these practical considerations aside, why are you doing this? Moving away from pages can be an opportunity to rethink the way you’re measuring engagement.
Why is someone using your app and not your website? These users are on your app for a reason. Maybe your app makes it faster for people who make frequent corporate orders to do so quickly. Maybe the app offers a more personalized content experience than your homepage. Whatever the reason, think about the reasons you built an app in the first place. App measurement is much better suited to measuring the volume and quality of content consumption through events rather than pageviews.
For the web, one of the most important things about getting well-tagged inbound traffic is that you can understand the return you’re getting for any given marketing effort. This is based in the assumption that traffic will come from diverse sources. For apps, you have inbound traffic from people who already have the app, and inbound traffic from people who are installing the app. Install campaigns will generally always happen from the app store, and there’s a handful of methods (paid search, for example) to drive people with existing installs of an app on their phone from the web to the app experience. Because you basically have traffic from two sources (app store, direct), you need to look from within to start thinking about attribution. Are there user segments or specific products or services you can offer on your app that are better correlated with a successful user interaction? This comes back, again, to the same central question — why is someone on the app and not the website? Focus on the goals of your app as an app, not as an extension of your website.
The web is a wide-open place, which makes it easy to stumble upon content through any number of external means. It takes a lot more steps and deliberation to seek out and install an app, or even open it, than for your typical web visitor. That means that on your website you’ll probably have people with a lot of different goals. Some people will be window-shopping, some will be competitive researchers, or they’re looking to apply for a job. You have an audience in your app that is necessarily predisposed to loyalty and high levels of engagement. Again, this is an opportunity. They came here on purpose. Do the goals you have for successful user interactions reflect the loyal disposition of these users? Do you have an experience that is tailored to their affiliation with the brand?
Wrapping it all up
You built an app for a reason, and your users installed it for a reason. Measurement should always come back to the best ways to determine success against the goal you had for your app. The standard information available to you in a newly-minted GA for app implementation is significantly pared back from what’s available for the web, but this can be an opportunity to maintain focus on what success looks like for app interactions, rather than viewing the app as a mirror of your website.