Собственное новостное приложение: как на MVP проверили окупаемость рекламы

Проверка бизнес-модели на работающем продукте

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

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

Мобильное приложение разрабатывал отдельный специалист. Я отвечал за всю серверную часть: сбор и обработку новостей, API для приложения, рекламную систему и её веб-кабинет.

Как отделяли новые новости от повторов

Агрегатор получал новости двумя способами: парсил часть источников и забирал данные из других по API. При таком сборе одна история попадала в поток несколько раз: издания публиковали свои версии, перепечатывали материалы и выпускали продолжения. Без обработки пользователь видел бы ленту, заполненную повторами.

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

Обработанные материалы распределялись по категориям, сохранялись и передавались в мобильное приложение через API. Агрегатор исправно обеспечивал приложение новостями.

Управление объявлениями и подключение внешних сетей

Для показа рекламы я разработал первую версию DSP, рекламной платформы для этого приложения. В нём было несколько рекламных блоков, расположенных в разных местах. Веб-кабинет позволял задавать места показа и выбирать креативы; серверная часть отвечала за распределение показов и ротацию объявлений.

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

Скорость выбора рекламы и учёт показов

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

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

Что показали установки и финансовый расчёт

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

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

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