Я Илья, руководитель направления геймификации в PARI. До работы здесь у меня был свой бизнес в рамках холдинга EXCORP.GG: мы делали игровые спецы для EXTREMUM и CS.MONEY. Я устал от того, что каждый спецпроект собирается с нуля, живёт пару недель и умирает.

Поэтому я понял: если склеить разные игровые механики в одну систему, они будут лучше работать вместе и усиливать вовлечение. Тогда я защитил эту идею перед фаундерами и основал LVL.IO — компанию, в которой мы создали такой продукт. Эту идею я показал ex‑главе киберспорта PARI Ивану Бураченко — и она легла точно под годовой контракт с BLAST, который компания подписала в 2022-м.

BLAST — это международная киберспортивная компания, которая организует турниры и другие события по CS. PARI в 2022 году заключила с BLAST годовой контракт на сотрудничество.

Так я зашёл в букмекерскую компанию как предприниматель и поставщик технологии, а позже сам перешёл в инхаус и остался развивать PARI PASS. Рассказываю, как проект стал основой для всех спецпроектов и событий в компании.

Как из разрозненных акций родилась идея единой платформы

Когда мы запускали PASS именно для PARI в 2022 году, это был продукт с такой механикой: дать пользователю дополнительную выгоду за привычные действия. Всё просто: человек делает ставку, получает PARI Coins и может обменять их на фрибет. А если хочет получить больше — подключается к игровым механикам: выполняет задания, проходит сезонную прогрессию, участвует в пикемах и открывает достижения. То есть сам выбирает, насколько глубоко вовлекаться.

Изначально PASS создавался для киберспортивной аудитории и должен был решать несколько задач: 

• стать новым решением на рынке, которого никто до нас не делал; 

• удерживать пользователя вдолгую; 

• давать людям дополнительную мотивацию возвращаться;

• оставаться экономически эффективным для бизнеса при всех вышеуказанных задачах. 

Первый запуск прошёл под BLAST — годовой контракт PARI с турнирной студией. Это условие как раз требовало не разовой акции, а механики, которая могла бы жить вместе с турнирами и надолго быть связанной с бизнесом и обновляться.

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

А внутри вместо набора отдельных игровых элементов появилась система, которую можно развивать, анализировать и быстро адаптировать под новые сценарии. Дальше расскажу, как PARI PASS прошёл этот путь.

От хайпа к продукту, за которым стоят 600 тысяч уникальных пользователей за 2025 год

В 2022 году PASS неплохо пошумел: о нём много писали в СМИ, конкуренты пытались сделать что‑то похожее, а в 2023-м проект взял серебряную награду премии Silver Mercury. В общем, хайп — это, конечно, здорово, но логично было двигаться дальше: удерживать интерес пользователей и следить за экономической эффективностью. Мы делали эту работу в три блока: поменяли стек, углубили аналитику и сделали механики переиспользуемыми.

Старый стек начал мешать развитию 

С точки зрения внутренней экономики и технологий PASS тоже сильно изменился. Первая версия была написана на довольно древнем стеке — PHP и старом React. По мере роста продукта мы начали постепенно переводить его на современные технологии. Сейчас на фронте у нас классический React SPA с Tailwind CSS и TanStack Query, а бэкенд построен на микросервисах: основные сервисы написаны на Go, часть — на Node.js. Они общаются между собой через REST. Для работы с данными используем PostgreSQL, для кеширования — Redis, а для организации очередей — RabbitMQ.

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

Были случаи, когда после релиза из‑за нагрузки падал весь проект, а на восстановление уходило по два‑три часа. С микросервисной архитектурой отдельные модули можно развивать и масштабировать независимо: новые фичи добавляются быстрее, а их влияние на остальную систему проще контролировать. В результате снизилась и нагрузка на QA.

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

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

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

Аналитика: теперь видим не только результат, но и каждый шаг пользователя

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

Так было, например, после старта ЧМ. На софт‑лонче проблем почти не было: пользователей было мало, а продуктовые метрики (основные из них — обороты и депозиты) с фидбэком по результатам опроса не показывали ничего критичного. Но когда был наплыв трафика, уже через неделю стало видно, что пользователи не понимают ценности коллекций и путаются в заданиях. 

Мы собрали данные и быстро нашли проблемы в UI/UX. Например, пользователь мог утром взять задание, сделать ставку на вечерний матч, а в 12:00 задание обновлялось — и его ставка становилась невалидной. В итоге за неделю мы внесли кучу поправок: изменили время обновления заданий, добавили подсказки и ограничения, снизили минимальный порог заданий с 1 000 до 100 рублей, убрали лимит на количество заданий и добавили автовзятие. 

После релиза повторно посмотрели метрики и провели опрос: проблемы в пользовательском флоу пофиксились. Причём снижение порога не уменьшило объём ставок: вместо одной ставки на 1 000 рублей пользователь чаще делал несколько ставок на меньшие суммы и быстрее двигался по прогрессии.

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

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

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

Как уже упомянули, сначала PASS работал на киберспортивную аудиторию. Задания, прогрессия, пикемы — все эти механики пришли из игр, поэтому пользователи легко в них включались. 

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

Так появился альбом для ЧМ. Мы посмотрели на аудиторию 35+ и стали искать знакомые ей ассоциации. Вспомнили коллекционные альбомы Panini с наклейками: их в своё время собирали сами пользователи или их дети. А идея коллекционирования понятна без объяснений: собираешь паки, находишь карточки, закрываешь коллекцию и получаешь награду за прогресс.

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

А универсальность для нас — это не только возможность переиспользовать готовую механику. Это ещё и способ организовать разработку — влиять на скорость и в целом на настроение команды. 

Почему большой продукт можно менять за неделю, а не за полгода

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

Например, если другому подразделению нужен модуль заданий или рейтингов, ему не приходится собирать всё с нуля: мы берём готовый бэкенд, поверх него делаем нужный фронт и запускаем новую механику. Но микросервисы сами по себе не дают такой скорости. Важен ещё и подход к разработке. У нас он строится вокруг CI/CD и принципов Adaptive Agile.

Есть несколько способов выстраивать SDLC. Один из распространённых — собирать большой релиз из нескольких фич, а потом выкатывать всё одновременно. У такого способа есть очевидный риск: если одна фича задерживается, может сдвинуться весь релиз. 

Мы стараемся этого избегать. Для нас Adaptive Agile — это в первую очередь отсутствие процессов ради самих процессов. Мы не пытаемся следовать какому‑то фреймворку целиком — берём из разных подходов только то, что действительно помогает быстрее доставлять код пользователю. CI/CD в этом смысле позволяет выпускать изменения небольшими порциями, быстрее получать обратную связь и не связывать несколько независимых фич в один большой релиз.

Так изначально собирали и продукт под ЧМ. Он может работать самостоятельно, без PASS, и адаптироваться под любой вид спорта или событие. Этот подход влияет на скорость. Нам выгоднее потратить лишнюю неделю на разработку универсального решения сейчас, чем каждый раз собирать такую же механику с нуля. Ведь разработчики — самый дорогой ресурс в запуске спецпроектов, поэтому переиспользование позволяет одновременно экономить и выпускать больше продуктов.

Притом команда у нас небольшая. Над PASS работает продуктовая команда и разработчики, аналитик, CRM‑менеджер и другие специалисты, которых подключаем под конкретные задачи. 

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

А ещё для небольшой команды важно сохранить короткий цикл согласований. Сейчас достаточно моего «ока» в переписке, чтобы внести даже значительные изменения. 

Это работает и в обратную сторону: такой подход позволяет быстро проверять идеи, которые появляются у любого члена команды. Аналитик может заметить проблему в данных, разработчик — предложить упростить пользовательский флоу, а дизайнер — изменить отдельный элемент UX. Мы обсуждаем такие предложения независимо от роли автора и, если идея подтверждается данными или помогает сделать сценарий лучше, быстро внедряем её. Так все ребята в команде могут влиять на то, каким получается продукт.

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

Что получилось в итоге

Было (2022-й, спецпроект под BLAST):

• одна аудитория — киберспорт;

• каждая новая фича в рамках РARI PASS — разработка с нуля с большим набором требований и глубоким тестированием;

• базовая продуктовая аналитика;

• стек — PHP и устаревший React.

Стало (сейчас):

• все виды спорта, множество сегментов аудитории с разными паттернами поведения;

• независимые микросервисы, которые переиспользуются между проектами;

• новые фичи выкатываются за неделю, а не за полгода (на ЧМ восемь изменений ушли в прод за семь дней);

• аналитика по каждому шагу пользователя, а не только по итоговым метрикам.

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

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