Привет! Меня зовут Даня, и я дата-аналитик в Кошельке. Я хочу рассказать, как мы выбирали и рассчитывали центральную метрику «про деньги» для команды Каталога в приложении «Кошелёк». Еще я расскажу, почему эта метрика (спойлер — это RPS) оказалась не совсем тем, что мы искали.

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

Нам нужна была центральная метрика, которая показывает эффективность всевозможных размещений. Выбор пал на Revenue Per Show (RPS) — доход с одного показа предложения.

RPS = Выручка / Количество показов

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

Почему изначально выбрали RPS

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

• Метрика должна показывать эффективность работы бизнес-юнита.

• У бизнес-юнита должны быть рычаги влияния на метрику.

• Метрика должна мотивировать направление на правильные действия, которые не навредят другим юнитам и пользователям.

• Одна метрика — один ответственный.

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

Каталогу, как площадке пассивных коммуникаций, была необходима метрика, определяющая, насколько эффективно мы даём ресурсы (показы) другим продуктовым командам Кошелька.

Как используется RPS

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

Зачем RPS в Кошельке?

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

В зоне ответственности нашей продуктовой команды лежали различные площадки:

• Сам Каталог как отдельная вкладка Кошелька. 

• Место под картами лояльности.

• Часть пространства на главной странице приложения.

• Web-ресурс.

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

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

Предполагалось, что мы можем это делать с помощью:

• Составления таргетированных подборок с высоким RPS для определённых сегментов пользователей.

• Выноса предложений с высоким RPS на главную Каталога и на домашний экран приложения.

• Увеличения конверсий выпуска: изменения текстов, картинок, проработка сценариев выпуска.

• Реализации более эффективных визуальных компонентов.

Какие сложности возникли 

Трудно посчитать

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

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

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

Поэтому на помощь пришли танцы с бубном и щепотка шаманства:

• Написание PowerShell-скрипта, который выполняет импорт из директории с синхронизированными  «облачными» Excel-файлами и проводит их конвертацию в *.csv в виде пар ключ-значение. 

• Вставка и выполнение ряда преобразований на стороне MSSQL с помощью хранимой процедуры.

• Обработка полученной таблицы в Python.

Трудно повлиять на метрику

Ладно, метрику посчитали. Теперь мы видели её целевое значение, и добавили разрез платформ (iOS/Android), разных экранов — сценариев, выручку от разных типов продуктов и само количество показов. Мы даже подняли старые эксельки архивы для расчёта метрики за последние 1.5 года.

Видим цель — идём к цели! Пришло время строить планы по её росту. В начале мы говорили, что RPS состоит из двух частей — выручки в числителе и количества показов в знаменателе. Поэтому для повышения метрики в реалиях Кошелька можно было пойти тремя путями:

1. Стимулировать пользователей выпускать больше продуктов. 

ДА, НО на это влияет то, каких партнёров нам подключает команда Лояльности, какой трафик приводит команда Маркетинга, как предложения «укладывает» внутри Каталога команда CVM и т.д. Получается, если мы в своей команде поставим это целью, то будем зависеть от остальных подразделений.

2. Увеличивать тарифы для партнёров. 

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

3. Оптимизировать размещение предложений внутри Каталога. Это как раз то, ради чего мы и хотели использовать RPS. 

ДА, НО тут появилась другая проблема — за качество контента внутри Каталога и его размещение тоже отвечает другая команда. Получается, что и тут мы на метрику влияем лишь очень косвенно.

Трудно интерпретировать и принимать решения

Из предыдущего пункта следует то, что мы оказались бессильны ответить на вопрос: какие выводы нам делать с помощью RPS?

Мы сумели корректно посчитать метрику, мы знали, что на неё влияет, видели как она то падает, то растет, ничего не понимали и не могли сделать вменяемые выводы. Короче говоря, принимать решения нашей команде она не помогала.

Почему RPS не оптимальна

Потому что в результате наших усилий мы получили метрику, которую:

1. Сложно точно подсчитать, потому что не все действия пользователей однозначно можно привязать к «деньгам».

2. Можно назвать ненадёжной, потому что она не вызывает у нас доверия из-за пункта 1.

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

4. Тяжело регулировать силами нашей команды.

5. Невозможно  использовать для принятия каких-либо решений из-за пункта 4.

6. Необходимо было «наращивать мясом» из других метрик — разделять каждую часть выручки по командам и углубляться дальше.

7. Трудно интерпретировать: партнёр А приносит нам 1 000 у.е, мы его показали 10 000 раз, RPS = 0.1. Партнёр Б приносит нам 10 000 у.е, но мы его показали 200 000 раз, RPS = 0.05. Несмотря на то, что RPS у Б в два раза меньше, он нам принёс в 10 раз больше денег. 

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

Дальнейшая судьба RPS

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

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

Надо строить пирамиду

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

Решение: пытаемся выделить Каталог как техническую платформу, которая не отвечает за качество контента и, самое главное, за выручку.

Нова задача: построить пирамиду метрик команды, которая будет показывать, как работает платформа Каталог и все движения внутри неё.

Критерии, на которые мы опирались при её разработке:

• Пирамида должна отражать все главные метрики Каталога, на которые мы можем повлиять.

• Глубина метрик должна быть достаточна, чтобы понять, что на метрики повлияли именно мы.

• Цели Каталога сформулированы и описаны, и мы их придерживаемся. 

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

Конечно, потребовалось его немного адаптировать и видоизменить две категории:

• Вместо Happiness пользователей у нас было «счастье» наших внутренних заказчиков, которым мы разрабатываем инструмент для заполнения Каталога. 

• В категории Task Success, ориентированной на эффективность решения задач пользователя, были технические метрики доступности и быстродействия платформы (скорость загрузки Каталога, количество ошибок при выпуске карт и т.д.).

Кроме того, для каждой категории мы описали:

• цель — что хотим получить.

• сигнал — что в поведении пользователей укажет на успех или неудачу.

• метрики — количественное выражение сигнала во времени. 

• задачи — что нам необходимо понять с помощью категории

Всё делали по строгой букве продуктового закона.

Затем мы визуализировали метрики в Miro. Это была бесконечная круговерть листочков, связей, интерпретаций и возможных сценариев, но мы справились.

Мы не торопились и опирались как на опыт других продуктовых команд в Кошельке, так и на экспертизу извне. Но достаточно быстро дашборд со всеми метриками уже крутился в Power BI.

«Они пытались» или почему пирамида метрик тоже не помогла

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

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

Так почему пирамида метрик всё еще не была оптимальным решением?

• У нас не было целевых метрик (goal metric) — показателей к чему глобально движется вся команда. Мы не сформулировали цель Каталога изначально и поэтому не знали, в каком направлении идем.

• Вся наша пирамида метрик состояла из показателей движущей силы (driver metric) и ограничительных показателей (guardian metric). Первый вид метрик отражает гипотезы о факторах успеха, а второй защищает от ошибочных гипотез.

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

• Нам было сложно связать наши показатели с ключевыми метриками и целями всей компании. Мудрость басни «Лебедь, Рак и Щука» сработала и здесь.

Учимся на своих ошибках

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

1. Определить цель команды простыми словами. Чётко её сформулировать и согласовать, чтобы она была связана с развитием компании в целом.

2. Выделить несколько ключевых метрик (мы пришли к выводу, что выделить одну north star метрику у нас не получается, да и в этом нет необходимости).

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

4. Сформулировать гипотезы по достижению цели. К каждой гипотезе привяжем метрики (это и будет наша пирамида метрик). Чтобы понять, что выбранные показатели движущей силы влияют на целевые показатели, будем проводить custdev-ы (о чем ниже) и опросы; анализировать исторические данные; проводить точечные А/В-тесты, направленные на оценку причинно-следственной связи между показателями.

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

6. Работать над пирамидой метрик непрерывно. Так как  по мере развития компании, сферы бизнеса в целом и нашего понимания, показатели могут и скорее всего будут меняться.

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

8. Раз в несколько месяцев встречаться с другими командами и делиться мнениями и подходами к пирамиде метрик.

Как определить цели и гипотезы для построения рабочей системы показателей

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

Для этого необходимо было понять, какую потребность пользователей позволяют решать возможности Каталога, какое поведение у них сейчас и как мы этим поведением можем управлять. Поэтому мы провели серию интервью, опросов и UX-исследований (все это в простонародье называется емким словом custdev).

Custdev был ориентирован именно на нашу команду и наши потребности: мы стремились залезть в головы нашим пользователями понять, как пользователи видят Каталог и почему им пользуются. У нас были свои гипотезы на этот счёт, основанные на ощущениях внутри команды Каталога.

Что мы сделали:

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

2. Создали шаблон для каждого интервью, чтобы и мы не забыли задать ключевые вопросы, и собеседник не увёл мысли куда-то далеко.

Что получилось:

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

• Собрать информацию о том, как пользователь пользуется Каталогом и для чего.

• Проверить наши гипотезы — мы действительно часто думали одно, а пользователи говорили нам совсем другое.

• Сгенерировать множество идей и абсолютно новые гипотезы по развитию Каталога.

• Выбрать направление движения — идей-то на самом деле было всегда много, но благодаря более глубокому изучению потребностей пользователя, вектор развития стал намного ярче, а часть идей отсеялась сама собой.

• Запустить еще три опроса и начать новое исследование по изменению UX-дизайна всего Каталога.

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

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

Более того, мы теперь понимаем как можем развиваться в дальнейшем:

• Горизонтально — усиливать ценность, решая новые задачи в сценарии экономии пользователя (если грубо, то разрабатываем другие сценарии экономии, где речь не только о деньгах, но и об экономии времени).

• Вертикально — усиливать ценность, благодаря более эффективному решению текущей задачи (делать удобней интерфейс, увеличить разнообразие предложений и т.д.).

Мораль всей истории

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

• Формулируйте свои гипотезы успеха до выбор метрик. А до формулировки гипотез определите ключевые метрики.

• Чтобы выбрать ключевые метрики, ответьте на вопрос: для чего существует ваша команда? Как определить её успех? И идите в одном направлении с глобальными целями компании.

• Убедитесь, что выбранные ключевые метрики однозначны, просты, вы уверены в их расчетах, а ваши гипотезы не идут вразрез с ними.

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

• Нет правильных или неправильных метрик. Любой можно найти свое применение.

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

Мы уже начали применять у себя советы, описанные выше. Надеемся, что скоро расскажем, как теперь метрики влияют на нашу командную стратегию и указывают, верным ли мы путем идём. А пока подписывайтесь на наш телеграм-канал, где мы рассказываем о разработке и жизни в Кошельке! :)