What to Do When Your Mobile App Is Costing You Revenue and the Team Says It Is Fine

The business side sees a revenue problem. The engineering team sees a healthy app. Both can be simultaneously true and simultaneously misleading, because they are looking at different data.

The business side is looking at transaction volume, conversion rates, and revenue per session. The engineering team is looking at uptime, crash rates, and error logs. These two views of the same app can produce completely different pictures - and both pictures can be accurate, because they measure different things.

Resolving the gap is not an authority question. It is a data question. The right data closes it.

Why the team says fine

"Fine" from an engineering team is almost always an honest answer to a different question than the one you are asking.

You are asking: is the app performing well enough to drive the revenue we expect from it? They are answering: is the app running without visible errors or infrastructure failures?

The second question is easier to answer. Standard monitoring tools - uptime dashboards, crash reporting, error logs - provide a real-time answer. A well-instrumented engineering team can answer the second question in minutes.

The first question requires a different instrumentation layer: product analytics that track user behaviour at step level, conversion rates through the funnel, session completion rates, and the correlation between user actions and business outcomes. This instrumentation is often not in place, because it requires deliberate setup and ongoing maintenance, and it sits in the gap between engineering metrics (is the app working?) and business metrics (is the app producing revenue?).

When that instrumentation is absent, the team gives the honest answer to the question they can answer: the servers are up, the crash rate is within normal range, no deployments introduced obvious errors. Fine.

What fine actually means

Fine means: no alerts have fired in our monitoring system. It does not mean: we have checked the conversion rate on the checkout flow and it matches our benchmark. It does not mean: we have confirmed that load times on the payment screen are under 1.5 seconds. It does not mean: we have looked at the funnel and identified where users are leaving.

Fine is a negative claim - no visible problems - not a positive one - everything is performing to standard. The gap between these two claims is where revenue problems hide.

An app can have a payment screen that takes 3 seconds to load, consistently causing 20 percent of users to abandon before completing - and that problem will not show up in uptime monitoring, crash reporting, or error logs. It will show up in conversion data, if conversion data is being tracked.

The data that resolves the gap

Four data points close the disagreement.

Step-level funnel conversion. What percentage of users complete each step of the transaction flow? Where does the completion rate drop significantly between one step and the next? This data exists in your product analytics platform if one is instrumented. If it is not, it can be pulled from your analytics provider's raw event logs.

Step-level load time. How long does each step in the transaction flow take to display to the user? P75 load time - the time at or below which 75 percent of users experience the step - is the relevant metric. Above 2 seconds at a critical step, conversion impact is measurable.

Crash-free session rate by screen. What percentage of sessions that reach a specific screen complete without a crash or silent error? A crash-free session rate of 97 percent sounds healthy overall but means 3 in 100 users encounter a failure - that is 3,000 users per 100,000 sessions.

Revenue per session trend. Is revenue per session stable, declining, or growing? If declining, when did the decline start? A decline that correlates with a specific app release is a technical cause. A decline that predates any recent release is either structural or external.

How to ask for it

Ask your vendor for a single report: step-level conversion rates for the transaction flow for the last 90 days, alongside p75 load times for each step, and the crash-free session rate for each screen in the flow.

A vendor with proper instrumentation can produce this report in under a day. A vendor that does not have this data - that cannot show you step-level conversion alongside load time data - is not in a position to tell you the app is fine. Fine requires measurement.

If the vendor says the data is not available, ask why. The answer tells you something important: either the app was built without product analytics instrumentation, the instrumentation exists but the vendor has not been tracking these metrics, or the vendor does not want to share data that would show a problem. Each of these answers changes the conversation.

What to do if you cannot get it

If the vendor cannot or will not provide step-level performance data, get direct access to the analytics platforms yourself. App Store Connect and Google Play Console provide session data, crash rates, and performance metrics directly. If the app has a product analytics integration - most do - ask for read-only access to the analytics platform account.

If the vendor controls all analytics access and will not provide it: the data belongs to your users and your business, not the vendor. A vendor that withholds performance data is not a vendor that is managing your app in your interest.

With direct access, you can answer the question yourself. Run the four-metric diagnostic. If the data shows a healthy conversion rate and acceptable load times, the revenue problem is outside the app - and the product discussion is the right next step. If the data shows a funnel break, the conversation with your vendor just became very specific.