Конверсия упала, оба сегмента выросли: разбираем платёжную воронку

Можно улучшить оплату в каждом сегменте и получить худший общий процент. Можно добавить повторы и снизить успешность попыток, одновременно завершив больше заказов. Прежде чем менять маршруты и интерфейс, проверьте единицу измерения, состав клиентов и время, которое вы дали платежам на завершение.

Когда общий процент обвиняет невиновную интеграцию

Рассмотрим отдельный учебный пример. В первом периоде сегмент A дал 900 заказов с конверсией 90%, сегмент B — 100 заказов с конверсией 60%. Получилось 810 + 60 = 870 успешных заказов из 1 000, то есть 87%.

Во втором периоде A улучшился до 92%, но теперь содержит только 200 заказов. B улучшился до 65% и содержит 800 заказов. Успехов стало 184 + 520 = 704, общая конверсия — 70,4%. Оба сегмента выросли, общий результат снизился на 16,6 процентного пункта из-за изменившегося состава потока.

Для проверки сравните периоды при одинаковых весах сегментов. С прежними долями 90% и 10% новый результат равнялся бы 89,3%: 0,9 × 92% + 0,1 × 65%. Это аналитический пересчёт, а не фактическая конверсия второго периода. Показывайте обе цифры с подписями: фактический итог нужен бизнесу, сопоставимый состав помогает оценить изменение самого процесса.

Один пример, четыре результата

Представим условный магазин, где 1 000 уникальных заказов дошли до экрана оплаты. Для 800 заказов покупатели отправили хотя бы одну попытку. Повторные действия дали суммарно 940 попыток, из которых 680 завершились успешной авторизацией и относились к 680 разным заказам. К концу выбранного окна по 660 заказам завершился этап capture: продавец подтвердил списание ранее авторизованной суммы.

• Переход к попытке оплаты: 800 / 1 000 = 80%.
• Успешная авторизация среди пытавшихся оплатить заказов: 680 / 800 = 85%.
• Успешность отдельных попыток: 680 / 940 ≈ 72,3%.
• Доля заказов с завершённым capture среди открывших оплату: 660 / 1 000 = 66%.

Эти показатели отвечают на разные вопросы. Первый помогает исследовать интерфейс и доступность методов. Второй показывает результат для заказа после допустимых повторов. Третий характеризует попытки, четвёртый отражает выбранный коммерческий результат. Если деньги списываются без отдельного этапа capture или используется банковский перевод, определите соответствующий подтверждённый результат для этого метода.

Разведите заказ, попытку и событие

В модели данных нужны устойчивый идентификатор заказа, отдельный идентификатор попытки и идентификатор события. Одна попытка может породить несколько уведомлений, а один заказ включать несколько попыток. Их смешение увеличивает числитель или знаменатель без изменения реального поведения клиентов. Для P2P-процесса аналогом заказа может быть конкретная заявка, но её границы нужно определить заранее.

Stripe рекомендует повторно использовать PaymentIntent при возобновлении того же процесса оплаты. Такой объект помогает связать неудачные попытки с одной корзиной или сессией. Это пример связи бизнес-объекта с платёжным процессом, а не универсальная схема для всех провайдеров. Источник: Stripe, Payment Intents.

Минимальная карта событий

Зафиксируйте открытие оплаты, выбор метода, отправку попытки, необходимость дополнительного действия, завершение этого действия и подтверждённый результат. Для каждого события храните время возникновения и получения, идентификаторы, сумму, валюту, метод и версию интеграции. В аналитические поля не нужно помещать реквизиты карты или избыточные персональные данные.

Для результата используйте проверенное серверное подтверждение, предусмотренное интеграцией. Возврат пользователя на страницу успеха полезен для оценки интерфейса, но сам по себе недостаточен как доказательство платежа. И наоборот, закрытие браузера не доказывает, что операция завершилась неудачей. Эти две ситуации должны входить в проверочные сценарии аналитики.

Stripe предупреждает о повторной доставке webhook-событий и отсутствии гарантированного порядка. Обработчик должен учитывать дубли и обновлять состояние независимо от порядка получения. Источник: Stripe, Webhooks.

Сравнивайте завершившиеся когорты

Выберите правило формирования группы, например заказы, впервые открывшие оплату за день, и дайте всем одинаковое окно наблюдения. Его длину подбирайте под конкретный метод и цикл покупки. Пока окно не закрыто, показывайте предварительный результат и долю ожидающих операций. Поздно подтверждённые платежи должны обновлять исходную когорту, а не создавать новую успешную попытку в случайном дне.

Разрезы также требуют дисциплины. Сравнивайте похожие методы, устройства, валюты и типы клиентов. Общий процент может снизиться только из-за увеличения доли более сложного сегмента. Прежде чем обвинять новую версию интеграции, проверьте изменение состава трафика и достаточность наблюдений.

Adyen Received payment details report включает данные об авторизованных и отклонённых платежах, взаимодействии и ответах участников обработки. Такой отчёт полезен для сверки серверной части воронки, но не описывает посетителей, которые вообще не отправили платёж. Источник: Adyen, Received payment details report.

Оставьте незавершённым операциям отдельное место

Предварительные результаты не надо насильно делить на успехи и отказы. Выделите операции с ожидающим или неизвестным исходом. Если сегодня таких стало больше, падение конверсии может отражать задержку подтверждения, а не окончательную потерю покупателей. Для решения нужны возраст ожидания и результаты после одинакового окна наблюдения.

Перед экспериментом запишите, что именно меняется, кто попадает в сравнение и что считается завершением. Проверьте, что один заказ не перескакивает между группами при повторе. Не меняйте одновременно знаменатель, окно наблюдения и интерфейс: иначе даже реальный рост будет трудно объяснить.

В итоговом разборе держите рядом дополнительное число завершённых заказов, стоимость обработки, возвраты и обращения о двойном списании. Последние показатели могут проявиться позже первой оплаты, поэтому ранний положительный результат остаётся предварительным до выбранной проверки качества. Нужное улучшение должно пережить эту проверку, а не только красиво выглядеть в день запуска.