Gathering insights after publishing
In this series of blog posts, I’m focusing on several ways of gathering insights from data out of the feedback loop to improve your mobile apps. Collecting feedback leads to insights that will help you prioritize on app improvements in your product roadmap, backlog- and release planning. So far we have been talking about the feedback loop and gaining insights before publishing your app to the app store. What if you have all these insights and what can you do to improve the user experience in the long run?
In the app world, there are several ways to pro-actively announce enhancements in a so-called “feed-forward” loop. The product owner collaborates with the development team and stakeholders to figure out where to focus on and adjusts the roadmap based on new insights.
Manage expectations well towards your stakeholders. To get to the point of higher ratings, app developers have been failing, learning and improving for a longer period of time. Give yourself enough time to collect feedback and prepare improvements in several releases of your app. Prepare yourself and the team to release and improve in iterations instead of aiming for a 5-star app right from the beginning but put the mechanisms in place to collect feedback right from the start.
In this last blog, we will focus on gatherings insights after publishing and marketing your mobile app.
- Analyzing Appstore Analytics
The most accessible feedback would be the user reviews in the app store (readable by everyone). If you have a very active and engaged user population, users will rate your app and sometimes write reviews. Although ratings are definitely an important indicator of how users are appreciating your apps, these might not give you the complete picture. Reviews are usually shorter and more to the point, while in-app feedback (covered in the previous blog post) often includes more detailed input.
General app performance data and metrics can be obtained from the app stores but is mostly limited to high-level information such as app store views, app downloads, app sales and (high level) crash reporting. If this is good enough for your reports you are good to go and use this data. Be aware that there are differences between Apple and Google in this case. If you need to get insights on platform-specific analytics for e.g. your Android apps you can get tons of information from the Google Play Console. The same is more or less valid for iOS apps in Apple Appstore Connect, with the big difference that Apple is collecting data based on opt-ins. This means that only some users, with data sharing switched on, are contributing to app store analytics.
Within the app ecosystem, the app stores are utilized as a distribution (and more often) a feedback management platform for users of mobile apps. For all published apps you can use the release notes section of the app store to announce new features and improvements based on user feedback. Next to that you can reply to the feedback and follow up on planned improvements.
Analyzing In-App Analytics and Backend Logging
When you need to get more insights into the performance of your apps (independent of the platform used) switching to a more detailed analytics tool could be necessary.
In this case, metrics are collected in analytics tools such as i.e. Adobe-, Google Analytics or Firebase Crashlytics. Analytics tools require embedding of an SDK component in your app which has to be available cross-platform. With this, you are able to receive out of the box analytics data (like available in the App Store ) but on top of that, you can manually add events in your app that generate specific in-app metrics.
A big difference from the standard analytics data out of the App Store is that there are technically no opt-in limitations as described before. You have much more flexibility on getting more app focused metrics. Examples are screen hits, button presses, and funnels for conversion data reports. Implementing in-app metrics requires more efforts but is great for getting in-depth insights on the app performance and utilisation.
Before implementing in-app analytics make sure that you discuss with your compliance and legal departments on the data that you can or cannot collect. With regulations such as the GDPR, companies have to be more cautious when they collect data. Organizations are obliged to be transparent about how they collect data and for what purpose. When usage patterns are linked to user data for tracking and profiling, users need to give permission. This could mean that you need to revise the onboarding process and “collect” approvals of your existing users. Ultimately users should know what they are up to when they register and use your services and apps.
Due to privacy rules, storing personal identifiable information in analytics clouds is not allowed without compliancy considerations and technical measures (such as data anonymization and hashing). Special agreements can be made to switch off certain data collection settings on the vendor side (such as collecting the source IP address and specific personal identifiable information). Your test/audit team can validate this before pushing the app live.
Other then in-app analytics, transaction and audit logs provide great details about the number of transactions done by your app users. Most of the usage data is logged on the server backend. With BI tooling, new insights can be gathered on i.e. transactions per channel, successful registrations, payment transactions, the value of the transactions etc.
Analyzing Online Research and Voice Of the Customer Surveys
Online research activities can range from data mining activities (i.e. social media analytics) to conducting surveys (NPS research).
Although online surveys could be intrusive these are still a powerful way to find to collect feedback from your customer. When done in a structured manner you should be able to find out how loyal your customers are with regards to your brand or product and how your organization deals with customer inquiries. Surveys can be sent by email but also be embedded in your app or website. The best moment for offering embedded surveys is after a transaction has been finished or a support request has been handled. Usually sending an email survey during a work week will give higher response rates. Avoid Fridays and the very end of the day.
Transactional surveys focus on the customer experience during a specific transaction on a specific touch point. Relational surveys, on the other hand, focus on customer loyalty in a broader sense. A combination of transactional and relational surveys are possible but could be more difficult to build as these are focused on a specific target audience handling transactions at a specific moment in the customer journey.
Important metrics of online surveys are the CSAT- (Customer Satisfaction), CES- ( Customer Effort) or NPS (Net Promoter) scores. NPS is the most popular indicator and measures customer loyalty. NPS is calculated by subtracting the percentage of the least satisfied customers (detractors) from the percentage of loyal customers (promoters). This results in a score between –100 and +100.
Segmentation and filtering can be applied in your NPS research like i.e. channels used in the customer journey, user activity, products/services used. Let’s say you have an app that offers different services depending on the product lifecycle, you can measure the NPS during different phases in that lifecycle (i.e. the onboarding, ordering, and payment). Once you have started measuring and have a baseline, make sure that you measure regularly (2 to 4 times a year). When there are clear differences in NPS scores between users that are using your app versus users that have used other digital channels, you can dive deeper into the reasons why.