Churn prediction signals: what shows up before a merchant cancels

In short: The churn prediction signals that matter for an e-commerce app are behavioural and early: a drop-off in the first week, no integration connected, data that stops flowing from the store, support tickets about billing, a frozen or paused store, and the end of a merchant's season. Find your own by comparing churned and retained merchants 30 days before the cancel, then attach one action to each signal.

What is a leading indicator of churn?

A cancellation is a lagging indicator. So is an uninstall, a one-star review and a low NPS score. By the time any of them arrive, the decision was made weeks ago. A leading indicator is something you can see in the product in the weeks before, while there is still time to do something.

For a monthly e-commerce app, "weeks before" is shorter than it is for annual enterprise software. A merchant can be fine on the 1st and gone on the 28th. That is why the useful signals are the ones you can detect automatically, within a day, from events your app already records.

Which signals show up before an e-commerce merchant cancels?

These six come from reading uninstall reasons and cancel tickets across close to two years in customer success at Social Snowball, and from the health score I set up as Head of CS there. Your mix will differ, but I would be surprised if any of them were absent.

1. First-week drop-off. The merchant installs, has one session, and does not come back. This is the largest single source of churn for most apps, and it is invisible if you only look at paying accounts. Userpilot's 2025 product metrics benchmark puts average month 1 retention at 46.9% across 83 B2B SaaS companies, and average activation at 37.5% across 62, from first-party data pulled from Userpilot's own analytics dashboards. The sample is Userpilot's customers rather than e-commerce apps, so treat the numbers as a rough shape, not a target. The shape is the point: most of the loss is early. Detect it with a simple rule, such as no second session within seven days of install, or the activation event never fired.

2. No integration connected. Theme app embed off, Klaviyo not connected, TikTok Shop not authorised, pixel not firing. The merchant did the install but not the connection that makes the app do anything. This is a setup failure, and it usually traces back to a step the merchant did not understand or could not find.

3. Data stopped flowing. Different from signal 2. The integration was connected and working, then orders stopped syncing or affiliate clicks went to zero for two weeks. Common causes: a theme change that dropped the embed, a store migration, an expired token, a redesign that removed the widget. The merchant often has not noticed, which means the first they hear of it is the invoice.

4. Support tickets about billing. "Why was I charged?", "How do I downgrade?", "Can I pause this?", "What does the Pro plan include again?" Each is a merchant doing the maths on your app. Tone shifts count too: a ticket that was friendly and turns short, or a thread the merchant stops replying to while the problem is unresolved.

5. A frozen or paused store. If you bill through Shopify, the subscription status is a signal in its own right. Shopify's AppSubscriptionStatus reference defines FROZEN as "The app subscription is on hold due to non-payment", with re-activation when payments resume. A paused store is the quieter case. Shopify's pause and build documentation says that on a paused store customers can view products but cannot make purchases, checkout is deactivated across all sales channels, and all apps remain active. Your app keeps running and receives nothing, which looks exactly like signal 3 unless you know the store is paused.

6. Seasonal merchants. Halloween costumes, swimwear, gifting, back to school. Their usage drops every year at the same time, and if you treat it as churn you will send reconnect emails to someone who is on a beach. Detect it from year-over-year usage, or more simply, from the merchant telling you in a ticket. The right response is a pause offer before the season ends, and a reminder before it starts.

Signal	How to detect it	Window to act
First-week drop-off	No second session or no activation event within 7 days	Days
No integration connected	Integration status flag still false after 48 hours	Days
Data stopped flowing	Zero core events for 14 days on an account that had them	One to two weeks
Billing tickets	Ticket tagged billing, downgrade or pause	Hours
Frozen or paused store	Subscription status, or shop plan name	Depends on the store
Seasonal dip	Same-period drop last year, or told in a ticket	Before the season ends

How do you find your own churn signals?

The method is a cohort comparison, and you can do it in a spreadsheet or in your analytics tool.

1. Pull every merchant who churned in the last six to twelve months, with the churn date.
2. Pull a similar number who stayed, spread across the same plans and install dates.
3. For each candidate signal, record the state 30 days before the churn date, and for the retained group, at a matching point in their tenure.
4. Compare the share of each group showing the signal. A big gap means a real signal. A small gap means noise.

If you use PostHog, the retention insight does most of the work. PostHog's retention documentation describes a retention cohort as a start event, which decides who is in the cohort, and a return event, which decides whether they were retained, and notes that it often but not always makes sense to use the same event for both. For an e-commerce app, do not use the same event. Use install or signup as the start, and the core data event, an order synced or a sale attributed, as the return. Retention measured on "opened the app" will look fine right up to the cancel.

PostHog's cohorts documentation adds dynamic cohorts with conditions like "Did not complete user signed up in the last 2 months", which is exactly the shape of signal 3. Build one cohort per candidate signal and use each as a filter on the retention insight.

Three tests for a signal before you keep it. Does the gap between churned and retained hold across plans, or is it really a plan effect? Does it show up early enough to act, or is it the cancel wearing a different hat? Can you detect it automatically every day? A signal that fails any of the three is a story, not a signal.

And watch the confounders. "No data flowing" is also what a paused store, a holiday closure and a broken event pipeline look like. Before you act on it, rule those out.

What should you do when a merchant trips a signal?

A signal without an action is a chart. Here is one action per signal, sized for a small team.

• First-week drop-off. A day 2 message with the single next step, and a human check-in on day 3 for paid plans. The fix is mostly in the product, and I cover it in the guide on Shopify app onboarding.
• No integration connected. One email with one link to the one connection, and an in-app banner that does not go away until it is done.
• Data stopped flowing. An alert to CS within 24 hours, a two-minute diagnostic (theme changed? token expired? widget removed?), and a message naming the likely cause with the fix. Not "let us know if you need help".
• Billing tickets. Answer within the hour with the plan options laid out plainly, and offer the downgrade before they ask for it. The cancellation flow guide covers how to make pause and downgrade real options.
• Frozen or paused store. Mark the account, stop all outreach, and set a check for when the status changes. Nothing else.
• Seasonal dip. Offer a pause before the season ends, keep their data, and send one reminder two weeks before it starts again.

Once a signal has an action, it belongs in a health score, which is where the weights and the weekly review live. The guide on building a customer health score covers how to turn these signals into bands.

Where to start

1. Pick the two signals you can detect today from existing events, most likely first-week drop-off and data stopped flowing.
2. Build a retention insight with install as the start event and your core data event as the return event, and look at the week 1 drop.
3. Run the cohort comparison on the last six months of churned merchants for those two signals and record the gaps.
4. Attach one action and one owner to each signal, and set an alert that fires within a day.
5. Add the billing ticket tag to your helpdesk this week, because it needs no engineering.