01.08.2025 15:15
ruslankostin 0 319 Источник

? Привет, Хабр. Я продукт-менеджер в 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 — наша тройка победы для такого сценария.

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

Комментарии (0)