Как мы делали удобный интерфейс для аналитики ставок и что пошло не так

👋 Привет, Хабр. Я продукт-менеджер в achiewin com — мы развиваем платформу для спортивных ставок, и одна из ключевых фич, которую мы проектировали в прошлом квартале, — дашборд анализа коэффициентов.
Выглядело просто: взять наши данные, обернуть в фильтры, показать графики — и вот тебе аналитика. На деле — всё пошло не так. Рассказываю, как мы завалили первую версию, что пришлось переписывать, и почему «простой интерфейс» сложнее, чем кажется.

Что мы хотели сделать

Наша гипотеза: пользователи хотят анализировать движение коэффициентов по разным исходам и видеть, где происходит что-то аномальное — перекосы линии, резкие падения, всплески объема.
Бэк у нас уже был: данные агрегируются с более чем 15 букмекеров и пишутся в ClickHouse с шагом в 15 секунд.

Основные требования:

• выбрать событие (матч, лига, турнир),

• отфильтровать по типу ставки (тоталы, форы, победа),

• увидеть, как менялся коэффициент по времени,

• найти всплески/сдвиги в линии по группам БК,

• желательно — удобно, быстро, и чтобы не лагало.

Первая версия: BI-ада

Собрали прототип на Vue 3 + Ant Design. С бэка через GraphQL прилетали агрегаты по коэффициентам, плюс метаданные с Redis (чтобы быстрее грузилось). Фильтров было 17. Таблицы — с построчной детализацией. Можно было выбрать таймфрейм, шаг агрегации, БК и вид спорта. Вот кусок схемы запроса к ClickHouse через GraphQL:

SELECT     match_id,     bookmaker,     market,     odds,     timestamp FROM odds_history WHERE sport = 'football'   AND market = 'totals'   AND timestamp BETWEEN {start} AND {end} ORDER BY timestamp 

Интерфейс работал… но пользователи не понимали, что с этим делать.
Из фидбека:

• «Слишком много всего»

• «Где тут посмотреть движение?»

• «Почему это график, а не список?»

• «А почему на мобиле ничего не видно?»

Метрики:

• Среднее время на странице: 23 сек

• CTR на графики: <8%

• Возвраты — почти ноль

Вывод: мы сделали интерфейс для себя, а не для пользователя. Типичная ошибка «через боль».

Где была ошибка

1. Перегрузка интерфейса. Фильтры друг друга исключали, логика была неочевидной.

2. Нет явного сценария. UX-поток не вел к цели — нельзя было быстро понять, «где сейчас что-то происходит».

3. Форма победила функцию. Визуально всё выглядело «сложно» — как дешёвый BI.

После серии юзабилити-интервью (6 респондентов, в том числе профи с опытом ставок) мы пришли к выводу: большинство не хочет строить срезы — им нужно уведомление о событиях. Пример: «коэффициент на ТМ 2.5 упал с 2.20 до 1.85 за 7 минут».

Вторая версия: от аналитики к сигналам

Что сделали:

• Убрали большую часть фильтров

• Добавили карточки-сигналы, которые формируются в real-time

• Графики оставили только при клике

• Десктоп и мобайл — разные подходы: для мобилки сделали упрощенный фид

Архитектура:

1. ClickHouse — основное хранилище истории коэффициентов (около 5 млн строк в сутки).

2. Redis — слой агрегации и предвычисления для быстрой отдачи «сигналов».

3. Kafka — события движения коэффициента проходят через парсер и попадают в топики:

   • odds_update

   • signal_candidate

4. Worker (Go) — подписан на Kafka, ищет шаблоны движения (например, падение >10% за <5 минут).

5. GraphQL API — отдает только сигналы, по фильтрам: спорт, тип ставки, дата.

{   "signal": {     "type": "drop",     "market": "total_under_2.5",     "from": 2.20,     "to": 1.85,     "interval": "7m",     "bookmakers": ["Bk1", "Bk2", "Bk3"]   } } 

Фронт:

• Vue 3 + Vite

• Lazy load компонентов карточек

• Рендер графика только по клику (ECharts)

• Caching сигнальных данных в браузере (localStorage) для мобилок

Что вышло

• Время на странице: 2 мин 46 сек

• Конверсия на просмотр графика: +215%

• Переходы на событие с сигнала: +300%

• Фидбек от саппорта: «Появилось ощущение, что нас понимают»

Что не успели

• Пока не реализовали группировку сигналов по турнирам

• Нет алертов — только ручной просмотр

• Нет возможности «собрать свою стратегию» по сигналам (это в бэклоге)

Выводы

• Интерфейс — не аналитика. Пользователь приходит не за данными, а за инсайтом.

• Сигналы > фильтры. Быстрое принятие решения требует простого UX.

• Прототипы — обязательны. Мы бы сэкономили месяцы, если бы раньше протестировали идеи с реальными пользователями.

• Real-time архитектура рулит. Kafka + ClickHouse + Redis — наша тройка победы для такого сценария.

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