I’d first clarify what counts as an active user, verify the decline, and identify where it is concentrated. Then I’d examine the user journey and recent changes to understand whether users are struggling to complete a task or simply spending less time on the platform.
1. Clarify the product and scope
For this case, I’d focus on Zerodha’s retail trading experience through Kite. Users come here to monitor securities, review charts, place orders, and track their positions or holdings.
I’d ask whether the decline is concentrated in a particular activity, such as intraday trading or long-term investing, or across the retail experience.
The case tells us that multiple user segments and product categories are affected. I’d therefore begin broadly, then narrow the investigation using platform and behavioural data.
2. Understand what “daily active” means
The agreed definition in this case is a logged-in user who spends at least 15 minutes on the app during a day, whether or not they trade.
I’d express that as:
DAU = Number of unique logged-in users with at least 15 minutes of foreground app time that day
I’d confirm whether those 15 minutes can span multiple sessions, how idle time is handled, and which time zone defines the day.
This is a duration-based activity metric. It can fall even when the number of people using the product remains unchanged. For example, a user who previously spent 17 minutes reviewing charts but now spends 12 minutes would disappear from this DAU count.
I’d therefore examine three measures together:
Unique users who log in each day.
Unique users who meet the 15-minute threshold.
Unique users who complete meaningful tasks, such as reviewing a chart or managing an order.
That would help me distinguish fewer visitors from shorter sessions or reduced task completion.
3. Verify and segment the decline
I’d check the metric definition, dashboard, event collection, and data pipeline. In particular, I’d verify that time spent in the chart view is still counted correctly.
The case says reporting and calculation methods are unchanged, the decline is sudden, and support ticket volume is stable. I’d still inspect ticket categories because a rise in chart-related complaints could be hidden within an unchanged total.
I’d ask for the size of the decline and its exact start date, then compare equivalent trading days. Market holidays and weekends should not distort the comparison.
Next, I’d segment by:
Mobile versus web.
iOS versus Android.
App version, device, and operating-system version.
New versus existing users.
Region and time of day.
Previous chart usage and trading behaviour.
The strongest finding is that the decline is concentrated on iOS, affects both new and existing users, and has no clear regional or time-of-day pattern.
That makes an iOS product change a stronger starting hypothesis than a platform-wide shift in demand.
4. Walk through the user journey
I’d examine:
Open and authenticate → Select a security → Review information or charts → Place or manage an order → Review order status and holdings
I’d treat any additional authorisation as specific to the relevant transaction, rather than assume every buy or sell follows the same process.
Journey stage | What I’d check | Evidence from the case |
|---|---|---|
Access and authentication | Login failures, crashes, added friction | No reported change |
Security selection | Watchlist access and information loading | No reported change |
Chart access | Visibility, successful opens, loading, abandonment | The chart entry point moved to a small icon at the top |
Order placement | Form changes, errors, completion | No reported change |
Order status and holdings | Visibility and successful updates | No reported change |
The chart was relocated, not removed. That distinction matters because the likely problem is discoverability.
A user who previously found “View chart” beside a security’s details now has to recognise a small icon elsewhere. Some may assume the feature is unavailable or switch to another tool.
5. Test whether chart discoverability explains the decline
My leading hypothesis would be:
Moving the chart entry point made it harder to find, reducing chart usage and causing some users to fall below the 15-minute activity threshold.
I’d test that against alternatives.
Hypothesis | Evidence that would support it |
|---|---|
Users cannot find the relocated chart | Chart opens fall, time to open rises, and usability sessions show confusion |
The chart has a technical issue | Users tap the icon, but loading failures or crashes increase |
Time tracking misses the new chart view | Chart activity remains healthy while recorded foreground time falls |
Users complete their tasks faster | Session duration falls while task success and satisfaction remain stable |
Users move chart analysis elsewhere | App sessions shorten alongside increased web chart usage or reported use of other tools |
I’d compare users exposed to the change with comparable users on the previous version. I’d also check whether people who frequently used charts before the release show a larger decline.
The release timing should align with the drop. If it does not, I’d continue investigating rather than force the explanation.
6. Examine external factors and changing behaviour
I’d use PESTEL to check political, economic, social, technological, environmental, and legal factors without giving every possibility equal weight.
That would include market conditions, regulation, competitor changes, negative publicity, service disruptions, strikes, and unusual events. I’d also consider changes in work routines, disposable income, or interest in investing.
The case introduces a long-term capital gains tax increase as a possible influence. I’d treat this as a scenario assumption and investigate its behavioural impact.
However, I wouldn’t immediately call it a second root cause. A tax change does not directly explain why iOS users are disproportionately affected. Its relevance may also differ between long-term investors and daily traders.
I’d compare similar investing cohorts across iOS, Android, and web. A broader decline among long-term investors could support the tax hypothesis. A decline concentrated among iOS chart users would support the interface hypothesis.
7. Address the strongest supported cause
If the evidence confirms a discoverability problem, my immediate action would be to restore the familiar chart entry point or add a clear, labelled shortcut near the security details.
I’d verify that the chart opens reliably and that its usage is measured correctly. A brief contextual cue could help users find it, but I’d avoid relying on instructions to compensate for an unclear interface.
For the longer term, I’d:
Test alternative placements with both new and experienced users.
Measure whether users can find and open charts successfully.
Roll out changes gradually with task-success and retention checks.
Monitor important workflows by app version.
Reassess whether the 15-minute definition is a useful headline measure of activity.
If external changes are affecting users, I’d investigate their information needs separately. The product goal should be helping users make informed decisions and complete intended tasks, rather than encouraging more trading to increase engagement.
8. Measure recovery
I’d retain the original 15-minute DAU metric to track whether the reported decline recovers, but pair it with more direct measures:
Successful chart access among users trying to view charts.
Time taken to find and open a chart.
Chart-loading failures and crashes.
Daily logged-in users and the distribution of session duration.
Return usage among previously affected users.
Task satisfaction and chart-related support contacts.
App updates and feature adoption would tell me how many users received or used the fix. They would not establish that the problem was solved.
My leading diagnosis is reduced chart discoverability following the iOS redesign. I’d validate it through chart behaviour and rollout timing, restore clear access if confirmed, and measure recovery in both the original metric and users’ ability to complete their tasks.