Recurring donor churn: why your denominator is wrong

Recurring donor churn is the rate at which recurring (sustainer) commitments stop being fulfilled. The number almost everyone gets wrong isn’t the numerator. It’s the denominator. Churn has to be measured against expected gifts, not received ones. Count only what arrived, and a quietly-failed credit card looks like nothing happened, so your most common form of churn becomes invisible.

How do you measure recurring donor churn?

You compare the recurring gifts you should have received in a period against the ones that actually stopped. The denominator is the set of expected charges implied by your open recurring commitments, not the set of payments that landed.

• Numerator: recurring commitments that stopped being fulfilled (cancelled or quietly failing).
• Denominator: the recurring gifts you expected this period, given the open commitments.

If a donor pledged $50/month and the card fails in month seven, that’s churn the moment the expected charge doesn’t arrive, whether or not anyone cancelled anything.

Why the denominator must be “expected, not received”

A received-only view can only see gifts that exist. But churn is, by definition, about gifts that should exist and don’t. Measuring churn against received gifts is like measuring no-shows by counting the people who showed up: the very thing you’re trying to detect is the thing that’s missing from your data.

The silent failure most shops never see

There are two kinds of recurring churn, and the dangerous one is quiet:

• Voluntary churn: the donor cancels. You get an event; it’s visible.
• Involuntary churn: the card expires or a charge fails. Nothing happens in your CRM. No cancellation, no flag, just an absence.

Involuntary churn is often the larger share, and it’s recoverable (a quick “update your card” note), but only if you can see it. You can only see it if your data knows a payment was expected, which means the recurring commitment has to be modeled as its own thing, separate from the transactions that fulfil it.

That commitment-vs-transaction distinction is the same one behind a pledge is not a payment, and it’s exactly why a system that flattens both into “a gift” simply cannot compute recurring churn correctly.

A worked example

A synthetic sustainer pledged $50/month. Ten charges succeed; in months seven and eleven the card fails (illustrative):

• Received-only view: “10 gifts this year, donor looks active.” The two failures are invisible. You learn about them when the annual revenue comes up short.
• Expected-vs-received view: 12 expected, 10 received → 2 failed charges flagged in months seven and eleven, in time to send a card-update nudge and recover the gift.

Same donor, same data. One view loses revenue silently; the other recovers it.

What you need to compute it

That separation (commitment as a first-class object, distinct from the transactions that pay it) is part of the shared data model; see what is the Advancement Common Data Model?. The precise numerator, denominator, and time basis for recurring_churn live in the open metric-definitions repository.

What you get

Early warning on the churn you currently learn about months late, a concrete recovery path for involuntary failures (which are the easiest donors to win back, since they didn’t mean to leave), and a sustainer program whose health you can actually measure instead of estimate.

For the builder/standard view, see The Standard (ACDM); to locate your shop on the ladder, take the self-assessment.

Examples use synthetic data. The standard is open and early; treat current releases as drafts.