Dunning Optimization with Amplitude

What Dunning Optimization Actually Requires

Involuntary churn from failed payments quietly kills subscription revenue. The average SaaS business loses 1-3% of monthly recurring revenue this way, and most of it is recoverable. The problem is not that payment processors fail — it is that teams retry payments blindly, send dunning emails on fixed schedules, and treat every failed payment the same regardless of customer behavior.

Amplitude does not replace your payment processor or your dunning tool. What it does is tell you which customers are worth fighting for, when to reach them, and what signals predicted their payment failure before it happened. That behavioral intelligence is what turns a generic retry sequence into a targeted recovery operation.

---

Where Amplitude Fits in the Dunning Stack

Your dunning infrastructure has three layers: the payment processor (Stripe, Braze, Recurly), the communication platform (Braze, Iterable, Customer.io), and the behavioral data layer. Amplitude lives in that third layer.

The workflow looks like this:

1. Payment fails → processor sends event to your data pipeline
2. Pipeline routes the event to Amplitude and your dunning tool simultaneously
3. Amplitude enriches the dunning tool with behavioral cohorts and engagement scores
4. Your communication platform executes the right message sequence for each segment

Amplitude's job is step three. Without it, your dunning tool operates on payment data alone. With it, you are sequencing outreach based on how engaged a customer actually is.

---

Step-by-Step Implementation in Amplitude

Step 1: Define Your Payment Failure Event Schema

Before any analysis, you need clean events in Amplitude. Work with your engineering team to fire these specific events:

• `payment_failed` — with properties: `failure_reason`, `attempt_number`, `plan_type`, `mrr_value`
• `payment_retry_succeeded`
• `payment_retry_failed`
• `dunning_email_opened`
• `payment_updated` — triggered when a user updates their card

If these events are not already in Amplitude, add them via your existing instrumentation. The `failure_reason` property (card declined, expired card, insufficient funds, etc.) is particularly important — recovery rates vary significantly by reason code.

Step 2: Build Pre-Dunning Behavioral Cohorts Using Behavioral Cohorts

Behavioral Cohorts in Amplitude let you group users by what they have done — or stopped doing — before a payment ever fails.

Build these three cohorts and save them:

• At-Risk Cohort: Users who have not fired your core retention event (login, key feature use, content consumption — whatever signals value) in the past 14 days
• Engaged-at-Risk Cohort: Users who fired a `payment_failed` event AND logged in within the past 7 days
• Disengaged-Dunning Cohort: Users who fired a `payment_failed` event AND have not logged in for 30+ days

The logic is straightforward: your recovery messaging for an engaged user who hit an expired card is entirely different from your approach to a disengaged user who has not used the product in a month. The first needs a frictionless payment update prompt. The second needs a reactivation argument before you even ask for card details.

Step 3: Map the Failure Journey Using Journeys

Journeys (formerly Pathfinder) shows you the actual sequence of events users take before and after a payment failure. Run a Journey analysis with `payment_failed` as the anchor event, then look backward 30 days.

You will typically find two or three dominant pre-failure paths. Common patterns:

• High feature usage → sudden drop-off → payment failure (billing issue, not churn intent)
• Gradual session decline over weeks → payment failure (churn intent preceded the failed payment)
• Consistent usage with no decline → payment failure (pure billing error, highest recovery rate)

Each path warrants a different dunning approach. The Journey view gives you the evidence to argue for segmented sequences instead of a single blast.

Step 4: Identify Optimal Retry Windows with Funnel Analysis

Funnel Analysis in Amplitude can tell you which retry timing correlates with the highest `payment_retry_succeeded` conversion. Set up a funnel:

`payment_failed` → `payment_retry_succeeded` converted within X days

Slice this by `attempt_number` and by time-of-day properties if your processor logs them. You are looking for the retry windows where conversion drops sharply — those are the windows to avoid. Most teams discover that their third retry attempt is mistimed, not that retry logic itself is broken.

Step 5: Export Cohorts to Your Communication Platform

This is where Amplitude connects to execution. Use Amplitude's native integrations — specifically the Audiences feature — to sync your behavioral cohorts directly to Braze, Iterable, or Customer.io.

For Braze, Amplitude syncs cohorts and you target them using Canvas (Braze's journey builder). For Iterable, cohorts populate Workflow Studio automatically. For Customer.io, they flow into your segment conditions.

The sync is not one-time. Set your cohorts to dynamic sync so they update as user behavior changes. A user who was in your Disengaged-Dunning Cohort but logged in after your first email should move to your Engaged-at-Risk sequence automatically.

Step 6: Measure Recovery Rate as a North Star Metric

Build a dedicated Dashboard in Amplitude to track dunning performance:

• Recovery rate by cohort: `payment_retry_succeeded` divided by `payment_failed`, segmented by your cohort property
• Time-to-recovery: Average days from first failure to successful retry
• Churn attribution: Users who reach `payment_failed` and then `subscription_cancelled` without a recovery event

Review this dashboard weekly during active optimization. You are looking for which cohort responds at what rate, not aggregate recovery rate, which obscures where the real opportunity is.

---

Limitations You Need to Know

Amplitude does not retry payments. It does not send emails. It does not integrate with your payment processor directly.

More specifically:

• No native Stripe/Recurly integration for payment events — you need a pipeline tool (Segment, mParticle, or direct API) to route payment events into Amplitude
• Cohort sync latency — Amplitude's cohort syncs to Braze or Iterable are not real-time. Depending on your plan and sync frequency, there can be a 15-60 minute lag. For dunning, where first-hour outreach matters, your dunning tool should still trigger initial communication via payment processor webhooks — Amplitude enriches the follow-up sequences, not the first touch
• No predictive payment failure model out of the box — Amplitude Audiences has propensity scoring, but configuring it to predict payment failure requires historical data and setup time. This is not a day-one capability

---

Frequently Asked Questions

Can Amplitude predict which customers will have a payment failure before it happens?

Amplitude's Predictions feature (within Audiences) can build a propensity model for almost any event, including `payment_failed`. However, it requires a meaningful volume of historical failure events — typically several hundred at minimum — and a training period of two to four weeks. If you have the data, this is worth building. It lets you trigger pre-dunning outreach before the card ever declines, which dramatically improves recovery rates.

Do I need a CDP like Segment to use Amplitude for dunning?

Not necessarily, but it helps significantly. Payment events from Stripe or Recurly do not flow into Amplitude automatically. You can send them via direct API instrumentation, but a CDP like Segment or mParticle simplifies routing payment processor webhooks into Amplitude alongside your product events. If you are already on Segment, this is a straightforward addition to your tracking plan.

How is Amplitude different from just using Stripe Radar or my dunning tool's built-in segmentation?

Stripe Radar and most dunning tools (Churnkey, Gravy, etc.) segment on payment data: failure reason, card type, transaction history. Amplitude segments on product behavior: feature usage, session frequency, activation milestones. These are complementary signals. A customer with an expired card who used your product daily last week is a very different recovery conversation than one who has not logged in for six weeks, even if the payment failure looks identical in Stripe.

What if my engineering team does not have the bandwidth to instrument new payment events?

Start with what you already have. Most teams have session and login events in Amplitude already. You can build a rough version of the At-Risk and Disengaged cohorts from login frequency alone, then sync those to your communication platform. It is less precise than a full payment event schema, but it is better than no behavioral segmentation. Add the payment-specific events in the next sprint when capacity opens up.