Reduce Shopify app uninstalls: why merchants leave and what to fix

In short: The Shopify app uninstalls you can prevent mostly happen in the first week, before the merchant has seen a result in their own store. To reduce them, get every new install to one visible outcome in the first session, read the uninstall reasons in your Partner Dashboard every week, strip out the uninstalls that were never about your app, and track retention by install cohort instead of one blended churn number.

Why do merchants uninstall Shopify apps?

I spent close to two years in customer success at Social Snowball before I moved into product design, first supporting over 1,000 brands launching affiliate programs, then leading the CS team. The uninstall reasons I read there fell into five buckets.

No result in the first session. The merchant installs, lands on a settings page, clicks around, and nothing has changed in their store. For an affiliate app, a result is a live program with a link the merchant can send to a customer. For a reviews app, it is the first review request sent. If the first session ends on a settings page, the app is already in trouble.

Setup takes too long. A theme app embed to switch on, a Klaviyo account to connect, commission rates to decide, an email to customise. Every step the merchant has to finish before seeing anything is a chance to leave. Most merchants run the store alone, and your app is one of thirty open tabs.

Price does not match the value they can see. The trial ends or the first usage charge lands, and the merchant cannot point to a number the app produced. Shopify's uninstall reason list includes "Too expensive", and in my experience merchants pick it when they mean "I cannot see what I paid for." The fix is usually a visible result, not a lower price.

Duplicate tools. The merchant installed three apps in the same category to compare them, or a new hire audited the billing line items and found two apps doing the same job. Shopify now lists "Testing multiple apps" as a reason, and it tells you something about your listing and your first session, not your feature set.

Theme conflicts and bugs. The widget did not render on their theme, the cart broke, the storefront slowed down. This is the reason that costs you reviews as well as installs, because a broken store is the one thing a merchant will write about publicly.

Then there is a sixth group that is not about you at all: stores closing, pausing for the season, or shut down by Shopify. Count those separately, which I cover below.

What does the app/uninstalled webhook actually tell you?

You subscribe to it in your app configuration. Shopify's webhook getting started guide shows the subscription as topics = ["app/uninstalled"] in shopify.app.toml, and the sample config points the topic at a handler route.

The payload is a shop object: shop id, name, email, domain, plan name, shop owner. It does not include the reason, or when the merchant last used your app. It is a notification that a store has gone, nothing more.

Two things to build into the handler:

• Shopify's webhooks overview says plainly that "Webhook delivery isn't always guaranteed", and tells you to verify the HMAC signature and ignore duplicate deliveries using the X-Shopify-Webhook-Id header. So treat the webhook as the fast signal, and reconcile against the Partner Dashboard once a week to catch anything you missed.
• Do not delete the store's data in the handler. Shopify's privacy law compliance page says the shop/redact webhook is sent 48 hours after a store owner uninstalls your app, and that you must complete the redaction within 30 days of receiving it. Mark the shop as uninstalled with a timestamp, stop billing and background jobs, keep the record, and let shop/redact do the erasing.

The handler should also post the uninstall to a channel your team reads, with the shop name, plan, days since install, and last meaningful action in your app. That one message turns a database row into something a person can act on within the hour.

Where the uninstall reason lives

Since April 2026, Shopify requires merchants to pick a reason before an app is removed. The changelog entry lists the options: testing multiple apps, store is closing or pausing, not using app now, not satisfied with app features, not satisfied with customer support, too expensive, not working properly with store, and other with a free text field.

Those reasons show up in your Partner Dashboard, not in the webhook, so someone has to open the dashboard and read them. Weekly is enough. Here is how I read each one.

Reason the merchant picked	What it usually means	First thing to check
Testing multiple apps	Your listing or first session did not separate you from the next app	Time from install to first result
Not using app now	They set it up and never came back	Was the key integration ever connected?
Not satisfied with app features	A specific job they could not do	Read the free text, then check support tickets from that shop
Not satisfied with customer support	A ticket went unanswered or unresolved	Pull every ticket from that shop in the last 30 days
Too expensive	They could not see what the app produced	Did the app ever show them a result in their own numbers?
Not working properly with store	Theme conflict or bug	Which theme, which page, which browser
Store is closing or pausing	Not about you	Exclude from your churn rate

The free text under "Other" is the most useful field in the dashboard. Read every one.

Which uninstalls should you not count?

A Shopify staff member explained in a developer community thread that when a merchant schedules the cancellation of their store, Shopify now uninstalls third-party apps as part of that process, and those show up with a scheduled_cancellation reason in app analytics. The same staff member suggested filtering them out of your churn metrics to get an accurate picture of voluntary uninstalls. Do that. Treat "Store is closing or pausing" the same way.

Then split what is left by how long the merchant had the app:

• Under 7 days. An onboarding problem. The merchant never got to a result. This is where most of the fixable uninstalls sit, and the fix is in the product, not in a win-back email.
• 7 to 30 days. A value problem. They saw the app work and decided it was not worth the plan. Look at what they did in week two, and whether the app ever showed them a number.
• Over 30 days. A change problem. A new theme, a new tool, a new owner, a bad support experience, a season ending. These are worth a personal email, because the merchant knows your app and can tell you exactly what changed.

A blended uninstall rate hides all of this. Three cohorts tell you where to work.

The first-week playbook

This is the sequence I would put in front of any new install, built for the small team most Shopify apps have.

Day 0, first session. Define one result the merchant should see before they close the tab, and build the first screen around it. Not a settings page or an eight-item checklist, one result. I wrote more about how to design that path in the guide on Shopify app onboarding.

Day 1. If the one integration that makes the app work is not connected, send one message about that one thing. Theme embed not enabled, Klaviyo not connected, no product chosen. One message, one link, one job. Not a five-email drip.

Day 2 to 3. A human check-in for every install on a paid plan. A short message from a named person asking what they are trying to get done. When I ran support at Social Snowball we kept median first response under 10 seconds, and that mattered most in this window. A merchant who hits a wall during setup leaves if nobody answers, and usually without filing a ticket.

Day 5 to 7. Show the first number, even a small one. Two affiliate signups, one review request opened, three products synced. An empty state buys you a few days. A number buys you a month.

Uninstall day. Webhook fires, alert posts, and one person sends one email within the hour asking a single question: what were you hoping the app would do? No discount, no template. The replies are the best product research you will get this quarter.

What should you measure?

Look at these weekly.

• Uninstalls by tenure bucket. Under 7 days, 7 to 30, over 30. Excluding scheduled cancellations and store closures.
• Day 7 and day 30 retention by install week. Group installs by the week they happened and track the share still installed. This is the number that moves when you fix onboarding, and it moves for the newest cohort first.
• Reason mix. The share of each dashboard reason, by month. If "Testing multiple apps" is climbing, look at your listing. If "Too expensive" is climbing, look at what the app shows before the first charge.
• Time to first result. Median hours from install to the one result you defined. The target is inside the first session.
• Key integration connected within 24 hours. The share of new installs that connected the thing that makes the app work.
• Reinstalls. The same shop domain installing again. A high reinstall rate means merchants left for a reason you could have removed the first time.

Those same numbers feed a customer health score, and the usage patterns that precede an uninstall are covered in the guide on churn signals.

Where to start

1. Subscribe to app/uninstalled if you have not, and post every uninstall to a team channel with shop name, plan, days since install, and last action.
2. Export the last 90 days of uninstall reasons from the Partner Dashboard, remove scheduled cancellations and store closures, and split the rest by tenure bucket.
3. Write down the one result a merchant should see in their first session, then measure what share of installs actually see it.
4. Watch five new installs go through setup, with session replays or a screen share, and note where each one stalls.
5. Reply personally to every uninstall under 30 days old with a single question, and read the answers together as a team.