“Make data-driven choices in every business decision” - this is the first principle I was taught in my university’s business class.
And while working as a lead android developer at VeryCreatives, I didn’t expect how much it’ll hold true for mobile application development as well.
Over the years, mobile developers have spent a significant amount of time improving data collection or data tracking. Nowadays, every application collects, uses, and stores some kind of user or device-related data.
Some data is used solely to enhance the user experience, while others represent user trends, streamline development, or aid in error fixing. Certain data also helps provide personalized content for users.
However, many users nowadays are worried about how their data is used. Scandals like Cambridge Analytica might give the impression that mobile app devs have ulterior motives behind gathering user data.
But is that really the case? In this article, I’ll analyze some of the types and ways businesses can collect user data to achieve their goals.
Device-Stored Data vs. Cloud-Stored Data
First, it’s crucial to understand the difference between local (device-stored) data and remote (backend or cloud) stored data. Local data is stored only on the device level and is not used for any analysis. This data is used to simplify users’ lives.
Examples include:
- Login Credentials: When a user logs into the application, we create a local copy of their credentials. This allows us to reuse it the next time the user opens the app. It is called a silent login.
- Preferred Language: Storing the chosen language option helps the app fetch content in the preferred language from our backend. This prevents users from the need of choosing their preferred language each time they open the application.
Such data collection is not intended for “spying” on anyone. As long as data is stored on the device level, it cannot be used for analytics because only the user device can access that data.
On the contrary, the app sends remote-stored data collected from multiple devices and users to a backend database. In these data collections, unlimited data from our users can be stored and can be analyzed to get valuable business information.
Centralized remote data storage is necessary for data-driven decisions, whether it’s part of the application’s backend or a third-party storage.
An important side note: Any device-stored data can be sent to a remote database. For example, to determine the most-used language in our app, we only need to send the selected language option data from the devices to the database, and we can easily get the result.
Types of Data Tracking
I would categorize data tracking into five types based on their collection method:
- Sensitive data tracking
- Data tracking for market segmentation or personalized content
- Data tracking for behavior analysis
- System logs
- Crashlytics or error tracking
While there are overlapping elements, I’ll try to differentiate them as much as possible.
Sensitive Data Tracking
Sensitive data comes directly from the user. Typically, the app can only request this data without creating new entries itself.
Examples include:
- Photos stored on the device
- Contacts/SMS/Emails
- The user’s GPS location
Although these data points are crucial for certain applications (GPS for a navigation system, photos for a photo editor app), the user must give explicit access to them by the mobile device OS. Without it, the app can’t access the data.
Once the user grants the permission, the app can use them locally or send them to a backend database.
Say you use the mobile version of Adobe Lightroom (a photo editing app). After logging in for the first time, the app will ask you for permission to access your photos.
Once granted, the app will let you pick the photos from your phone’s local storage and edit them. Additionally, each photo edited using Lightroom will be stored in Adobe’s cloud storage for you to access it from multiple devices.
While building your app, you should be mindful of the way you ask for permission to access user’s data. If the user receives too many requests at once, they might feel your app is trying to “know too much” about them.
A great way to distribute access requests throughout your app is to make them contextual. Don’t ask the user for access to all their data at the first launch. Instead, ask for specific data when the user tries to access specific features.
For example, only ask for access to camera when the user is trying to take a photo with your app.
Users generally try to deny access to these data, and the best practice is to request as few user permissions as possible.
Segmentation Data Tracking vs. Behavior Analysis Data Tracking
These two data tracking types are very similar, with only a few differences.
Segmentation data is linked to a specific user and is used to assign the user to a specific user group or differentiate them from others.
For example, an e-commerce store application can create two user groups:
- One for the users who already made a purchase
- One for the users who did not
Storing a successful purchase flag for each user’s record lets us know exactly which user is in which group.
Behavior analysis data serves a similar purpose. But instead of assigning data to specific users, it quantifies the number of specific events that happened within the app.
For example, you can use behavior analysis data to see the conversion rates of first-time app users. Here, you focus on the overall percentage of users without identifying them.
But wait – segmentation data can give you pretty much the same info, right?
Yes, but segmentation data can’t be used every time.
GDPR may require special storage for the segmentation data (especially if we want to use a third party for data collection, analysis, or storage). On the other hand, anonymous user engagement data often falls outside such regulations.
Let us illustrate this with an example. The shop application introduces a new feature: location-based discounts for their users. The further the user is from the shop, the bigger the discount is. This is an optional discount, but to get it, the user has to provide their address.
The business wants to see how many of the users use this feature (before investing more time in further development). Addresses are GDPR-sensitive data, so tracking them with user IDs requires special handling.
It may require extra effort (updating legal documentation, adding an option to delete this data, etc.). Adding a counter that only counts how many (unidentified) users used it means way less development and can answer the same question.
Another reason is storage capacity. For example, tracking every visited screen of each user will fill up the database quickly. Storing the number of visitors to each screen requires fewer resources.
What kind of information can be tracked?
Mostly anything a device can detect:
- Button interaction (shop item selected),
- Screen changes (which product detail is checked),
- Time spent on specific screens,
- User inputs (typed-in price, selected age),
- Drop-off points in a journey or flow,
- User origin (UTM parameters of application installation),
And more, depending on application requirements.
To track each element, you need to connect them to a unique tracking event. These events can contain multiple data fields.
For example, a registration tracking event can collect the user’s name, age, gender, while the purchase tracking event can collect the items, purchase amount, given destination and currency.
You also have multiple mobile app analytics tools to choose from.
Custom backend implementation offers the most flexibility. The received data from the mobile applications can be stored in a database. Then custom logic processes these data and displays them.
Another option is to use third-party tools that provide their own tracking system to collect and store the data. Usually, these companies provide easy-to-integrate tools and some custom services (analysis, segmentation, push notification for users, etc.), which can save development effort and time. Some examples include:
- CleverTap: A customer engagement platform that personalizes the user journeys
- CrossEngange: A customer intelligence platform
- Branch: Linking and attribution platform
- Intercom: Customer Support and AI chatbot
For anonymous behavior data collection, the most used system is Google Analytics.
System Logs
Logs are typically created for smaller, well-defined journeys and help identify any issues with them. The payment flow is a typical flow that requires well-written system logs. You can use this to identify any issue in a specific purchase.
The mentioned log would contain the timestamp of the purchase initiation, the selected item(s), the price, and the selected payment option.
Also, other entries of the same log would capture the response from the payment provider or the check result if the items are available in stock, and the end result that was given to the user.
From the whole log file, you can tell the exact reason why the user didn’t receive the item – from the payment provider not being able to deduct the money from the bank to the user canceling the purchase.
These logs can be created on either the mobile application side and sent to a remote database or generated by the backend. They can help you identify areas requiring improvement or provide data for system stability measurement.
Error Tracking
The least useful tracking for a marketing team but the most important for a development team is error tracking or crash tracking.
Although every developer dreams of a crash-free system, unforeseen user interactions or device conditions/errors can lead to unhandled use cases, causing application crashes.
Once a crash occurs, all the data stored in the device memory is lost, and figuring out what was the case is close to impossible.
That’s why crash reporting tools are essential. Before the application closes itself, these tools capture any data related to the cause and report it to the developers, who should solve the issues based on the reports.
You can use these reports to identify problematic parts of the application, or device providers, or even possible cyber attacks.
The most common tool is Firebase Crashlytics, which provides an easy-to-use SDK and a comprehensive reporting page for the developers. But as an alternative, there is Bugsnag with similar capabilities.
Final Thoughts
The implementation of a tracking system is usually not the challenging part. There are plenty of tools and options available. The difficulty lies in:
- Consistency: Every new feature requires new tracking events.
- Planning: Which actions, events, and inputs should be tracked and where they should be stored
- Understanding: Establishing the connection between collectible data and the user intent.
- Starting it from the beginning: Untracked interactions can not be collected later.
At Verycreatives, we have the necessary experience to provide a customized tracking system for any application. If you’re planning your mobile app and need a hand setting up your tracking system, let’s jump on a call and discuss the details.
FAQ: Understanding Data Tracking in Mobile Apps
Q: I hear a lot about how apps collect my data. Why do they do it?
A: App developers gather data for a variety of reasons, the most important being:
- Improving user experience: Data helps understand how users interact with the app and identify areas for enhancement.
- Market research & personalization: Analyzing trends allows businesses to tailor content, features, and offers to their audience.
- Identifying and fixing errors: Tracking errors and crashes helps developers improve app stability.
Q: Are there different types of data tracking?
A: Yes, here are some common types:
- Sensitive data tracking: User-provided data (photos, location, contacts) that requires explicit permission to access.
- Segmentation data tracking: Used to categorize users into groups based on characteristics or behavior.
- Behavior analysis data tracking: Quantifies events within the app without necessarily linking them to specific users.
- System logs: Records journeys within the app to pinpoint issues.
- Crashlytics or error tracking: Captures data about crashes to aid developers in troubleshooting.
Q: Should I be worried about apps tracking my data?
A: This is a complex question. Reputable companies use data responsibly to improve their apps and services without compromising user privacy. However, it’s important to be aware of the data apps collect. Here are some tips:
- Read privacy policies: Understand how the app will collect and use your data.
- Manage permissions: Grant access only to data necessary for the app to function.
- Be wary of overly intrusive apps: If an app requests too many permissions, consider a different one.
Q: How can I control what data is tracked?
A: Most operating systems (iOS, Android) allow you to manage permissions on an app-by-app basis. You can often deny or restrict access to certain types of data.
Q: How do I find out what data an app is collecting already?
A: Many app stores now require clear privacy policies and data collection disclosures. Check the app’s listing for a dedicated privacy section or contact the developer directly for more details.
