Привет! Меня зовут Даня, я аналитик данных в Wallet. Хочу рассказать, как мы выбрали и рассчитали центральную метрику «о деньгах» для команды «Каталог» в приложении «Кошелек».
Я также расскажу вам, почему этот показатель (спойлер: это RPS) оказался не совсем тем, что мы искали.
Как выглядит Каталог в Кошельке? Кошелек — это приложение, с помощью которого уже покупают и сохраняют более 13 миллионов человек.
А команда Каталога отвечает за платформу, которая позволяет пользователям выпускать новые карты, участвовать в различных акциях, подавать заявки на банковские продукты и многое другое.
Нам нужен был центральный показатель, показывающий эффективность всех видов размещения.
Выбор пал на Revenue Per Show (RPS) — доход с одного показа оффера.
RPS = доход / показы.
Звучит довольно просто, но дьявол, как всегда, кроется в деталях.
Давайте разберемся, какие именно.
Почему вы вообще выбрали RPS?
Для оценки эффективности нашего направления каждой команде была присвоена определенная метрика.Критерии выбора были следующими:
- Метрика должна показывать эффективность бизнес-подразделения.
- Бизнес-подразделение должно иметь влияние на этот показатель.
- Метрика должна мотивировать руководство совершать правильные действия, которые не принесут вреда другим подразделениям и пользователям.
- Один показатель, один ответственный.
- Действия других подразделений могут повлиять на метрику, но незначительно.
Нет ничего плохого, если они оказывают положительное влияние.
Если они оказывают негативное влияние, ответственное подразделение должно принять меры для улучшения показателя.
Как используется РПС? RPS очень похож на показатель eCPM, широко используемый в рекламе.
eCPM — эффективная стоимость за тысячу показов.
Это важный показатель в мобильной рекламе, который помогает сравнивать эффективность различных типов рекламы и оптимизировать их для увеличения дохода.
Почему RPS в кошельке? Наша гипотеза заключалась в том, что RPS поможет оценить и оптимизировать нашу стратегию монетизации, позволяя нам увидеть, как мы используем показы по отношению к зарабатываемым деньгам.
Кроме того, с помощью этой метрики мы могли сравнивать эффективность разных платформ, отображать локации в разрезе структурных элементов приложения, отдельных компонентов и конкретных продуктовых предложений.
Наша продуктовая команда отвечала за различные сайты:
- Сам Каталог — это как отдельная вкладка Кошелька.
- Разместите под картами лояльности.
- Часть места на главной странице приложения.
- Веб-ресурс.
Собственно, нам нужно было оценить эффективность этого разнообразия.
RPS, в свою очередь, мог бы рассказать об эффективности показа различных предложений в приложении относительно заработанных денег.
Эту информацию можно использовать для повышения эффективности стратегий монетизации за счет оптимизации размещения предложений и внедрения новых функций.
Мы должны были сделать это с помощью:
- Формирование таргетированных подборок с высоким RPS для определенных сегментов пользователей.
- Выведение предложений с высоким RPS на главный Каталог и на главный экран приложения.
- Повышение конверсии релиза: изменение текстов, картинок, разработка сценариев релиза.
- Внедряйте более эффективные визуальные компоненты.
Какие трудности возникли
Трудно посчитать Первая трудность возникла сразу после утверждения метрики – как ее рассчитать? Дело в том, что в Каталоге много партнеров с разными типами и даже механиками монетизации.Что можно делать с Справочником? Пользователь может оформить новую карту, и тогда она появится в его приложении, он может принять участие в розыгрыше или акции, отсканировав квитанцию внутри Каталога, он может подать заявку на выпуск банковской карты, перейдя из приложение на сайт партнера и т.д. При этом каждая механика монетизируется по-разному.
Да, даже один и тот же сценарий в зависимости от соглашения с партнером имеет разные виды оплаты.
Почему это была проблема Например, пользователь может подать заявку на получение дебетовой карты через Каталог.
Банк должен его одобрить, донести до пользователя, и только после первой транзакции скрипт монетизируется.
Получается, что о части выручки мы изо дня в день не знаем и должны либо отбрасывать ее, либо каким-то образом прогнозировать.
И чтобы принимать решения, нам нужно ежедневно видеть динамику RPS и общий доход. Кроме того, на тот момент рассчитывать выручку было сложнее, чем сейчас.
У нас не было полной автоматизации и прозрачности инструментов.
Например, у некоторых команд не было единого шаблона учета доходов.
Поэтому на помощь пришли танцы с бубном и щепотка шаманства:
- Написание скрипта PowerShell, который импортирует из каталога синхронизированные «облачные» файлы Excel и преобразует их в *.
csv в виде пар ключ-значение.
- Вставка и выполнение ряда преобразований на стороне MSSQL с использованием хранимой процедуры.
- Обработка полученной таблицы в Python.
Теперь мы увидели его целевое значение и добавили разбивку по платформам (iOS/Android), различным экранам — сценариям, доходам от разных типов продуктов и самому количеству показов.
Мы даже подтянули старые архивы Excel, чтобы посчитать показатели за последние 1,5 года.
Видим цель – идем к цели! Пришло время строить планы по его росту.
Вначале мы говорили, что RPS состоит из двух частей — выручка в числителе и количество показов в знаменателе.
Поэтому для увеличения метрики в реалиях Кошелька можно было пойти тремя путями:
- Поощряйте пользователей выпускать больше продуктов.
- Повышение тарифов для партнеров.
Более того, наша команда ничего не могла с этим поделать, так как мы не согласны с нашими партнерами.
- Оптимизируйте размещение предложений в Каталоге.
Это именно то, для чего мы хотели использовать RPS.
Получается, что здесь мы влияем на метрику лишь весьма косвенно.
Трудности с интерпретацией и принятием решений.
Из предыдущего пункта следует, что мы были бессильны ответить на вопрос: какие выводы нам следует сделать, используя RPS? Мы смогли правильно посчитать метрику, знали, что на нее влияет, видели, как она то падает, то растет, ничего не понимали и не могли сделать вменяемых выводов.
Короче говоря, это не помогло нашей команде принять решения.
Почему RPS не оптимален
Потому что в результате наших усилий мы получили метрику, которая:- Точно подсчитать сложно, поскольку не все действия пользователя можно четко связать с «деньгами».
- Его можно назвать ненадежным, поскольку он не вызывает у нас доверия в силу пункта 1.
- Не может быть использован для оценки нашей команды, так как зависит от работы многих других команд.
- В нашей команде сложно регулировать ситуацию.
- Не может использоваться для принятия каких-либо решений из-за пункта 4.
- Пришлось «наращивать мясо» из других метрик — разделить каждую часть выручки на команды и пойти глубже.
Но мы решили пойти другим путем, об этом чуть позже.
- Трудно интерпретировать: партнер А приносит нам 1000 USD, мы показали ему 10 000 раз, RPS = 0,1. Партнер Б приносит нам $10 000, но мы показали ему 200 000 раз, RPS = 0,05. Несмотря на то, что RPS у Б в два раза меньше, он принес нам в 10 раз больше денег.
Это могло бы сработать для многих компаний и команд, но не для нас.
Дальнейшая судьба РПС Метрику RPS можно использовать для оценки совместной работы коммерческой и продуктовой команд. Это хорошо отвечает на вопрос, как эта группа команд использует внимание пользователей.
Но ни одна команда не несет полной ответственности за метрики.
Также можно было уточнить значение RPS для конкретного баннера в каталоге.
Тогда мы могли бы оценить эффективность оффера или целой категории с офферами не только с точки зрения конверсий, но и с точки зрения денег, что было бы гораздо эффективнее.
Но мы от этого отказались из-за очень сложной технической реализации.
Нам нужно построить пирамиду
Мы рассматриваем, изучаем и обсуждаем ПСР уже несколько месяцев.В результате мы пришли к одному простому, но концептуально важному выводу — наша продуктовая команда не влияет напрямую на деньги.
Также мы поняли, что Каталог приносит в кошелек дополнительную ценность, помимо основной — удобно хранить все свои карты в кошельке и показывать их на кассе.
Решение: Мы пытаемся выделить Каталог как техническую платформу, не отвечающую за качество контента и, главное, за доход. Новое задание: постройте пирамиду командных метрик, которая покажет, как работает платформа Каталога и все движения внутри нее.
Критерии, на которые мы опирались при его разработке:
- Пирамида должна отражать все основные метрики Каталога, на которые мы можем влиять.
- Глубина метрик должна быть достаточной, чтобы понять, что мы повлияли на метрики.
- Цели Каталога сформулированы и описаны, и мы их придерживаемся.
Пример использования фреймворка, на котором мы сосредоточились Конечно, пришлось его немного адаптировать и доработать две категории:
- Вместо Счастья пользователей у нас было «счастье» наших внутренних клиентов, для которых мы разрабатываем инструмент наполнения Каталога.
- В категории «Успех задач», ориентированной на эффективность решения пользовательских задач, присутствовали технические метрики доступности и производительности платформы (скорость загрузки каталога, количество ошибок при выдаче карт и т. д.).
- цель - что мы хотим получить.
- сигнал — что в поведении пользователя будет указывать на успех или неудачу.
- метрики – количественное выражение сигнала во времени.
- задания — что нам нужно понимать, используя категорию
| Категории | Задача | Цели | Сигналы | Метрики |
| Счастье | Определите, как клиенты относятся к инструменту администрирования каталога.
| Повысьте удовлетворенность клиентов с помощью CAT | • Клиенты оценивают продукт • Участвовать в опросах | • Результаты опроса • НПС |
| Обручение | Определить частоту и глубину взаимодействия с Каталогом | Увеличить время взаимодействия с Каталогом и количество сессий | • Пользователи постоянно посещают Каталог • Потребление контента | • % пользователей, которые входят в Справочник • Количество просмотров • Средняя продолжительность сеансов в Каталоге • Средняя глубина сеанса |
| Принятие | Определить, в какой степени пользователи принимают Справочник и его возможности.
| Увеличение количества новых пользователей Каталога.
Увеличение количества существующих пользователей, использующих Каталог.
| • Выпуск продуктов • Нажмите на контент • Используйте навигацию по каталогу.
| • Количество показов • Среднее количество показов за сеанс.
• Количество выпусков продукта • % пользователей, которые входят в систему и публикуют что-либо |
| Удержание | Определите, как часто пользователи возвращаются в Каталог и совершают целевое действие | • Увеличьте жизненный цикл пользователей и сократите их отток.
• Все пользователи чаще посещают Каталог. • Сократить количество пользователей, которые посетили Каталог один раз и больше никогда не посещали его.
| • Пользователи перестают заходить в Каталог, но заходят в приложение | • Неделя хранения 1 (в каталоге) • % посещений Каталога от общего количества посещений приложения • % пользователей MAU, которые никогда не посещали Каталог |
| Успех задачи | Определить, позволяет ли техническая составляющая продукта успешно решать проблемы пользователей.
| • Увеличьте время отклика и производительность с помощью каталога.
• Уменьшить количество технических ошибок | • Пользователи могут воспользоваться всеми возможностями Каталога в удобное для них время.
| • Среднее время загрузки служб каталога.
• Службы каталога времени безотказной работы • Время работы Справочника с точки зрения пользователя.
|
Затем мы визуализировали метрики в Miro. Это был бесконечный вихрь бумажек, связей, интерпретаций и возможных сценариев, но мы справились.
Мы не торопились и полагались как на опыт других продуктовых команд Wallet, так и на внешнюю экспертизу.
Но достаточно быстро дашборд со всеми метриками уже работал в Power BI.
«Они пытались» или почему пирамида метрик тоже не помогла
У нас было довольно много метрик для одной команды (18 разных показателей), они были разделены на категории и были нам понятны.Каждая группа показателей имела конкретную цель и давала нам конкретную информацию.
Но.
время идет, а все эти показатели по-прежнему не помогают нам принимать решения, а стратегия развития не строится на метриках.
Нашей ключевой целью было не создание пирамиды метрик ради пирамиды метрик.
Нам нужен был инструмент, с которым мы могли бы связать большую часть работы над нашим продуктом.
Инструмент, который бы достоверно показывал, насколько значимы наши действия для продукта и пользователя.
Так почему же пирамида показателей все еще не является оптимальным решением?
- У нас не было целевые показатели (целевая метрика) — показатели того, к чему движется вся команда в глобальном масштабе.
Мы изначально не сформулировали цель Каталога и поэтому не знали, в каком направлении идем.
- Вся наша пирамида метрик состояла из показателей движущая сила (метрика драйвера) и ограничительные индикаторы (охранная метрика).
Первый тип метрик отражает гипотезы о факторах успеха, а второй защищает от ошибочных гипотез.
- Мы постарались описать, как одна метрика влияет на другую, и что мы будем делать, если показатель вырастет или упадет. Но у нас не было конкретных и четких гипотез.
Мы думали, что наша пирамида показателей расскажет нам об успехе, но она говорит нам, насколько успешно мы к нему движемся.
Изменение показателей не должно быть целью.
- Нам было сложно связать наши показатели с ключевыми метриками и целями всей компании.
Мудрость басни «Лебедь, Рак и Щука» сработала и здесь.
Учимся на своих ошибках
Мы понимали, что пытаемся создать систему метрик для принятия решений практически с нуля, и поэтому не слишком расстроились.Мы оценили наши предыдущие попытки как вклад в «светлое будущее», где каждое решение основывается на правильных и контролируемых цифрах и данных, поэтому риск ошибиться сведен к минимуму.
Следовательно, мы продолжили нашу работу с еще большим энтузиазмом и пришли к следующим шагам:
- Определите цель команды простыми словами.
Четко сформулируйте его и согласуйте, чтобы оно было связано с развитием компании в целом.
- Выделите несколько ключевых метрик (мы пришли к выводу, что выделить одну метрику «Полярной звезды» мы не можем, да и нет в этом необходимости).
- Согласуйте наши ключевые показатели с целями всей компании.
Это не значит, что наши ключевые показатели будут такими же, как у всей компании.
Одна и та же метрика может играть совершенно разную роль для разных команд. Это означает, что наши задачи направлены на повышение целевых показателей компании.
- Сформулировать гипотезы достижения цели.
К каждой гипотезе прикрепим метрики (это будет наша пирамида метрик).
Чтобы понять, что выбранные показатели движущей силы влияют на целевые показатели, проведем кастдевы (подробнее об этом ниже) и опросы; анализировать исторические данные; провести точечные A/B-тесты, направленные на оценку причинно-следственной связи между показателями.
- Убедитесь, что каждая метрика предоставляет дополнительную информацию и не копирует существующую информацию.
- Постоянно работайте над пирамидой метрик.
Потому что по мере развития компании, сферы бизнеса в целом и нашего понимания показатели могут и, скорее всего, будут меняться.
- Встречайтесь с командой каждые две недели и обсуждайте, понимаем ли мы, куда именно идем, и говорят ли нам об этом наши текущие метрики.
Каждая встреча и ее результаты документируются и собираются на одной странице.
- Встречайтесь с другими командами каждые несколько месяцев и делитесь мнениями и подходами к пирамиде показателей.
Как определить цели и гипотезы для построения работающей системы показателей
Мы начали с того, что попытались определить полезность Каталога для пользователя, поскольку до этого мы всегда говорили только о глобальной ценности всего приложения Wallet. Для этого нужно было понять, какие потребности пользователей позволяют нам решить возможности Каталога, какое поведение они имеют на данный момент и как мы можем этим поведением управлять.Поэтому мы провели серию интервью, опросов и UX-исследований (все это в народе называется custdev).
Custdev был ориентирован именно на нашу команду и наши потребности: мы стремились проникнуть в головы наших пользователей, чтобы понять, как пользователи видят Каталог и почему они его используют. У нас были свои гипотезы на этот счет, основанные на ощущениях внутри команды «Каталога».
Что мы сделали:
- Мы разделили пользователей в Каталоге на сегменты с разным поведением, определили цели исследования и гипотезы, которые мы должны либо опровергнуть, либо подтвердить, изучая пользователей.
- Мы создали шаблон для каждого интервью, чтобы не забыть задать ключевые вопросы, и собеседник не уносил свои мысли куда-то далеко.
- Поймите свою миссию с точки зрения пользователя.
Пользователь, получивший ценность, – это не тот, кто оформил как можно больше карт или принял участие в куче акций, а тот, кто смог сэкономить благодаря Каталогу.
- Собирайте информацию о том, как пользователь использует Каталог и почему.
- Проверьте наши гипотезы — мы действительно часто думали одно, а пользователи говорили нам совсем другое.
- Генерируйте множество идей и совершенно новых гипотез для развития Каталога.
- Выбирайте направление движения — идей на самом деле всегда было много, но благодаря более глубокому изучению потребностей пользователя вектор развития стал гораздо ярче, а часть идей отсеялась сама собой.
- Запустите еще три опроса и начните новое исследование по изменению UX-дизайна всего Каталога.
На входе в Каталог мы видим пользователя с желанием сэкономить, а на выходе должен быть пользователь с намерением и возможностью получить эту выгоду.
Понимание этого, а также общих целей компании дает нам четкие границы при выборе целевых показателей каталога.
Теперь у нас также есть материал для формулирования гипотез успеха команды, на который мы будем «нанизывать» метрики и тестировать их в дальнейшем.
Чем быстрее и лучше мы помогаем пользователям экономить, тем ценнее для них будет наш продукт. Это найденное сообщение сразу позволяет нам генерировать идеи и возможные функции, не разбрасываясь мелкими изменениями.
Более того, мы теперь понимаем, как можем развиваться в будущем:
- По горизонтали — увеличение стоимости за счет решения новых задач в сценарии экономии пользователя (просто говоря, мы разрабатываем другие сценарии экономии, где речь идет не только об экономии денег, но и об экономии времени).
- По вертикали – увеличить ценность за счет более эффективного решения текущей задачи (сделать интерфейс удобнее, увеличить разнообразие предложений и т. д.).
Мораль истории
Мы продолжаем и будем продолжать работать над пониманием того, какие метрики нужны и зачем.И кажется, что мы только в начале пути.
Но и до этого начала путь был очень тернист и запутан.
Но вот что мы можем определенно порекомендовать:
- Прежде чем выбирать показатели, сформулируйте гипотезы успеха.
Прежде чем формулировать гипотезы, определите ключевые показатели.
- Чтобы выбрать ключевые метрики, ответьте на вопрос: зачем существует ваша команда? Как определить его успех? И идти в том же направлении с глобальными целями компании.
- Убедитесь, что выбранные ключевые метрики понятны, просты, вы уверены в их расчетах, а ваши гипотезы им не противоречат.
- Для каждой гипотезы успеха опишите движущие и ограничивающие показатели, которые должны помочь в ее достижении.
Проверьте наличие причинно-следственной связи между этими метриками и целевыми.
- Не существует правильных или неправильных показателей.
Любой может найти ему применение.
- Даже если вы считаете, что у вас все хорошо и все свои решения вы принимаете на основе проверенных показателей, не прекращайте работать над ними.
Со временем компания, окружающая среда и ваше понимание изменятся, и метрики должны меняться вместе с ними.
Мы уже начали применять описанные выше советы.
Мы надеемся вскоре рассказать, как метрики теперь влияют на стратегию нашей команды, и указать, на правильном ли мы пути.
А пока подписывайтесь на нашу телеграмм канал , где мы рассказываем о развитии и жизни в Кошельке! :) Теги: #продуктовое мышление #метрики #ценность продукта #метрики продукта #метрика северной звезды #Управление продуктом #Аналитика мобильных приложений #Управление продуктом #ИТ-компании #ИТ-компании
-
Черная Пятница 2015
19 Oct, 24 -
Столица Электромобилестроения России.
19 Oct, 24 -
Стажировка В Google 2 (Часть 1)
19 Oct, 24 -
Рисование Графиков Онлайн
19 Oct, 24
