Платёжная воронка онлайн-казино: события, decline-коды и SQL-диагностика

Редакция mevrica

Аналитика4 мин чтения

Обновлено 1 августа 2026 г.

Платёжная аналитика начинается после клика «Пополнить», но не заканчивается ответом success. Пользователь выбирает метод, создаёт попытку, проходит подтверждение банка, получает окончательный статус, а затем депозит квалифицируется программой. Если хранить только deposit=yes/no, невозможно отличить отказ банка от сломанной кассы, неподходящей валюты или потери постбэка.

Событийная схема

attempt_id создаётся на каждую отправку, deposit_id — только на проведённый депозит. session_id объединяет повторные попытки одного визита без раскрытия личности. route_id обозначает конкретный маршрут провайдера и эквайера; method_code — пользовательский метод. Эти поля позволяют увидеть, где упал результат, не сохраняя номер карты, кошелька или документ.

Нормализованный справочник отказов

Маппинг должен быть версионным. Не переписывайте старый отчёт после изменения классификации: храните provider_code и mapping_version. Категория unknown — полезный сигнал, а не мусорная корзина. Рост неизвестных кодов после релиза часто быстрее обнаруживает изменение API, чем общий approval rate.

Таблица попыток

CREATE TABLE payment_attempts (
  attempt_id        text PRIMARY KEY,
  session_id        text NOT NULL,
  click_id          text,
  method_code       text NOT NULL,
  route_id          text NOT NULL,
  amount_minor      bigint NOT NULL CHECK (amount_minor > 0),
  currency          char(3) NOT NULL,
  submitted_at      timestamptz NOT NULL,
  final_status      text NOT NULL,
  provider_code     text,
  normalized_reason text,
  mapping_version   integer NOT NULL
);

SQL: воронка по методу и маршруту

SELECT
  date_trunc('day', submitted_at) AS cohort_day,
  method_code, route_id, currency,
  count(*) AS attempts,
  count(DISTINCT session_id) AS sessions,
  count(*) FILTER (WHERE final_status='authorized') AS authorized,
  round(100.0 * count(*) FILTER (WHERE final_status='authorized')
        / nullif(count(*),0), 2) AS attempt_approval_pct,
  round(100.0 * count(DISTINCT session_id) FILTER
        (WHERE final_status='authorized') / nullif(count(DISTINCT session_id),0), 2)
        AS session_success_pct
FROM payment_attempts
WHERE submitted_at >= current_date - interval '14 days'
GROUP BY 1,2,3,4 ORDER BY 1,2,3;

Два коэффициента отвечают на разные вопросы. attempt approval показывает эффективность отдельных отправок, session success — смог ли пользователь завершить платёж хотя бы одной попыткой. Если повторов стало больше, первый показатель падает быстрее второго. Для бизнеса важны оба: успешная сессия сохраняет конверсию, но лишние попытки ухудшают опыт и создают нагрузку.

Обезличенный расчёт

card_b лучше по конверсии сессии, но получил иной сегмент. Перед переключением сравнивают одинаковые GEO, банки, устройства, валюту и диапазон суммы. У card_a 58 из 610 проведённых депозитов не стали approved FTD, у card_b — 37 из 409. Доли почти одинаковы; зона улучшения находится до депозита. Если после маршрутизации card_b на сопоставимой случайной доле сохранит преимущество, прирост на 1 000 сессий составит около 50 успешных платежей до последующей квалификации.

SQL: причины потерь

SELECT method_code, route_id, normalized_reason,
       count(*) AS declines,
       round(100.0 * count(*) / sum(count(*)) OVER
         (PARTITION BY method_code, route_id), 1) AS share_pct
FROM payment_attempts
WHERE final_status='failed'
  AND submitted_at >= now() - interval '7 days'
GROUP BY 1,2,3 ORDER BY 1,2,4 DESC;

Правило расследования

1. Сравнить долю cashier_opened → submitted и submitted → authorized.
2. Разбить изменение по method, route, GEO, device, currency и часу.
3. Проверить новые provider_code и mapping_version.
4. Отделить первую попытку от повторных.
5. Сопоставить deposit_posted с postback и approved FTD.
6. Менять маршрут только контролируемой доле, сохраняя возможность отката.

Границы ответственности

Арбитражная команда не должна предлагать обход банковской проверки, KYC или риск-контроля. Её задача — обнаружить техническую или коммуникационную потерю и передать оператору агрегированные доказательства. UK Gambling Commission, например, требует у онлайн-операторов проверять возраст и личность до игры; порядок в другом GEO устанавливает соответствующая юрисдикция.

Источник и дата проверки

Регуляторный контекст проверен 1 августа 2026 года по официальному руководству UK Gambling Commission: https://www.gamblingcommission.gov.uk/public-and-players/guide/age-and-id-verification. SQL и числа в примере являются воспроизводимой учебной моделью, а не рыночным бенчмарком.