Introduction

The mobile app is facing a classic middle-man problem, where users associate the quality of the content inside as the quality of the app itself. They then proceed to give it a low rating on the Play Store. This can lead to a downward spiral, where a low rating tends to reduce the number of installs and users spread the message of poor quality through word of mouth.

Given that a significant number of the bad ratings are because of empty book nodes, since the latter can't be avoided due to the printing cycles - it would be good to help set expectations with end-users so they are less disgruntled and impatient with the pace of content addition to the Sunbird instance. Letting them know WHY there's so many empty nodes should help with this.

In addition, there's a large % of users who do enjoy using the app and who might not be aware that their rating is important to everyone on the Play Store (every drop counts). Bringing these users to the Play Store can help bolster the rating, and thereby improve perception of app value.

Finally, app ratings are currently hard to contextualize from the Play Console, since all app ratings are available with no information of tenant and sub-segments. Providing a means to identify a group rating within the app helps contextualize the app ratings based on user segments, and thereby identify what relief is best applied to which segment. This should help increase app quality perception amongst multiple user segments, as we cater to the specific problems that affect their group's experience.

JTBD

Jobs To Be Done: As a Sunbird instance or tenant within, I would like to know how my users perceive the quality of my offering and improve upon it. In addition, I would like for the maximum number of users to experience our app and decide for themselves the value the app provides.
User Personas: Teacher, Student, Ram, Shyam
System or Environment: Mostly at home, likely to be a couple of days (or more) after install so as to make a proper judgment of the value within the app.

Requirement Specifications

This section consists of requirement specifications for specific use cases in the User JTBD. The requirements for each use case are elaborated in detail through sub-sections for:

Use case overview
Overall process workflow
Associated user stories
Non-functional requirements
Localization requirements
Telemetry requirements
Dependencies
Impact on other products
Impact on existing data

Request of app experience rating after adequate experience

We attempt to get the user's rating of the app after they've had some time to experience the app and let us know their thoughts.

Overall Process Workflow

We give a couple of days to the user to get a sense of the value derived from the app, and after they've performed a core action within the app (e.g. playing a content), we ask them if they wish to rate us on the store. For users who give us a poor rating (most of which is going to be related to unavailable content), we direct them to the support page - where we attempt to address their concerns. Otherwise, we send the user to the Play Store to provide a rating.

The Sunbird app admin can then analyze the average ratings of weekly/monthly installs to understand the rating provided by various user segments within the app. They can then focus on improving the experience for those user segments.

As a Sunbird app admin, I want users to give me their opinion of the app, so I can decide where to focus for a better user experience

The flow would be as mentioned in the process workflow above. Users are asked to rate their experience after a predefined time duration has elapsed after their install.

Main Scenario - Rate the app after <x> duration

Srl. No.	User Action	Expected Result
	Ram opens the app after <x> time (For now, configure to 2 days)	Ram will play a content
	Ram plays a content and returns to the mobile app	Ram has completed a core action for which they'd opened the app. Ram is NOT shown the dialog asking for content rating.
	Ram is asked if he'd like to share his app experience in a manner visually distinct from content rating popup.	Ram says 'Yes' instead of ('Never' or 'Later')
	If Ram says 'Later', we wait again for <x> time	Ram becomes more willing to rate his app experience
	Ram is asked to rate his experience on a scale of 1-5	Ram selects a rating Ram's rating is stored in our device database.
	If Ram provides a rating below 4, Ram is apologized to - and asked if we can help resolve his concerns with the app. There are two ways: Look at the Support FAQ, and see if there's a known answer. Send a support request right away.	If Ram selects 'Support request', we initiate the 'Support request' flow with a minor change in subject to indicate that this was initiated due to the request for rating.
	Ram sends the mail	We thank Ram for his support, and will reach out to him within a couple of days.
	If Ram provides a rating >= 4, then his experience is quite good.	We take Ram to the Play Store to share his rating with others.

Exception Scenarios

Srl. No.	Error / Exception	Expected Handling
	Shyam has given us a rating, and then uninstalled and reinstalled the app.	The app identifies that this device has already provided a rating before, and therefore doesn't show the popup again.
	Shyam is actively using the app for a week after install, but has never gone online.	The app waits for a time when the user is online, and only then asks for their experience.

Wireframes

https://invis.io/2WRG3VO8RZ7

For Future Release

Disgruntled users are requested to rate their experience after more time has passed. Assuming they're still using the app, it would be good to know how their experience is now.

JIRA Ticket ID

Localization Requirements

UI Element

Description

Language(s)/ Locales Required

Messages

The message that is shown to the user after a core experience, to know what they feel about the app.

Message asking the user if we can help better their experience (by reading FAQ or sending a support request immediately)

All supported languages.

Telemetry Requirements

Event Name	Description	Purpose
User becomes a valid candidate	The moment the user completes a core value within the app (e.g. playing a content).	To know the start of the app rating funnel
User rating invite (count of instance)	The moment the user is shown a popup asking if they'd like to rate the app. We specifically also track which time this question has been asked (first, second.. nth).	To know how many users see this popup
User invite response	The response that the user provides (Yes / Later / Never)	To know how frequently users accept to rate the app vs. not
User star rating	The star rating shared by the user	To know what rating the user gives (and thereby context of the user)
User rating helpful acknowledgement	The user is shown an apology with an intent to fix experience at the earliest.	To see how many users are having a bad experience.
User selected FAQ section	The user's click on FAQ section	To know how many users go towards the FAQ vs. initiates a mail.
User was sent to Play Store	The users who've given the app a good rating	To bolster the quality rating on the Play Store

Non-Functional Requirements

Performance / Responsiveness Requirements	Load/Volume Requirements	Security / Privacy Requirements
Immediate	Across all users	User id and device id is sent to the FAQ/support email if needed.

Impact on other Products/Solutions

Product/Solution Impacted	Impact Description
N/A	N/A

Impact on Existing Users/Data

User/Data Impacted	Impact Description
Very few users who have provided a prior rating	Since some users would have provided ratings of their own intent, they are likely to see a rating popup again - and they can choose to say 'Never' set a rating.

Key Metrics

Srl. No.	Metric	Purpose of Metric
	Funnel of rating	This helps us understand what % of our users are willing to rate the app
	Comparitive analysis of ratings across states	This helps understand which segment of user (B/M/C/S) is underperforming compared to the median.

PRD

Improving ratings on Play Store