An ecommerce app business case should answer one question: what could the app add to the business after accounting for what those customers would have done anyway?
If an existing customer moves a $100 order from your mobile website into the app, the app records $100 in revenue. But it has not necessarily created $100 in additional revenue.
A credible ROI model separates total app revenue from the incremental value created through higher conversion, larger orders, more frequent purchases or lower communication costs.
You will never forecast this perfectly. The goal is to make the assumptions visible, test whether the project works under conservative conditions and identify the numbers you need to measure after launch.
The Short Version: How to Calculate Ecommerce App ROI
Build the model in five steps:
- Define the commercial goal and the customers the app is meant to serve.
- Estimate how many of those customers will install and actively use it.
- Calculate what the same audience would generate on mobile web.
- Model the incremental change in conversion, order value or purchase frequency.
- Subtract the full cost, then test conservative, expected and strong scenarios.
The standard ROI formula is:
ROI = (incremental value - total cost) / total costIf the app creates $120,000 in incremental gross profit over a year and costs $60,000 to launch and operate, the ROI is 100%.
Notice that this example uses incremental gross profit, not just revenue. A dollar of sales is not a dollar of return.
Start With the Job the App Needs to Do
Do not begin with a generic claim that “apps convert better.” Start with the commercial problem you expect the app to solve.
The app might be intended to convert more returning mobile shoppers, increase order value or encourage another purchase. It could make loyalty and subscriptions easier to use, recover more abandoned carts or reactivate customers without relying as heavily on paid retargeting and per-message SMS.
Choose a small number of measurable goals. If the forecast credits the app with every possible benefit, it becomes impossible to tell which assumptions are doing the work.
The goal also affects the audience. An app built to support VIP loyalty members should not be modeled against every anonymous website visitor. A replenishment app should focus on customers who buy products with a natural reorder cycle.
Estimate the Addressable App Audience
Not every website visitor will install the app, and not every install becomes an active user.
Start with people who have a plausible reason to download. Existing customers, returning mobile visitors, loyalty members and subscribers are the obvious groups. Regular purchasers and highly engaged email, SMS, social or community audiences may also be realistic targets.
Then model the funnel:
Reachable audience × install rate × active-user rate = active app usersFor example, imagine a brand can meaningfully promote the app to 100,000 existing customers in the first year.
If 12% install it and 70% of installers remain active over the period being modeled, that produces 8,400 active users:
100,000 × 12% × 70% = 8,400 active app usersThese are illustrative assumptions, not benchmarks. Replace them with first-party data wherever possible.
Use a monthly adoption ramp rather than pretending all users appear on launch day. Downloads usually build over time as the brand promotes the app across the website, email, SMS, packaging and other customer touchpoints.
Establish the Mobile-Web Baseline
The baseline is what your likely app users would have generated without the app.
For a simple commerce model, you need the number of active users or shopping sessions, the mobile-web conversion rate and the mobile-web average order value.
The baseline formula is:
Equivalent mobile-web revenue
= active users × purchase opportunities per user × mobile-web conversion rate × mobile-web AOVIf you model monthly active users, use monthly purchase opportunities and calculate the result month by month. If you use annual customer purchase frequency, keep the rest of the model annual.
Consistency matters more than complexity. Mixing monthly traffic with an annual purchase rate is an easy way to produce an impressive but meaningless number.
Use data for returning mobile customers if you can. App users are usually more engaged than the average anonymous mobile visitor, so comparing them with the site’s blended conversion rate can exaggerate the app lift.
Model the App Scenario
Now estimate how the same audience might behave in the app.
The simplest model changes two inputs: conversion rate and average order value.
You can then calculate:
Estimated app revenue
= active app users × purchase opportunities per user × app conversion rate × app AOVAnd:
Incremental commerce revenue
= estimated app revenue - equivalent mobile-web revenueThis is still a model, not proof of causation. People who download an app may already be more loyal and more likely to buy. That selection effect is another reason to use cautious assumptions and validate them after launch.
A Worked Ecommerce App ROI Example
Imagine an established brand expects to average 10,000 active app users during the first full year.
For a simplified model, assume each active user creates one meaningful shopping opportunity per month.
Mobile Web Baseline
Use 10,000 users, 12 monthly shopping opportunities, a 3% conversion rate and an $80 average order value.
10,000 × 12 × 3% × $80 = $288,000Without the app, the equivalent audience would generate an estimated $288,000 in mobile-web revenue.
App Scenario
Keep the same 10,000 users and 12 monthly opportunities, but model a 4% conversion rate and an $84 average order value.
10,000 × 12 × 4% × $84 = $403,200The app records $403,200 in revenue. The model attributes $115,200 of that to incremental improvement:
$403,200 - $288,000 = $115,200 incremental revenueIf the brand’s contribution margin on that revenue is 45%, the estimated incremental contribution is:
$115,200 × 45% = $51,840Now compare that with the app’s total annual cost.
If setup, platform fees, internal time, promotion and supporting tools total $36,000:
($51,840 - $36,000) / $36,000 = 44% ROIUnder these assumptions, the first-year ROI is 44%.
The example is deliberately simple. It shows the logic, not a result you should copy into your own business case.
Revenue Is Not the Same as Profit
Using incremental revenue in the numerator overstates the return if fulfilling those orders has a meaningful cost.
A better model applies a contribution margin after product costs, discounts, payment fees, fulfillment and other variable expenses.
For example:
Incremental contribution
= incremental revenue × contribution marginYou can then add any genuine cost savings, such as avoided SMS sends or reduced paid reactivation spend, before subtracting the total app cost.
Be careful not to count the same benefit twice. If increased repeat purchasing is already reflected in the number of shopping opportunities, do not add a separate “retention lift” on top without a distinct basis.
How to Model Retention and Purchase Frequency
Conversion rate is not the only way an app can create value.
For many brands, the more important outcome is another purchase over the course of a year. The app keeps the brand accessible, makes account or loyalty benefits easier to use and gives the team a direct re-engagement channel through push.
If you have reliable purchase-frequency data, you can model customers rather than sessions:
Annual revenue per customer
= orders per customer × average order valueThen compare expected annual value for an equivalent customer cohort with and without the app.
This model is useful for replenishment, subscription, fashion, beauty and other categories with repeat-purchase potential. It is less useful when purchases are naturally several years apart.
Keep the assumption modest. Moving a cohort from 2.0 to 2.2 orders per year may create a meaningful return at scale. You do not need to assume the app transforms every customer into a monthly buyer.
Give Push Notifications Their Own Case
Push can create revenue and reduce the cost of reaching customers, but its value often overlaps with the core model.
A push campaign may increase app sessions, which then show up as more purchase opportunities or a higher observed purchase rate. Adding the entire campaign revenue again would double-count the benefit.
Keep push as a separate test or upside case unless you have enough data to isolate it.
Measure the opt-in rate and reachable audience first, then follow the path from delivery to opens, sessions and conversion. A holdout group can show the incremental lift more credibly.
You can also compare the cost with an equivalent SMS send. Watch opt-outs and uninstall signals alongside revenue so a short-term campaign result does not hide damage to the channel.
The strongest measurement uses a control group that does not receive the campaign. Comparing recipients with non-recipients helps distinguish the effect of the message from purchases that would have happened anyway.
Include the Full Cost of the App
The subscription or development quote is only part of the investment.
Include setup, design and development along with ongoing platform fees, hosting, revenue share and integration work. Add the internal time required to launch and operate the app rather than treating it as free.
The complete budget should also cover developer accounts, creative production, download incentives, push and analytics tools, maintenance, compatibility updates and future releases. Allow for eventual migration or exit costs as well.
Use the same time period for costs and benefits. A three-year view is often more informative because upfront development and setup costs are concentrated near launch while adoption builds gradually.
Our guide to ecommerce mobile app costs explains how these costs differ between self-service builders, managed services and custom development.
Build Three Scenarios
One forecast creates false confidence. Use at least three.
| Input | Conservative | Expected | Strong |
|---|---|---|---|
| Adoption | Slower than planned | Defensible central case | Strong promotion and uptake |
| Active-user rate | Meaningful drop-off | Based on comparable channels | High continued engagement |
| Performance lift | Small improvement | Evidence-based target | Strong but plausible result |
| Launch timing | Includes delay | Current project plan | Smooth delivery |
| Cost | Includes contingency | Expected total | No major overrun |
The conservative case is the most important. If the project only works when adoption, conversion and order value all land near the top of the range, the business case is fragile.
A useful model also shows which variable has the biggest effect. For one brand, it may be adoption. For another, the deciding factor may be revenue share, internal workload or a small change in repeat-purchase rate.
Calculate Payback, Not Only ROI
ROI tells you how much value the project creates relative to its cost. Payback tells you when cumulative value recovers the investment.
An app can have an attractive three-year ROI and still require a large upfront payment that takes 18 months to recover.
Calculate the model month by month:
- Ramp active users as promotion builds.
- Estimate monthly incremental contribution and cost savings.
- Subtract setup and ongoing costs in the month they occur.
- Track the cumulative total.
- Identify the first month in which the cumulative figure becomes positive.
This makes cash-flow requirements and launch delays visible.
Add the Operating Plan to the Business Case
The spreadsheet only works if someone executes the strategy behind it.
The business case should identify the target customer, the reason to install and the channels that will promote the app. It should name the people responsible for merchandising and push, along with the integrations and analytics required to run the plan.
It should also define the metrics that determine whether to expand, change or stop the investment.
For example, an adoption forecast based on reaching 100,000 customers is not credible if the launch plan consists of one email and an app-store listing.
Likewise, a forecast that depends on push-driven repeat purchases needs a campaign owner, a messaging plan and useful reasons to contact customers.
How to Measure ROI After Launch
Replace assumptions with observed data as quickly as possible.
Track the path from app-promotion impressions to store-page visits, installs and registration. Then measure active use, push permission, shopping activity, purchases and contribution.
Retention and uninstall signals show whether the app continues to earn its place after the initial download.
Compare app customers with an appropriate mobile-web group, not the site’s entire visitor base. Where possible, use cohort analysis, pre- and post-launch behavior, controlled campaigns and holdout groups.
No method will remove every selection bias. The customers most likely to install may also be the customers most likely to spend. Be clear about what the data proves and what remains an inference.
Review the model regularly. If adoption is strong but activity is weak, the problem may be the app experience or value proposition. If performance is strong but adoption is low, distribution may be the constraint.
When Does an Ecommerce App Have a Strong Business Case?
The case becomes stronger when the brand has a meaningful base of existing customers, high mobile traffic and regular repeat purchases or product launches. Customers need a clear reason to install, and the brand needs channels capable of driving those downloads.
Push should have a useful role beyond generic promotion. Healthy contribution margins and an app approach whose total cost fits the opportunity make the economics more forgiving.
It becomes weaker when the store has little traffic, low repeat-purchase potential, no promotion plan or an app cost that requires unrealistic adoption and performance.
An app can still support less frequent categories through loyalty, content, services or account functionality. But the ongoing reason to use it needs to be clear.
Final Thoughts
A good ecommerce app ROI model does not try to make the largest possible number.
It shows what must be true for the app to become worthwhile.
Start with the customers most likely to use it. Calculate what they already generate. Model a cautious improvement, convert incremental revenue into contribution and include the full cost of operating the channel.
Then pressure-test the result.
If the conservative case is acceptable and the operating plan can realistically produce the required adoption, the app has a credible business case. If the forecast only works by counting all app revenue as new or stacking several optimistic lifts together, it needs another pass.
