Time was that the best way to understand UX was to talk to users. It’s still useful. Today, the state-of-the-art for understanding mobile user engagement is data delivered within the app, as an organic part of the user experience.
The challenge is to build those tools for understanding the quality of user experience into the app itself, in a way that doesn’t intrude on what the user is doing. In this post we survey the best tools and hey parameters to track user patterns in your app.
Mobile user analytics is the key weapon in the UX designer’s arsenal to conquer the mobile market.
With all the potential features you want to pack into your app, you may be tempted to put tracking how users and customers interact with your app outside the scope of your MVP. Don’t make that mistake. In fact, it’s even more important than A/B testing, especially if you are offering B2B SaaS. Customers who pay you to put their staff on your platform will expect you be able to prove how productive it is.
In this post, we’re going to do a high-level look at why we’d want to track users to begin with, the different ways to do it, and some things to keep in mind while integrating different services with your app.
What is “tracking” behavior
Terms like “tracking” can conjure up a lot of negative imagery when it comes to things like user privacy. When we say “track,” we quite literally mean that we’re recording a the specifics of a user’s behavior within our application. Recording generally refers to sending a message to an analytics service when a user does something.
When something happens in our application, we record it. Most of the services show you a reverse-chronological timeline of events denoting some sort of user behavior. We can see things like user “Tapped the signup button” three days ago or “Cancelled subscription” 20 minutes ago. These types of events on a timeline will show a very specific set of behaviors that you can analyze and later change your app with such data in mind. For example, if the user created five todo items in your planner app and then canceled his account the next day, we can gather that something about the product didn’t meet the user’s needs.
This is where tracking can become incredibly valuable: identifying pitfalls in the successful usage of an app. With this sort of information, you can do proactive things like contact a specific user to ask about their cancellation and attempt to keep them as a customer. We can also do things like identify trouble areas in an app and determine where to focus efforts.
Like anything, tracking is good in moderation. Better yet, tracking is good when the purpose behind that tracking is well-informed.
What to track and when
First, we need to understand what to track, when, and why. It’s easy to think that you need to track every little detail, however, that’s not always necessary. It all boils down to utility: how will you and/or your team make use of the information that you’re collecting? What will the information inform? Will it be used to improve your app or simply as a marketing tool when speaking to investors?
For B2B SaaS applications, your customers are organizations who have a population of their own users hosted on your platform. Think about the job their user does with your app. Beyond the satisfaction of each individual user, a customer who relies on your app to drive their business will want to understand your contribution to their profitability. A powerful selling point for you: offering analytics that shows productivity and utilization for user populations across customers, comparing one company’s users to others who use your platform.
Determining utility requires a conversation, either with yourself or with your team. Before you blindly start tracking user behavior, it’s important to know why you’re doing it and what you need (versus what you don’t). Getting there is a matter of asking a few questions:
- What is the primary goal of collecting this data?
- What specific data will help you fulfill that goal best?
- Who is responsible for collecting, organizing, and reporting on the data?
- How and when will you evaluate the reported data?
- How will you form a decision on a path forward based on the data?
- Once you’ve made a decision, who is responsible for implementing it?
- Once a decision is implemented, how will you evaluate its effectiveness?
An example conversation or response may look like this:
- We’ve noticed a lot of users creating an account, but not completing account setup. We want to understand where users are getting stuck in the onboarding phase of our app.
- We need to know how many people are making it through each of the steps and identifying any characteristics of those people that separate them from others.
- Jane is going to collect and organize the data into a report.
- We will have a meeting to discuss where users seem to have the most trouble and discuss what in the app may be causing that. We will couple this with other data we’ve received like support requests.
- We will decide whether this a problem that needs to be solved by a specific team (e.g. design or engineering), or, by multiple teams.
- Based on the team we chose to solve the problem, we will assign members of those teams to implement the solution.
- Once the solution has been implemented, we will collect data for an additional week and see if the numbers have improved. If they haven’t, we’ll repeat this process until we find one that improves user success.
This is just an example. An actual process will churn up a lot more questions and discussion. The point is to think about implementing tracking based on something specific that will influence your decision making. A mistake many app owners make is tracking a lot of random things only to realize they didn’t know what to do with them. It’s easy to think you need everything, but it’s important to ask whether or not that’s the case and identify the problems you’re really trying to solve and why.
If you’re not part of a team and on your own, focus on tracking and improving smaller scopes. Instead of tracking behavior on every single feature, pick one or two and focus on their improvement before moving on. Follow the questions above, always asking if what you’re implementing is in response to a specific goal. If it isn’t, reevaluate and decide whether or not the work is necessary.
Determining what to track
If you need to determine the utility of each thing before you track it, should you track anything to begin with? Yes. It will depend on how your service is built, but a good rule of thumb is to focus on tracking behavior around things like your signup flow, a primary feature, or customers canceling their subscription.
Avoid panicking about missing out on data. Track those things whose data you can make use of now and ignore the rest until you can actually make use of it. If you “track all the things,” it can be easy to overwhelm yourself and distract your thinking from what really matters. Get the basics right first and then continue to tune later.
As the concept of tracking user behavior has grown over the years, so too has the number of services available to perform the task. There are a lot of services that more-or-less do the same thing, each with their own variation or tweak. We’re going to look at some of the most popular options and highlight services that work particularly well.
While most people think of Google Analytics as a tool for tracking things like page visits, it also offers an event tracking service for the apps. This service allows you to track specific events (behaviors) in your application and see them within your Google Analytics dashboard.
Here you can see all of the events that have been sent to Google for the specific property. They offer filtering by category, action, and label so you can split up data based on certain campaigns or event types.
Tracking data is similar to other services, just installing a small portion of code and then tracking events. GA is very popular among Android developers because of its obviously tight integration with other Google services.
Another popular contender for tracking behavior is Mixpanel. What’s unique about Mixpanel is that beyond just tracking events, they also allow you to track specific users. This means that when a user signs up for your application, you can create a “profile” for them on Mixpanel which records that user’s individual behavior. Even further, they also allow you to track things like sales and revenue. Beyond just tracking events, Mixpanel helps you to interact with customers based on those events and data.
For example, if you want to send out a notification to all of the users who only add one picture in your photo app and then logout of the application, Mixpanel makes this possible. Using their interface, you can filter down users and target them based on their behavior. This is great if you’re trying to test the performance of a certain feature and are concerned about your user base as a whole as opposed to just one user.
What’s nice about this is that it mostly decouples tracking code from your application. By looking at generic events on elements and pairing them with definitions, you can assign the task of defining events to a non-technical member of your team. If you’re not the product owner, this can be a huge win for your time and productivity. Just drop in the code and then let someone else define the events they want to track.
Technically speaking, Intercom isn’t a behavior tracking service. Instead, they’re best identified as a customer engagement tool. The reason we included Intercom here is because they still allow you to resolve the problems mentioned above in the post revolving around user success. Instead of “guesstimating” based on user behavior, Intercom allows you to message users directly within the application and start real-time conversations. This is great because it allows you to directly communicate with your users and pinpoint issues as they happen.
With all of these services you’re likely seeing two paths forward. Let your head spin at the number of options and configurations. Or pick out a few and leave the rest behind. In the past this was admittedly the best route forward, but now it’s possible to do both actually. With Segment, you can take advantage of using tons of tracking tools using the same code. Instead of implementing the specific tracking code for each service, Segment gives us a unified API for sending events to services.
Once you’ve installed Segment, use three primary methods to track events and users for identifying specific users, for tracking certain events, and for tracking movement between pages or views in our application. Behind the scenes, Segment does the heavy lifting of converting the shape of those events to match the various services we’ve selected in their dashboard.
As a closing note, it’s important to mention that you need to be responsible, specifically in regard to user privacy. Don’t be a creep. If you’re tracking your users, tell them when, why, and how you’re doing it. Beyond running an ethical service or business, this builds user trust and in some cases protects you from unwanted legal action. If your customers know that you’re tracking them, they’ll be more open to things like receiving emails when they cancel their account. If they didn’t know they were being tracked and receive an email afterward? Prepare for a potential freak out and their absolute dismissal of your service (both personally and when asked by others).
How CloudGeometry can help
Analytics and Big Data are more than a useful supplement to mobile applications; they need to be built in from the get-to. At CloudGeometry, we know which data you should collect, how to analyze it and what to do with it – to continually improve your mobile app or SaaS offering to keep ahead of the competition, to show what users value most (and least) from your app. We have years of experience crafting and launching award-winning mobile apps, whether your targeted audience is consumers or business users. Our experts can help you with everything from user experience to choosing between native vs. cross platform, back end infrastructure, data analytics, and everything in between.