Как посчитать payment retry success rate в SQL

Зачем retry rate

После failed payment система пытается повторить charge через час, день, три. Retry success rate показывает эффективность этого механизма. Низкий retry rate = card permanently bad, retry бесполезен. Высокий = временный issue (insufficient funds, network). Метрика — основной KPI для billing-команды.

Базовая формула

retry_rate = successful retries / total retries

Считается на retry-уровне, не user-уровне.

Retry success rate в SQL

WITH retries AS (
    SELECT
        user_id,
        event_id,
        event_date,
        event_status  -- 'success' или 'failed'
    FROM payment_events
    WHERE event_type = 'retry'
      AND event_date >= CURRENT_DATE - INTERVAL '90 days'
)
SELECT
    COUNT(*) AS total_retries,
    COUNT(*) FILTER (WHERE event_status = 'success') AS successful,
    COUNT(*) FILTER (WHERE event_status = 'success')::NUMERIC * 100
    / NULLIF(COUNT(*), 0) AS retry_success_rate_pct
FROM retries;

Industry typical: 25-40%. Smart retries (Stripe, recurly) — до 60%+.

По номеру попытки

WITH retries_numbered AS (
    SELECT
        user_id,
        event_id,
        event_date,
        event_status,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY event_date) AS retry_number
    FROM payment_events
    WHERE event_type = 'retry'
)
SELECT
    retry_number,
    COUNT(*) AS attempts,
    COUNT(*) FILTER (WHERE event_status = 'success')::NUMERIC * 100
    / NULLIF(COUNT(*), 0) AS success_rate_pct
FROM retries_numbered
GROUP BY retry_number
ORDER BY retry_number;

Retry 1: 40-50% success. Retry 5+: 5-10%. После 4-5 attempts — обычно безнадёжно.

По платежной системе

SELECT
    payment_system,
    COUNT(*) AS retries,
    COUNT(*) FILTER (WHERE status = 'success')::NUMERIC * 100
    / NULLIF(COUNT(*), 0) AS success_rate_pct
FROM payment_retries
WHERE attempt_date >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY payment_system
ORDER BY success_rate_pct DESC;

Stripe обычно даёт highest recovery благодаря Card Account Updater. PayPal — ниже из-за отсутствия этой функции.

Smart retry vs fixed

Smart retry система понимает причину failure и адаптирует timing. Fixed retry бьёт через каждые 24 часа. Сравнение:

WITH retry_groups AS (
    SELECT
        CASE WHEN retry_system = 'smart' THEN 'smart' ELSE 'fixed' END AS retry_type,
        status
    FROM payment_retries
    WHERE attempt_date >= CURRENT_DATE - INTERVAL '60 days'
)
SELECT
    retry_type,
    COUNT(*) AS attempts,
    COUNT(*) FILTER (WHERE status = 'success')::NUMERIC * 100
    / NULLIF(COUNT(*), 0) AS success_rate_pct
FROM retry_groups
GROUP BY retry_type;

Smart retry обычно даёт +15-25% recovery vs fixed.

Частые ошибки

Ошибка 1. Считать success в первой попытке как retry. Это original payment, не retry. Не путать.

Ошибка 2. Не сегментировать по failure_reason. Insufficient funds — recovery 60%+. Expired card — < 10%. Разные сценарии.

Ошибка 3. Считать на user, а не на retry. Один user с 5 attempts = 5 retries. Не считайте unique users в numerator.

Ошибка 4. Игнорировать таймауты network. Network timeout != real failure. Часто retry успешен. Сегментируйте.

Ошибка 5. Не учитывать chargeback после retry. Иногда retry success → chargeback через 30 дней. Net recovery меньше.

Связанные темы

• Как посчитать payment success rate в SQL
• Как посчитать grace period recovery в SQL
• Как посчитать involuntary churn в SQL
• Как посчитать chargeback rate в SQL

FAQ

Сколько retry attempts оптимально?

3-5. Дальше chargeback risk возрастает.

Smart retry — это что?

Recurly / Stripe Smart Retries: используют ML для выбора лучшего времени retry.

Retry в выходные?

Хуже, чем в будни (зарплата приходит в среду). Smart retry это учитывает.

Card Account Updater стоит?

$0.25/match in Stripe. Окупается if updated card recovers $5+ MRR.

Retry vs dunning email?

Retry — automatic charge. Dunning — email с CTA «update card». Используют оба.