разбор продуктаобновлено 2026-08-20

Страница спортивного события: как показать много рынков и не потерять контекст

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

Иллюстрация к материалу: Event page спортивной платформы: как показать много рынков и не потерять контекст
Kenneth C. Zirkel / Wikimedia CommonsCC BY-SA 4.0

Плотность — не количество строк на экране

На event page пользователь сравнивает рынки и возвращается к контексту матча. Если всё раскрыть, экран превращается в длинный каталог; если всё свернуть, постоянно приходится угадывать, где нужный рынок. Нужна иерархия, основанная на сценарии чтения.

Три уровня контекста

Верхний уровень сохраняет event identity и live status. Второй — группы рынков с коротким summary. Третий — selections. При scroll sticky-панель оставляет счёт/фазу, но не дублирует весь header. Выбранные selections сохраняют визуальную связь с betslip.

«Показать больше» не равно «сделать полезнее»

Редкие market groups можно раскрывать по запросу, но выбранный или изменившийся рынок нельзя внезапно убирать из DOM. Progressive disclosure должен уважать текущее действие пользователя.

Состояние важнее декоративной анимации

Price change, suspend и selected имеют устойчивый визуальный приоритет. Если компактный layout не помещает все украшения, первым сохраняется статус доступности и focus/selected state. Анимация изменения цены — вторична.

Закреплённый контекст становится вторым экраном

Слишком крупная sticky-зона съедает пространство на маленьком устройстве. Компонент переключается на компактный вариант после scroll threshold и учитывает safe area. Сам threshold тестируется на разных viewport, а не задаётся из дизайна «на глаз».

Как проверить страницу на реальном матче

Макет с несколькими рынками почти всегда выглядит чище реального event page. Проверять плотность нужно на длинном событии: много групп, длинные названия участников, несколько suspended-состояний, изменяющийся счёт и уже выбранные позиции. Только на таком наборе видно, где навигация перестаёт помогать, а sticky-блок начинает отнимать полезную площадь.

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

  • Проверить narrow mobile viewport с длинными названиями рынков.
  • Не прятать состояние suspended внутри collapsed-группы без индикации.
  • Сохранять выбранную группу и позицию при обновлении данных, если это не ломает контекст.

Что проверять в продуктовой аналитике

Не нужно придумывать «идеальную конверсию». Сначала смотрят поведение: какие группы раскрывают, сколько раз возвращаются к header, где происходят invalid actions после suspend, как меняется глубина scroll. Потом эти наблюдения связывают с конкретной гипотезой интерфейса.

Пройти страницу от стартового свистка до финала

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

Хорошая проверка — сохранить выбранный рынок, раскрытую группу и позицию focus, затем отправить несколько обновлений каталога. EventPage должен сохранить контекст, даже если список внутри перестроился. Live-блоки могут обновляться часто, но навигационный каркас не обязан перерисовываться вслед за каждым tick.

Для аналитики полезно смотреть не только depth scroll. Сигналы потери контекста — частые повторные раскрытия одной группы, возвраты к верхней части страницы после обновления и клики по уже недоступным элементам сразу после reorder.

Схема решения: Event page спортивной платформы: как показать много рынков и не потерять контекст
Диаграмма к разбору: Страница спортивного события: как показать много рынков и не потерять контекст.
Следующий слой

Связанные разборы по той же архитектурной цепочке

Надёжность

Сессия пользователя и публичный кэш: где проходит граница

Как отделить публичную страницу события от данных аккаунта, сохранить эффективность кэша и не допустить персональные данные в общий ответ.

Перейти к разбору →
Интерфейсы

Поиск по событиям и рынкам: отдельный индекс чтения

Зачем спортивной платформе отдельный поисковый индекс, как обновлять его из каталога событий и что делать с устаревшими результатами поиска.

Перейти к разбору →
Букмекерская логика

Коэффициенты в реальном времени без шторма запросов

Путь коэффициента от поставщика до интерфейса: нормализация, снимки и изменения, версии, обратное давление и разветвление потока обновлений.

Перейти к разбору →
Мобильные продукты

Уведомления о спортивных событиях: очередь и независимые каналы

Как доставлять спортивные уведомления через исходящую очередь и независимые каналы, контролировать дубли, повторы и возраст сообщений.

Перейти к разбору →