Как мы увеличили долю монетизируемых авторов внутри мобильной студии
Процесс + результат
О продукте
Мобильная студия — это мобильное приложение для авторов контента, которое позволяет управлять своим каналом RUTUBE. Пользователи могут загружать видео, проводить прямые эфиры, анализировать статистику канала и взаимодействовать с аудиторией
Проблема
Монетизация — один из ключевых драйверов удержания авторов в Мобильной Студии RUTUBE: чем больше авторов зарабатывает на контенте, тем выше их мотивация загружать видео, а значит — растёт вотчтайм и рекламная выручка RUTUBE
Бизнес-цель — увеличение доли авторов-партнеров
Обратился к аналитике — 24% авторов мобильной студии подходят под условия монетизации, но заявку на нее не подавали
Проблема заключалась в том, путь автора к монетизации в Мобильной Студии RUTUBE не существовал как сценарий
Дерево метрик Rutube
Моб. студия до монетизации
Исследование авторов
Кто целевой сегмент
Поднял разрез по типам: 88% авторов подходящих под условия — самозанятые. Официально зарегистрированы, данные уже где то зарегистрированы, но в заявке их каждый раз вводят вручную
Почему не доходят до заявки
Разобрал тикеты поддержки и регулярные исследования пользователей Мобильной Студии, часть авторов не знают:
- Может ли его контент монетизироваться вообще
- Какие условия надо выполнить
- Что заявка на монетизацию вообще существует и что в ней требуется
Что с теми кто доходит до заявки
Провел несколько глубинных исследований с авторами-партнерами о том как они заполняли заявку (в веб версии студии она существовала), основные озвученные проблемы:
- Большая ручная форма требует много времени на заполнение и отпугивает
- Причины отказа в ряде кейсов не ясны, не категоризованы
Синканулись с модерацией, собрали данные:
- Топ причин отказа на заявку: ошибки в полях заполнения, недостаточно документов или данных
- Ручная проверка вручную заполненных данных отнимает много времени
88% авторов самозанятые, их данные уже где-то есть
Для авторов непонятны условия монетизации
Существующая форма сложная как для авторов так и для модерации
CJM авторов
Разбил сценарий автора на части:
- Не знает о монетизации
- Знает условия
- Выполнил условия
- Подал заявку
- Заявка одобрена/отклонена
Цель — не «больше заявок», а больше заявок, которые проходят модерацию с первого раза
Целевые метрики:
- % Авторов дошедших до заявки
- % Авторов зашедших в заявку и отправивших её
- % Заявок, одобренных с первой попытки
Схема становления автора партнёром
Ограничения
Собрали технические и бизнес ограничения, на которые опирались при формулировании гипотез и проектировании сценариев
Бэк заявки один на веб и мобилку, переписывать под мобильный клиент нет возможности
Сроки релиза и ресурс разработки очень ограничены
Требования к заявке диктует комплаенс, дизайн их не упрощает — только объясняет
88% авторов мобильной студии подходящих под условия — самозанятые, их данные уже есть в госсистемах, но интеграции на текущий момент нет
Заявку подают три типа авторов — самозанятые, ИП и физлица. Состав документов и причины отказов у них разные
Гипотезы и приоритизация
Сформулировал проблемы по категориям авторов (Не дошел/Дошел до заявки) опираясь на исследование и CJM, на основе этого составил и приоритезировал гипотезы по решению этих проблем
Авторы, которые не дошли до заявки
Проблема 1Автор не знает, что монетизация вообще существует и доступна ему
В Студии нет точки входа. Узнать можно только извне или от поддержки
Гипотезы по решению
Авторы, которые не дошли до заявки
Проблема 2Автор знает про монетизацию, но считает, что не подходит
Условия сформулированы юридически и лежат вне продукта. Автор оценивает себя пессимистично и даже не проверяет
Гипотезы по решению
Авторы, которые дошли до заявки
Проблема 1Автор доходит до заявки, но она выглядит как большая непонятная анкета, и он откладывает
Одна длинная страница, непонятно, сколько это займёт и что понадобится
Гипотезы по решению
Авторы, которые дошли до заявки
Проблема 2Автор начинает заполнять, прерывается и не возвращается
Черновика нет, возврат означает начать сначала
Гипотезы по решению
Авторы, которые дошли до заявки
Проблема 3Автор заполняет и отправляет, но получает отказ по данным
Ошибка в поле или нехватка документа выясняется через недели, а не в момент ввода
Гипотезы по решению
Решение 1
Перед проектированием мы не знали где лучше разместить точку входа в страницу монетизации, на которой будут находиться:
- Для авторов не партнеров — условия и требования к монетизации, прогресс до нее
- Для авторов партнеров — баланс и аналитика по выплатам
Если авторы не будут её замечать, то это снизит конверсию в переход, как следствие уменьшит воронку по дохождению до заявки/получению выплат
Провели ресерч с помощью тепловой карте на pathway, по тому где больше заметно
- База: 426 респондентов
- Аудитория: авторы RUTUBE
- У 84% не подключена монетизация
В Nav bar
В Tab bar
Далее сделал дизайн каждого из шагов, который проходит автор перед тем как стать партнером. Основные сущности:
- Точка входа в монетизацию
- Прогресс, показывающий сколько автору осталось до подачи заявки на монетизацию
- Точка входа в заявку
- Статусы обработки заявки
Прогресс на главной и в монетизации
Точка входа в заявку → вебвью (Переход на веб версию студии)
Статус обработки — успешно
Статус обработки — отклонено
Тестирование и результат 1 решения
Релиз 1 решения сделал ровно то, на что был рассчитан: авторы узнали о монетизации и пошли в форму. Но форма не сумела обработать этот поток должным образом
Решение 2
Я провел серию глубинок с авторами, которые заполнили заявку в рамках 1 решения, какие у него оказались трейдоффы:
- Пользователь устал заполнять — а у нас нет возможности сохранить черновик, только заполнять с нуля
- Сессия периодически прерывалась по инициативе пользователя/ошибкам бека — пользователь отваливался на середине процесса и недозаполнял
- Прерывание опыта — внутри вебвью находится совершенно другой интерфейс, отличный от мобильной студии → увеличивается количество отказов
Нашей команде удалось согласовать возможность интеграции/закупки Госуслуг, это стало большой возвожности для роста показателей одобрения заявок и проектировании нативной пошаговой формы
Одной из задач было создать понятный степпер, который отобразит автору (внутри заявки и на главном экране) информацию о том, на каком шаге он находится и что он уже прошел
Вариант степпера
Вариант 1
Вариант 2
Вариант 3
Вариант 4Я спроектировал несколько вариантов, которые проверил на коридорном тестировании
Вариант 1 — счётчик у заголовка плюс бар у кнопки. «1 из 3» интерпретируется однозначно, однако счётчик и полоса дублируют друг друга и разнесены по разным концам экрана, надпись «1 из 3» конкурирует с заголовком за внимание
Вариант 2 — только сегменты. Занимает минимум места, однако число шагов приходится пересчитывать глазами, а закрашенный сегмент читается двояко: «этот шаг пройден» или «я сейчас здесь»
Вариант 3 — объединенный 1 и 2 варианты, отсутствует дублирование, однако занимает больше места, чем остальные, и разваливается после пяти-шести шагов
Вариант 4 — совмещает счётчик и прогресс в одном элементе: номер всегда там, где взгляд, но бегунок на полоске может читаться как элемент слайдера, а форма — перематываемой
Вариант степпера
Вариант 1
Вариант 2
Вариант 3
Вариант 4Выяснилось, что наиболее очевидным вариантом оказался третий. Люди смогли быстрее всего определить на каком шаге они находятся и сколько им еще осталось
После спроектировал редизайн заявки, который поможет улучшить опыт и довести пользователя до её одобрения быстрее и проще:
- Вынес выбор типа автора вперёд и объяснил его. Было: сухой список — самозанятый / ИП / физлицо. Люди останавливались и спрашивали «а мне какой и для чего?»
- Переработал большую форму в последовательную с шагами: Создание кошелька → Авторизация в госуслугах → Отправка данных → Ожидание модерации
Пошаговая форма
Пошаговая форма
Черновик заявки
Перед запуском провел исследование на 9 авторов
- По типу: самозанятые
- По опыту: те, кто уже подавал заявку
Результаты: все респонденты дошли до конца, новых блокеров не нашли
Принято решение запускать пошаговую форму в релиз
Общие результаты
Решение 1
→ отправил заявку
Решение 2
→ отправил заявку
По данным аналитики в Мобильной студии самая высокая доля партнеров среди остальных продуктов
Гипотезы развития
Как планируем дальше развивать функционал
- Перенос сценария на ИП и юрлиц. Мы оптимизировали под самозанятых как под массовый сегмент, ИП и юрлица — дополнительная точка роста
- Предпроверка контента до подачи. Автор узнаёт о нарушении до того, как потратил время на заявку. Шаг зависит от модерации
- Уведомление о смене статуса заявки. Сейчас автор узнаёт об отказе, только когда сам зайдёт в приложение или посмотрит электронную почту
- Прогноз выполнения условий в виджете. «При текущем темпе вы выполните условие примерно через N дней». Дополнительная мотивация, но технически дорого
