Recurly's July 2026 churn benchmarks put the ecommerce subscription churn rate at a 4.25 percent median annual figure. Split that number open and it stops looking like one problem: 2.87 percentage points are voluntary, customers who chose to leave, and 1.38 points are involuntary, customers whose renewal payment simply failed, according to Recurly's own research.
That means close to a third of the churn most subscription brands report every month has nothing to do with their product, their offer, or their retention emails. It is a declined card.
Most ecommerce dashboards never make that split. They report a single churn rate, blend a product problem with a payments problem into one number, and send the retention team chasing the wrong fix. Here is how to separate them, and why the tools most brands already have, GA4 chief among them, cannot do it without help.
One churn rate, two different causes
A subscription cancels for one of two reasons.
Voluntary churn is a decision. The subscriber opens the account portal, or emails support, and actively ends the relationship. Price, product fit, a competitor, or simply not needing another box this month.
Involuntary churn is an accident. The renewal charge hits an expired card, an account with insufficient funds, or a bank that declines the transaction for its own risk reasons, and the subscription lapses even though the customer never asked to leave. Stripe's guidance on involuntary churn frames the distinction the same way: involuntary churn happens when customers stop unintentionally, as opposed to voluntary churn, where they make a deliberate choice to cancel.
The two causes also respond to completely different interventions. Voluntary churn responds to cancellation-flow surveys, save offers, pause options, and genuine product or pricing changes. Involuntary churn responds to payment retry logic, card-expiry reminders, and dunning emails, none of which touch the product at all.
GA4 was never built to see a subscription cycle
Here is where most brands hit a wall before they even get to analyzing the split: GA4 cannot see it.
GA4's own ecommerce event documentation defines the purchase event around a single transaction: a transaction_id, a value, a coupon, an items array. There is no cycle number, no subscription identifier carried across renewals, and no field for why a transaction did not happen. The schema was designed for one-time ecommerce orders, and subscription billing was never part of its model.
That has a practical consequence most brands only discover once they try to pull a subscription LTV report: GA4 only automatically captures the first charge, the one a customer makes on your site. Every renewal after that happens in the background, triggered by a billing platform, with no browser session for GA4's standard tag to observe.
The fix is server-side. Google's own Measurement Protocol documentation describes exactly this use case: sending events that happen outside standard user interaction, tying server-to-server and offline activity back into the same property. But the same page is explicit that the Measurement Protocol is meant to augment automatic collection, not replace it.
That means someone still has to build the plumbing. A server-side event for every renewal charge, carrying the same customer identifier as the original purchase, plus whatever fields your subscription platform exposes for cycle number and cancellation reason.
Skip that build and your GA4 property quietly treats every subscriber as a one-time customer who happened to buy once. The retention cohorts you would build on top of that data, the same kind we cover in our guide to building a cohort analysis ecommerce brands can actually trust, will understate repeat behavior that is really happening on autopilot through your billing platform instead of through GA4's browser-side tag.
What the missing split costs you
The absence of a voluntary/involuntary split does not just blur a vanity metric. It corrupts decisions further downstream.
Pull subscriber LTV without separating churn causes, and a cohort that loses 10 percent of its members to declined cards in month three looks identical to a cohort that loses 10 percent because the product disappointed them. Our breakdown of LTV to CAC ratio for ecommerce covers why a blended number this unreliable will flatter or punish a channel for the wrong reason. A churned-cohort LTV calculation has the same failure mode: the input data cannot tell two opposite causes apart, so the output number cannot either.
It also misdirects the team. A retention manager who sees rising churn and does not know a third of it is payment failures will spend a quarter testing win-back offers and pricing changes against a problem that a retry schedule would have fixed in a week.
Fix the payments half first
Involuntary churn is the cheaper fix, because it does not require touching the product, the price, or the offer. It requires a working retry policy.
Stripe's documentation on Smart Retries lays out a specific default: eight retry attempts spread across a two-week window, with the system choosing retry timing based on signals like which device last used a given payment method and which local time windows tend to convert better for debit cards. Hard declines, a reported lost or stolen card, are treated differently: Stripe holds those retries until the customer supplies a new payment method rather than hammering a card that will never succeed.
The mechanism matters because it tells you what to check if your own involuntary churn number looks high:
- Is a retry policy actually configured, or is a single failed charge cancelling the subscription immediately?
- Does the retry window stretch far enough (Stripe's own range runs from one week up to two months) to catch a payday or a replaced card?
- Are customers getting an email with a link to update their payment method before the card expires, not just after a charge already failed?
- Is the subscription platform distinguishing hard declines, which need a new card, from soft declines, which a later retry can still recover?
None of that requires a win-back campaign or a discount. It requires the retry and dunning configuration actually being turned on and tuned, which is frequently the gap, not the absence of a clever idea.
Building a churn number you can actually act on
Once the payments side is tuned, the reporting side needs the same split GA4 cannot give you by default.
In practice that means three additions to however you currently track subscribers: a stable customer identifier carried across every renewal event, a cancellation reason field populated from your subscription platform's own cancellation flow (several mainstream Shopify subscription apps, including Recharge and Skio, prompt for a cancellation reason at the point of cancellation, though exactly what gets captured and exposed via API varies by platform and plan), and a server-side renewal event sent for every billing cycle, not just the first.
From there, the churn rate stops being one number and becomes two trend lines: voluntary churn you manage with retention and pricing work, and involuntary churn you manage with payment recovery. A reporting partner building out a dashboard library typically adds this as its own view precisely because retention, subscription, and profit numbers need to sit next to each other to be useful, not scattered across a billing platform's own dashboard and a separate GA4 property that never sees half the renewals.
If your store runs subscriptions and your current retention reporting still shows one blended churn number, that is usually the fastest place to find a gap, which is exactly the kind of behavioral measurement question our product analytics work is built to answer: not just whether customers come back, but which specific mechanism is costing you the ones who do not.
The split is the whole point
A single subscription churn rate tells you that something is wrong. It does not tell you what, and "what" is the only part of the number that changes what you do next.
Separate voluntary from involuntary before you act on either one. A retention offer aimed at the wrong third of your churn will not move the number, and neither will a retry policy aimed at customers who already decided to leave. One caveat worth sitting with: the split itself is not static. A brand that fixes its retry policy this quarter will see its churn rate drop and its remaining churn become almost entirely voluntary, which is the correct signal that the payments work is done and the harder, slower retention work is next.
