The timing split you’re describing is basically what already showed up in the billing study, even though that one wasn’t tracking uninstalls at all. Median 1-star reviewer had been paying 90 days, median 5-star wrote within 30, and a quarter of those within a day of installing. That’s reviews, not exit-survey answers, but it does line up with early churn and late churn looking like genuinely different things rather than the same complaint at different volumes.
Nobody’s actually run the tenure-segmented exit survey here as far as I’ve seen. If someone has, I’d want to see it.
Speaking as someone who builds apps: the early uninstalls are almost never about a missing feature. They are about no first win in the first session. If a merchant installs, sees a setup checklist, and closes the tab without anything live on the storefront, the app is gone in a day or two.
The second reason is listing and product mismatch. The listing promises one job, the app does a slightly different one, and the merchant finds out after install instead of before. That is a copy problem, not a churn problem.
The third is overlap with something they already run. They will not rip out Privy or Klaviyo because your onboarding asked them to. If the first step is replace the popup, you lose. If the first step is sit next to it, you stay.
So the first win should be embed on plus one live campaign, not a 12-step setup.
Disclosure: I built Atomato (Atomato Email, SMS & Upsell - Grow email and SMS lists and upsell from a feed... | Shopify App Store), a shopper-opened notification bell/feed for restocks, drops, and offers. Email/SMS is one card in the feed. It sits next to the popup they already have. We try to get the bell live on the theme the same day so the first win is a campaign in the feed, not another overlay.
I can offer a data point the thread is missing: an actual uninstall, ours, with the post-mortem.
A merchant installed our sync app from an ad, spent under two hours, and left. The reconstruction from logs: the app asked them to connect a second store before showing anything of value, they did not have the second store’s credentials handy, and the screen they were left on was a setup prompt. Nothing was broken. There was simply nothing to look at. Every theory upthread about time-to-value is true, but the sharper lesson for us was: the setup step did not fail, it just existed.
The contrast that taught us the rest: our other app takes a backup automatically on install - by the time the merchant has finished reading the welcome screen, it can already show their own numbers, and its first receipt lands about twelve minutes in with real record counts from their store. Zero setup steps. That one has kept its installs so far.
So my answer to the original question: merchants uninstall when the first session ends without the product having done anything yet. Icey.Lane’s “time to first evidence” is the right metric, with one amendment - the strongest version is evidence that arrived without the merchant doing anything at all. If the product’s nature allows work-before-configuration, do the work first and ask questions later.
Both apps are mine (StoreTwin, StoreVault) - one taught me this the cheap way, the other the honest way.
Hi @KynaatJohn From the developer side - most early uninstalls happen in the first few minutes, usually before the merchant even finishes setup. If they don’t see the result on their store quickly they’re gone. Pricing is rarely the reason at that stage, unless the merchant is just starting out with the store or your app is extremely expensive
Yeah, I’d be really curious to see that too. I think the tenure split could make the data much more useful, because someone uninstalling after a few days is probably dealing with a very different issue than someone leaving after a few months.
It’d be interesting to see whether early churn is mostly about setup/value, while later churn is more related to billing, reliability, or the app no longer being a good fit.
Even a small exit-survey sample could probably reveal some patterns that reviews alone can’t.
Hi @Binaery
I really like the “first win” point. I think that’s an important distinction between onboarding someone and actually showing them the value of the app.
The listing-to-product mismatch is interesting too. If a merchant installs with one expectation and discovers something different after installation, the uninstall can happen before they even get far enough into the onboarding.
And I agree on the overlap point as well. Making an app work alongside the tools a merchant already uses can probably be a much easier sell than asking them to replace something that’s already part of their workflow.
Hi @Ian_Chechin
This is a really good example of the difference between “setup failed” and “setup was the problem.” Nothing was technically broken, but the merchant still had no reason to stay because the app hadn’t shown them anything yet.
I especially like the “first evidence” idea. If an app can do something useful in the background before asking the merchant to configure everything, that seems like a much stronger first-session experience.
The comparison between your two apps is a great example of how removing that initial friction can completely change the experience. “Do the work first, ask questions later” is a pretty powerful principle for onboarding.
Hi @ETRADE_PARTNER
Yeah, that matches what others have been pointing out here as well. Those first few minutes seem to be really important, especially if the merchant can’t see any visible result from the app yet.
I also agree that pricing probably isn’t the main factor at that stage. If the merchant hasn’t experienced the value of the app yet, even a low price won’t necessarily make them stay.
It really seems like getting something useful live quickly is one of the biggest opportunities for reducing those early uninstalls.
Agreed, that’s the real test and nobody’s run it yet as far as I know. All we’ve got is the billing study, and that’s reviews, not installs/uninstalls, so it’s a proxy at best: median 1-star reviewer had been paying 90 days, median 5-star reviewer wrote within 30 (2,797 reviews, 906 apps). Consistent with early and late churn being different problems, but it doesn’t prove it. If someone runs that tenure-segmented exit survey, I’d genuinely want to see it.
Yeah, that’s the interesting part. It would be useful to see whether the reasons really shift by tenure, early churn being more about time-to-value, while later churn is driven by things like reliability, billing, or changing needs.
The review data gives us a good starting point, but an actual exit survey could reveal the missing side of the picture.
That’s exactly the gap review data can’t close. We can see billing complaints pile up around 90 days and five-star reviews cluster near 30 days, but reviews are self-selected — people who bothered to write one. An exit survey would catch the quiet uninstalls that never leave a review at all, which is probably most of them, and split cleanly by tenure instead of us squinting at review timestamps as a proxy. If that survey’s out there I haven’t seen it. Until it exists, what we’ve got shows correlation with a plausible time-to-value story, not the actual mechanism.
Exactly, I think that’s the key distinction. Until we have actual exit-survey data, we can spot patterns in reviews, but we can’t really know what’s driving the silent uninstalls.
Would definitely be interesting to see that data if someone ever runs the survey.
Agreed, that’s the honest ceiling of review data — no way around it without an actual exit survey. If anyone reading this has run one or seen one published, I’d genuinely want to see it too. Until then what we’ve got is a decent proxy for the story, not proof of the mechanism, and I’d rather say that plainly than oversell it.