Shopify does not share another developer's install data. Your Partner Dashboard and the app/uninstalled webhook cover your own app only. To see competitor installs and removals, you observe public storefronts over time: when the code a competitor's app places on a store appears or disappears between two scans, that is an observed install or removal on that date.
That observation is useful, but it is not a confirmed purchase, cancellation or switch. This guide covers what the data can answer, how to set up a watchlist, how to tell a removal from a replacement, and how to act on it without overreaching.
Questions install and removal data can help answer
| Question | What to look at |
|---|---|
| Which merchants run a competitor today? | Current detections for each competitor app |
| Which merchants recently stopped running a competitor? | Detected removals in the last few weeks |
| Which merchants just entered my category? | First-time installs of any app in the category |
| Is a competitor gaining or losing in a segment I care about? | Installs versus removals over time, filtered by vertical, country or plan |
| Which of my prospects are already committed elsewhere? | Overlap between your prospect list and competitor detections |
| Which of my own customers also run a competitor? | Overlap with your install base (see monitoring your install base) |
Treat movement totals as directional. A change in how well an app is detected can look like a change in how many merchants use it.
How storefront detection works, and what it cannot see
Many apps add something to the storefront: an app block or app embed through a theme app extension, a script, or a pixel. Those leave public traces in a store's pages. A scanner reads those traces, maps them to apps, and compares each scan with the previous one.
That method has real limits. Know them before you build a process on top of it.
- Backend-only apps are invisible. Apps that work only in the Shopify admin (many accounting, tax, fulfillment and reporting tools) leave nothing on the storefront to detect. For those categories, App Store reviews are often the only public signal.
- Dates are observation dates. A removal is dated when a scan first noticed it, which can be days or weeks after it happened, depending on how often that store is re-scanned.
- Installed is not the same as active. App embeds can be installed but switched off in the theme editor. A merchant can also install an app without paying for it, for example on a free plan or a trial.
- Leftover code can linger. Some apps leave code in a theme after uninstall, which can delay a detected removal.
- Pasted code is not an install. A vendor snippet added to a theme by hand looks similar to an app in some cases.
- Theme changes create noise. A new theme can drop app blocks without the app being uninstalled. Redesigns often produce several apparent removals at once.
- Failed page loads. A store that is down, password-protected or slow during a scan can look like it lost apps. Good systems confirm a removal across more than one scan.
- Headless storefronts may not expose the same traces at all.
Ask any data source you evaluate how it handles these cases, especially temporary failures and detection improvements that suddenly "find" an app on many stores at once.
Build a competitor watchlist
A watchlist is the set of apps whose installs and removals you want to see. Build it in tiers so you can prioritize.
- Direct competitors. Apps a merchant would replace with yours. Usually 3 to 10.
- Partial competitors. Suites or adjacent apps that include your feature as one part, for example a marketing platform with a basic reviews module.
- Complementary apps. Apps your best customers also run. Installs here can indicate a new fit, not a competitor loss.
- Your own app. So you can see overlap with competitors inside your base.
Review the list every quarter. New apps enter every category, and merchants' alternatives change faster than most teams update their lists.
Distinguish a detected removal from a confirmed replacement
This is the most important judgment in the workflow. A removal says something left the storefront. It says nothing on its own about why.
| What you observe | What it may mean | Confidence it is a switch | Suggested handling |
|---|---|---|---|
| Competitor removed, nothing else changed | Paused, testing, redesign, cost cutting, or leaving the category | Low | Note it; contact only if fit is strong |
| Competitor removed, several other apps also removed around the same time | Theme change, rebuild or replatform | Low for a switch, high for a broader change | Investigate the store before contacting |
| Competitor removed, another app in the same category added | Likely replacement | Medium to high | Usually too late to win this round; note for later |
| Competitor removed, no replacement in the category after a few weeks | Possibly evaluating or doing without | Medium | Good candidate for outreach |
| Competitor removed and a recent negative review of it from this merchant | Dissatisfaction is plausible | Medium to high | Strong candidate; reference the topic, not the review |
| Competitor added | New entrant to the category or a switch away from another app | Not applicable | Usually deprioritize while they onboard |
A removal is only a confirmed replacement when another app in the category is detected on the same store, or when the merchant tells you. Do not assume that a removal means dissatisfaction, or that an install means a paid subscription.
Prioritize by fit, recency and supporting evidence
Use three questions, in this order:
- Fit. Does this merchant match your customer profile? If not, stop. A perfect signal on a poor-fit store is still a poor-fit store.
- Recency. How recently was the change observed? Merchants mid-change are more open to a conversation than merchants who settled months ago. Many teams act on changes observed in the last two to four weeks.
- Supporting evidence. Is there more than one observation? A removal plus a negative review, a Plus upgrade, or a relevant job opening is a stronger reason to reach out than a removal alone.
A simple rule set works for most teams:
- Contact this week: strong fit, observed in the last 14 days, at least one supporting observation.
- Contact this month: strong fit and recent, but a single observation.
- Watch: weaker fit, older change, or a likely replacement already in place.
The buying signals reference includes an example scoring approach if you want something more structured.
Turn signals into respectful outreach
Merchants know their storefront is public. They still do not want to feel watched. Write about their situation, not your data.
- Lead with the likely task, such as migrating data or comparing options, not with the fact that you noticed.
- Never state a reason you cannot know. "Since you weren't happy with X" is a guess, and it reads as one.
- Offer something useful even if they do not buy: a migration checklist, an export guide, a short comparison of approaches.
- Keep the ask small.
Illustrative example for a removal with no replacement yet:
Hi [Name], if you're reviewing [category] tools at [Store], one thing worth checking before you choose is whether your existing [data type] can be imported. Some apps make that easy, others don't. Here's a two-minute checklist we put together. Happy to answer questions either way.
Illustrative example for a likely replacement already in place: usually, do not send a sales message. Log the account and revisit in a few months, when the new tool's limits may be clearer.
For broader outreach structure, see how to find customers for your Shopify app.
Track outcomes
Log every signal you act on with:
- Signal type (removal, removal plus review, install, and so on)
- Date observed and date contacted
- Contact role
- Outcome: no reply, reply, qualified conversation, trial or install, paid
- Whether the signal turned out to be wrong (for example, the app was never removed)
Review this monthly. You are looking for which signal types and which time windows produce qualified conversations for your category. Report incorrect signals back to your data provider so they can be corrected.
Where Alert fits
Alert observes public Shopify storefronts on a rolling basis and turns app changes between scans into dated events. For this workflow, it helps with:
- The watchlist: add the competitor apps you track, with no cap on the number.
- Detection: App Moves lists installs and uninstalls detected per store and dated. A removal is confirmed across repeat scans, so a single failed page load does not register as an uninstall, and changes caused by Alert's own detection improving are separated from merchant changes.
- Supporting evidence: the Reviews feed shows new reviews on watched apps, flags 1 to 3 star reviews, and shows whether Alert's crawl currently sees that app on the reviewer's storefront.
- Next steps: each merchant carries its detected app stack and, where available, a named contact. Pipeline status and notes are shared across your team.
Install and uninstall events cover apps with a storefront footprint. For backend-only apps, reviews are the available signal.
Start a 14-day free trial and add your competitors to see the stores currently running them.
FAQs
Can I see competitor install numbers in my Shopify Partner Dashboard?
No. The Partner Dashboard and Partner API report on your own apps only. Competitor data has to come from outside observation of storefronts or from public information like App Store reviews.
How quickly is a competitor uninstall detected?
It depends on how often the store is re-scanned and whether the removal is confirmed across more than one scan. Expect a delay between the actual change and the observed date, and treat the date as "no later than."
Does a detected uninstall mean the merchant is unhappy with the competitor?
No. Merchants remove apps during redesigns, while testing, to cut costs, or because they stopped needing the feature. Dissatisfaction becomes more plausible when other evidence, such as a negative review, points the same way.
Can I track competitors that have no storefront code?
Not through storefront detection. For admin-only apps, public App Store reviews, job postings and the merchant's own announcements are the main external signals.
Should I contact a merchant right after they install a competitor?
Usually not. They have just made a choice and are onboarding. Note the account and revisit later unless you have a clear reason that fits their situation.