Я прочитал правила Sber500xDisrupt. 35 обращений оказались совсем не тем, что я думал

Я думал, что требование 35 обращений означает 35 действий пользователя в сутки. Положение Sber500xDisrupt показало другую механику - и одновременно гораздо яснее обозначило главный риск моего продукта.

В прошлой статье я написал, что заявку в Sber500xDisrupt уже отправил и независимо от результата отбора собираюсь продолжать исследовать выбранную гипотезу.
После этого я внимательно прочитал само Положение о конкурсе.
И некоторые вещи стали выглядеть совсем иначе.

Главное открытие касается тех самых 35 обращений на одного активного пользователя в день.
Сначала я понимал эту метрику буквально: человек должен открыть ИИ-таролога и 35 раз что-то у него спросить за сутки.

Если бы продукт действительно нужно было проектировать вокруг такого поведения, мне было бы сложно увидеть в этом естественный пользовательский сценарий.
Но в Положении под обращением понимается совсем не обязательно сообщение пользователя.

35 обращений - это не 35 сообщений пользователя

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

В самом Положении приведён хороший пример.
Пользователь один раз просит ИИ-консьержа найти и забронировать ресторан с рыбной кухней.

Для человека это одна задача.
Но внутри Решения происходит пять вызовов: DeepSeek, Firecrawl, GigaAM, GigaCaller и отдельный навык консьержа.
Для конкурсной метрики это 5 обращений.
Для меня это принципиально меняет смысл показателя.

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

Для пользователя это может оставаться одним цельным действием.
Внутри системы при этом происходит несколько вызовов разных компонентов.

То есть 35 обращений в правилах конкурса не означают, что человека нужно заставить 35 раз написать боту.

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

Для конкурса это очень существенная деталь.

Это не означает, что архитектуру можно дробить ради счётчика

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

Тестовые обращения, отладка и действия, не связанные с реальным пользовательским сценарием, в зачёт не принимаются. Искусственное увеличение метрик, бот-трафик, массово созданные аккаунты и стимулированная активность, которая не отражает реальное использование продукта, запрещены.

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

Главный барьер для меня теперь не 35 обращений

Чтобы вообще стать финалистом, сначала нужно пройти общий порог.
В Положении DAU расшифровывается как число уникальных реальных пользователей, воспользовавшихся Решением в течение календарных суток.

Для выхода в финал нужно одновременно показать средний DAU не менее 1000 за зачётный период и добиться того, чтобы значение DAU было не ниже 1000 минимум в 14 из 28 календарных дней.
Кроме этого, требуется не менее 10 обращений к Решению на одного DAU в среднем за сутки, а само Решение должно пройти антифрод-контроль и технический аудит.

И только после этого начинается соревнование внутри отдельных номинаций.

• В «Высокочастотной поверхности» нужно показать не менее 35 обращений на одного DAU в среднем за сутки. Побеждает финалист с максимальным подтверждённым значением.
• В «Массовом охвате» нужен DAU не менее 2 500, причём этот показатель тоже должен быть устойчивым за зачётный период.
• В номинации «Лучший пользовательский опыт и дизайн» сначала тоже нужно стать финалистом, после чего продукт оценивают эксперты.

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

Времени на раскачку почти нет

Первый этап заканчивается 14 октября.
К этому моменту нужно создать работающую минимально жизнеспособную версию продукта (MVP), провести не менее 20 клиентских интервью, привлечь не менее 50 реальных пользователей, вывести Решение в открытый контур, подключить аналитику и подготовить концепцию вывода продукта на рынок.

На второй этап допускают не более 50 команд.
Сам второй этап длится до 14 декабря, но конкурсные метрики измеряются за единый четырёхнедельный зачётный период, заканчивающийся 30 ноября.

Это значит, что к середине октября нельзя прийти просто с работающим приложением и мыслью: теперь начну разбираться, где искать людей.

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

Это хорошо попадает в мою слабую сторону

В первой статье новой серии я писал про «Говори дело» и «Дожми встречу».
В двух продуктах в совокупности было почти две тысячи пользовательских регистраций и более 51 тысячи сообщений.

То есть собрать работающий ИИ-продукт и привести туда первых пользователей я умею.
Но системного опыта масштабирования потребительского продукта до тысяч ежедневных активных пользователей у меня нет.

Оба предыдущих сервиса создавались вокруг Telegram. Для быстрого запуска это было удобно, но одновременно слишком сильно связало и интерфейс, и распространение с одной платформой.
Технически я могу перенести продукт в веб, MAX или другой интерфейс.

Но перенос не отвечает на главный вопрос.
Как получить следующие сто пользователей?
Потом тысячу?
Почему они вернутся завтра?
Какой канал привлечения можно масштабировать?
Сколько стоит активный пользователь?
За что он готов платить?

После чтения Положения я ещё яснее вижу, что именно это и будет главным экспериментом.

На первом этапе Сбер смотрит не только на MVP

Отбор на второй этап строится не вокруг одного факта, что приложение запускается.

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

То есть к концу первого этапа нужно показать не просто продукт.
Нужно показать первые данные и объяснить, почему из первых 50 пользователей потенциально могут появиться следующие сотни и тысячи.

Мне такой критерий понятен.
Он довольно быстро отделяет техническую демонстрацию от продукта, который пытается жить на рынке.

Номинация за пользовательский опыт тоже оказалась конкретнее, чем я ожидал

В номинации «Лучший пользовательский опыт и дизайн» Решение тестируют не менее трёх внутренних экспертов.

Есть 6 критериев, каждый оценивается от 0 до 10 баллов.
Смотрят:

1. понимает ли пользователь сценарий без внешней инструкции,
2. насколько быстро получает первый полезный результат,
3. как продукт обрабатывает ошибки,
4. понятна ли работа системы,
5. насколько целостно выглядит интерфейс
6. удобно ли им пользоваться на заявленных устройствах.
   Максимальная итоговая оценка - 60 баллов.

Для моего будущего MVP это хороший ориентир.
В продукте с Таро очень легко уйти в красивую мистическую оболочку и заставить человека пройти десять экранов до первого результата.

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

С интеллектуальной собственностью всё серьёзнее

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

По условиям конкурса Решение должно быть создано с нуля в период проведения конкурса.
Определение результатов интеллектуальной деятельности (РИД) при этом широкое. В него входят:

1. созданные в период конкурса исходный и объектный код,
2. алгоритмы, архитектура, интерфейсы,
3. дизайн, документация,
4. подготовительные материалы, входящие в Решение.

Мой уже существующий личный прототип ИИ-нумеролога-таролога поэтому полезен как опыт и источник продуктовых гипотез.
Но конкурсный продукт, если меня допустят, нужно создавать отдельно.
И я точно не хочу строить его по схеме, где внутри конкурсного Решения одновременно окажется универсальное ядро моих продуктов, которое потом используется в других продуктах.

Это уже не только инженерная аккуратность.
Это граница интеллектуальной собственности.

Репозиторий придётся показать уже на первом этапе

Положение требует предоставить Организатору доступ на чтение к репозиторию.
Это нужно для технического аудита и подтверждения того, что Решение действительно создано с нуля в период конкурса.

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

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

Приз тоже оказался не просто призом

Фонд конкурса составляет 30 миллионов рублей.
Но каждая выплата победителю состоит из двух частей.

70 процентов приходится на денежную награду за выполнение конкурсного задания.
30 процентов - на вознаграждение за отчуждение исключительных прав на РИД.

• Для «Высокочастотной поверхности» это 10,5 миллиона рублей награды и 4,5 миллиона за РИД.
• Для «Массового охвата» - 7 и 3 миллиона.
• В номинации за пользовательский опыт первое место даёт 2,1 миллиона награды и 900 тысяч за РИД, второе - 1,4 миллиона и 600 тысяч соответственно.

Все суммы указаны до удержания НДФЛ. Для меня это важное уточнение.
Когда я вижу фразу «приз 15 миллионов», теперь понимаю, что 4,5 миллиона из этой суммы прямо связаны с передачей исключительного права.

Что я понял про возможную передачу РИД

Положение описывает следующую последовательность.

1. Сначала Жюри определяет победителей.
2. После этого Организатор направляет победителю проект договора об отчуждении исключительного права на РИД и акт приёма-передачи.
3. Для выплаты среди обязательных документов нужны подписанные оригиналы договора и акта. Если необходимые документы не предоставлены, соответствующие выплаты не производятся.
4. Если правообладателей несколько, документы должны подписать все правообладатели. Неподписание хотя бы одним из них исключает возможность отчуждения РИД.

Из самого Положения я не хочу делать более широкий юридический вывод о последствиях возможного отказа от подписания.
Тем более в документе отдельно закреплено преимущественное право Сбера на заключение с победителем договора об отчуждении исключительного права.

Если я когда-нибудь дойду до этой точки, правильным следующим шагом будет не моя трактовка статьи конкурса, а разбор конкретного договора с юристом.
Сейчас для меня важнее другое: заранее не смешивать конкурсное Решение с интеллектуальной собственностью, которую я не собираюсь включать в такую сделку.

Для моего продукта есть ещё один сложный блок - персональные данные

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

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

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

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

После чтения Положения гипотеза стала для меня интереснее

Не потому, что правила подтвердили сам продукт.
Они ничего не говорят о том, нужен ли людям мой ИИ-нумеролог-таролог.

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

А задача тысячи реальных дневных активных пользователей от этого легче не стала.
И именно она теперь выглядит главным испытанием.

Поэтому следующий вопрос уже не про правила конкурса

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

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

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

А следующий вопрос для меня уже совсем практический.
Почему люди сегодня удаляют приложения Таро, астрологии и персональных ИИ-ассистентов?
Что в них раздражает?
Где они ошибаются?
Чего пользователям не хватает?
И что из этих жалоб действительно стоит превращать в требования к новому продукту?

Похоже, именно с этого и нужно начинать разработку.