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

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

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

Что приложения MCP добавляют к обычным инструментам MCP?

Приложения MCP добавляют интерактивное представление View к результату инструмента MCP. Обычный сервер Model Context Protocol предоставляет инструменты и ресурсы. Модель может вызвать инструмент, а хост может показать текст или структурированные данные. Расширение Apps позволяет инструменту указать ресурс ui:// с HTML, который хост отображает в изолированном iframe. View получает входные данные и результаты инструмента, а затем общается с хостом через JSON-RPC и postMessage.

Это разделение имеет практическое значение. Модель по-прежнему выбирает и вызывает инструмент. Сервер по-прежнему отвечает за бизнес-логику и доступ к данным. Хост по-прежнему управляет диалогом, экранами согласия и iframe. View дает пользователю элементы управления там, где обычный язык неудобен: для фильтрации графика, настройки нескольких зависимых параметров, выбора строк, просмотра медиа или подтверждения действия с серьезными последствиями.

Официальная спецификация MCP Apps от 2026-01-26 определяет четыре части, которые стоит запомнить: заранее объявленные UI-ресурсы, метаданные для связи инструмента с ресурсом, двустороннее взаимодействие и обязательную изоляцию iframe. Она также требует согласования возможностей. Хост сообщает о поддержке расширения io.modelcontextprotocol/ui и доступных MIME-типов. Сервер должен возвращать содержательный текст даже при наличии интерфейса, чтобы инструмент корректно работал в хосте без поддержки Apps.

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

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

Дистрибуция смещается от привлечения к вызову

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

Единица обнаружения тоже меняется. Страница сайта конкурирует за переход. Карточка мобильного приложения конкурирует за установку. Инструмент MCP конкурирует за право стать лучшим объявленным действием для конкретного намерения. На выбор влияют его имя, описание, схема входных данных, требования к аутентификации и надежность, которую наблюдает хост. Интерфейс появляется только после выбора, поэтому красивый View не спасет расплывчатый контракт инструмента.

Командам следует отдельно отслеживать три уровня дистрибуции:

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

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

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

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

Переносимость не устраняет различия между хостами

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

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

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

По краям процесса аутентификация тоже зависит от хоста. Удаленный MCP-сервер может применять стандартный процесс авторизации, но привязка аккаунта, повторный вход и показ согласия могут отличаться. Постройте сервер так, чтобы идентичность и права по тарифу оставались за границей инструмента. View должен получать только данные и действия для текущей задачи. Если другой хост изменит origin iframe или работу хранилища, платные права пользователя не должны исчезнуть вместе с локальным состоянием браузера.

Перед обещанием «работает везде» составьте небольшую матрицу совместимости. Запишите транспорт подключения, поддержку расширения Apps, возможности хоста, поведение рамки, завершение аутентификации, подтверждение инструментов и закрытие View. Проверьте одну эталонную задачу в каждом хосте. Результат должен быть равноценным, даже если оформление отличается.

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

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

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

Рассмотрим продукт для управления расходами на облако. Запрос «Покажи расходы» даст график, но намерение останется слабым, а завершение задачи неясным. Запрос «Найди сервисы, размер которых можно уменьшить, разреши исключить продакшен и подготовь одобренные изменения» создает цикл решения. Модель собирает область анализа, сервер рассчитывает варианты, View позволяет изучить и исключить строки, а отдельный инструмент готовит или применяет разрешенное действие. Интерфейс оправдывает свое место, потому что визуальное сравнение и выбор лучше серии повторных запросов.

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

1. Запишите запрос пользователя, который должен вызвать первый инструмент. Если для него нужен абзац терминов вашего продукта, обнаружение будет слабым.
2. Опишите решение, которое упрощает View. Если ответ звучит как «посмотреть наш продукт», лучше сделайте веб-страницу.
3. Назовите событие завершения: например, утвержденный бюджет, отправленная конфигурация, экспортированный выбор или закрытый инцидент.
4. Укажите, что получит хост без Apps. Если запасной вариант не дает полезного результата, контракт сервера слишком зависит от View.

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

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

Контракт инструмента и есть поверхность продукта

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

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

Эта форма запроса и ответа достаточно компактна для контрактного теста:

{
  "name": "review_release_risks",
  "arguments": {
    "repository": "acme/payments",
    "releaseWindow": "2026-08-14",
    "minimumSeverity": "medium"
  }
}

Успешный результат должен сохранять полезный текстовый вариант и передавать View стабильные данные:

{
  "content": [
    {
      "type": "text",
      "text": "Found 3 release risks. One is high severity and two are medium."
    }
  ],
  "structuredContent": {
    "reviewId": "rr_1842",
    "risks": [
      {
        "id": "risk_31",
        "severity": "high",
        "reason": "Database migration has no rollback command",
        "suggestedAction": "Add and test a down migration"
      }
    ]
  }
}

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

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

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

Доверие входит в воронку установки

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

Спецификация Apps дает командам полезное ограничение: View работает в изолированном iframe, а хост формирует Content Security Policy по объявленным метаданным. Если приложение не укажет домены CSP, строгая политика по умолчанию заблокирует внешние подключения и ресурсы. Хост может дополнительно ужесточить политику, но не вправе разрешить необъявленный домен. Это хороший исходный режим. По возможности собирайте View в один пакет и объявляйте минимальный набор действительно нужных origin.

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

Официальный реестр проверяет, что издатель контролирует пространство имен GitHub или домена. В его документации прямо сказано, что проверка программного кода передана реестрам пакетов и нижестоящим агрегаторам. Проверка пространства имен отвечает на вопрос «кто это опубликовал?». Она не отвечает на вопрос «безопасна ли реализация?». Зафиксируйте это различие в материалах для продаж и внутренних проверках, чтобы никто не принимал запись в реестре за сертификацию.

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

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

Монетизация остается связанной с сервером и аккаунтом

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

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

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

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

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

В консалтинге или аудите полезное приложение может остановиться до автоматического исполнения. Оно способно собрать структурированные доказательства, показать картину затрат или процесса и сделать объем человеческой работы понятным. На oleg.is эта логика ведет к Team & AI Audit, когда данные показывают дублирование инженерной работы или слабые практики применения ИИ; приложение должно обозначить границы проблемы и не притворяться, будто виджет в чате заменит руководство.

Сигналы выручки появляются раньше самой выручки

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

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

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

Наблюдайте за сигналами в таком порядке:

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

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

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

Выпускайте продукт тремя контролируемыми релизами

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

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

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

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

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

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

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

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

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

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

Долговечное преимущество находится за View

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

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

Приложения MCP также делают узкие продукты более жизнеспособными. Обычному SaaS нужна достаточно большая поверхность, чтобы оправдать отдельное место, куда приходит пользователь. Приложение может встретить его внутри существующего места и хорошо выполнить одну задачу. Стоимость упаковки снижается, но слабые продукты раскрываются быстрее. Если сервер лишь оборачивает распространенный API общими описаниями, хост или другой сервер сможет его заменить.

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