# How to measure whether an app adds value, not just moves web orders > App revenue is only part of the answer. Assess total customer value, channel displacement and costs before calling a commerce app a success. - Author: Neha - Published: 2026-09-10 - Category: Guides - Canonical: https://www.arclift.ai/blog/measure-incremental-app-value An existing customer buys their next order in your app instead of on your website. The app dashboard records revenue. Your business may have gained nothing beyond a different checkout location. That doesn’t make the app a bad investment. A clearer subscription account, a useful program or an easier reorder may be worth building. It means the investment needs a better test than adding up app orders. This guide proposes that test; it reports no measured Arclift lift. The linked concepts are fictional, local demonstrations of journeys you could evaluate. Explore the Concept: [Subscription Stack](/concepts/subscription-stack#manage) [Daily Routine](/concepts/daily-routine#use) [Training Companion](/concepts/training-companion#reorder) ## App revenue is not the same as added revenue Attribution assigns credit to observed activity. Incrementality asks whether an intervention changed the outcome. Google’s measurement guidance makes that distinction explicit. For a commerce app, the practical question is what customers would have done without the new experience, not which screen received their payment. Imagine an app launch accompanied by a discount and a prominent email campaign. App orders rise. Some may be new purchases, some may replace web orders, and some may have happened later without the discount. Treating the entire total as added revenue combines different effects under one attractive number. Start with a written decision: are you testing whether an invitation strategy creates more valuable customer relationships, whether a particular app feature helps existing users, or whether the whole app program earns its costs? These questions need different comparisons. Decide which one will influence your next investment before choosing the dashboard. Source: [Google: Marketing measurement tools](https://business.google.com/aunz/think/marketing-strategies/media-measurement-tools/) ## Build a customer view across channels For this evaluation, propose a customer-level view of completed orders across app and web. Keep refunds, cancellations, discounts and delivery costs visible. Define the observation window in advance around your business’s purchase cycle rather than ending it when the chart looks good. Your app analytics can explain the journey. Your order system should establish what was actually purchased. Agree which system owns order identity, how refunds update the record and how a customer appearing in both channels is matched. Count an order once, even when more than one tool claims it. Incomplete matching is a measurement limitation, not permission to assign unmatched orders to the channel you prefer. Report its extent. Keep guest orders and unmatched activity visible as separate unknowns. An honest uncertainty range is more useful than a precise-looking total built on inconsistent identities. ## Test an invitation, not a self-selected audience Comparing app installers with non-installers is tempting. It also leaves a basic question unanswered: were the installers already your most committed customers? Their later spending cannot, by itself, tell you what the app changed. One possible design is to randomly assign eligible customers to an app invitation or the existing experience. Keep assignment stable, define the main outcome beforehand and plan the sample size and duration with someone who understands your order variability. These are established controlled-experiment principles, not a claim that a small store can obtain a reliable answer from any short test. Compare the assigned groups, including invited customers who never install. Otherwise you reintroduce selection by keeping only the people who responded. Record customers in the comparison group who find the app independently. The result estimates the effect of the invitation strategy under those conditions; it does not isolate the effect of possessing an app from the message, incentive or other changes accompanying the invitation. If you cannot run a useful randomized test, a before-and-after review can still inform decisions. Describe it as observational. Record promotions, stock shortages, price changes and seasonality, and avoid presenting an association as proof of added revenue. Insufficient evidence is a legitimate result. Source: [Controlled experiments on the web: survey and practical guide](https://exp-platform.com/Documents/controlledExperimentDMKD.pdf) ## Measure the job the app does The app needs a job more specific than generating opens. In the QUIET / HOURS Subscription Stack, the proposed job is resolving a payment hold while keeping pause, cancellation and delivery choices separate. In its Daily Routine, it is organizing products in the customer’s chosen time slots and keeping that saved plan editable. In DAILY / FORM, it is returning to a program and managing supply between orders. These concepts demonstrate interactions, not live retention outcomes. For subscription self-service, evaluate whether a customer can understand their current status and successfully make the intended change. For a routine, separate opening the planner from completing a useful task. For a program, distinguish viewing a session from returning to continue it. Pair these journey measures with business outcomes; none is a substitute for them. Subscription Stack only resolves an authored payment state on the page. It does not process a charge or establish recovered revenue. Its more useful local checks are whether a pause survives payment recovery, whether cancellation stops the displayed schedule and whether editing contents preserves the customer’s account status. A successful cancellation is a completed customer task, not a failed retention measure. Daily Routine records self-reported check-ins, not verified product use or adherence. Test whether saved choices survive an unsaved edit, whether a check-in can be undone and whether shopping opens the intended product and quantity for review. Supply estimates stock and time; Subscription handles billing; Routine keeps a customer-defined plan. Activity in one does not establish success in the others. After installation, a feature experiment answers a narrower question. Firebase’s A/B Testing documentation describes comparing app variants against a baseline using a primary metric and supporting metrics. That can inform a reminder or navigation change among participating app users. It does not establish whether introducing the app generated additional orders across the business. Source: [Firebase: Create Remote Config experiments](https://firebase.google.com/docs/ab-testing/abtest-config) ## Count costs and consequences Revenue is not the final investment measure. Define a contribution view with your finance owner: what remains after product, fulfillment, discounts, returns and other relevant variable costs? Then account for app development, maintenance, platform services, content operations and support in the investment decision. Keep the accounting assumptions explicit rather than hiding them in a single return percentage. Also choose safeguards. An easier reorder is not a success if it creates more accidental purchases or support requests. A reminder that increases short-term orders may still be unsuitable if customers repeatedly disable it. A cancellation flow should complete the customer’s requested action, not appear successful because fewer people can find the exit. Avoid changing every variable at once. If you redesign the website, change subscription pricing and launch the app together, the commercial result belongs to the combined program unless your evaluation can separate the effects. ## Make the next decision smaller Before commissioning a full app, choose one recurring customer task and make it tangible. Explore a delivery editor, a daily plan or a program-to-reorder flow. Check that it is understandable, that its state is truthful and that customers would have a reason to return. A prototype can answer those design questions; it cannot establish revenue lift. Then write the launch decision in plain language: the customer group, the change being tested, the all-channel outcome, the costs to include and the conditions under which you would continue, revise or stop. Agree those conditions before results arrive. Bring your current customer journey and the decision you need to make. We can discuss a focused prototype and a measurement plan suited to that decision. An app should earn its place in your business, not just its own revenue column. ## Your brand’s next step [Mobile Membership & Repeat Purchase](/services#apps) [Start a Conversation](/contact?service=apps&example=subscription-stack) ## Related reading [Resolve payment without undoing a pause](/blog/subscription-stack-concept) [A daily plan the customer puts together](/blog/daily-routine-concept) [Build an app customers use between orders](/blog/training-companion-concept)