Прокси метрика что это
Прокси-метрики в E-commerce. Часть 2
В этой статье, состоящей из трёх частей, мы рассказываем о нашем исследовании метрик, на которые стоит ориентироваться, чтобы увеличить долгосрочную выручку онлайн-магазина.
В первой части обсудили проблемы, возникающие при оценке LTV пользователей онлайн-магазина, и как можно решить их с помощью прокси-метрик. Также мы рассказали, как ищут подобные метрики компании из разных областей и поделились собственным списком найденных метрик, применимых в e-commerce.
Вторая часть (то есть та, которую вы сейчас читаете) более техническая: в ней мы детально объясняем, как можно найти и выбрать полезные прокси-метрики из множества вариантов, насколько хорошо они предсказывают LTV покупателей, смогут ли магазины с разными категориями товаров их использовать и т.д.
Третья, финальная часть, более прикладная: в ней мы обсудим, как бизнесу работать с полученными метриками, чтобы повышать LTV пользователей, а вместе с ним и долгосрочную выручку онлайн-магазина.
Но вернемся к технологии поиска прокси-метрик. Для своего исследования мы использовали методы машинного обучения и извлекали из данных статистические закономерности. Поэтому будет логично сперва рассказать об используемых данных, на основе которых мы делали выводы.
Источники данных
У Retail Rocket более 1000 клиентов по всему миру: Россия, Европа, Латинская Америка, СНГ – часть которых работает с компанией много лет. Из них для исследования мы отобрали 27 интернет-магазинов, специализирующихся на различных категориях товаров.
Такое разнообразие магазинов понадобилось, чтобы проверить, насколько найденные прокси-метрики будут универсальны.
Описание данных
У каждого посетителя интернет-магазина есть идентификатор, хранящийся в cookie. По нему можно отследить, какие связанные с пользователем события происходили, когда и каким образом.
К таким событиям относятся:
Добавление товара в корзину;
Просмотр страницы сайта;
Использование поисковой системы сайта;
Пользователь оставил свою электронную почту.
По нашим данным, примерно 10% всех cookie «живут» более 120 дней – этого достаточно, чтобы выявить связи между признаками и LTV. Однако есть проблема: часть пользователей сбрасывает cookie и возвращается в магазин с новым идентификатором. Из-за этого сложнее определить, как те или иные признаки влияют на LTV. Возможно, при более точной идентификации пользователя обнаруженные нами связи окажутся сильнее.
Логика формирования признаков и целевой переменной
Чтобы было проще разобраться, введем следующие термины:
Дата среза – это дата, разделяющая два периода: период сбора признаков (4 месяца до даты среза) и период сбора информации о будущем LTV (6 месяцев после даты среза).
Например, если дата среза – 1 июля 2020 года, то признаки собираются с 1 марта 2020 по 1 июля 2020 года включительно, а информация о будущем LTV – со 2 июля 2020 года по 1 января 2021 включительно.
Целевая переменная в нашем исследовании (информация, которую мы хотим предсказать) – факт покупки в период сбора информации о будущем LTV. Мы рассматривали только посетителей из периода сбора признаков и, если не находили никаких связанных с ними событий в период сбора информации о будущем LTV, считали, что такой пользователь ничего не покупал.
Чтобы проверить, насколько найденные нами зависимости стабильны во времени, у каждого из 27 магазинов мы взяли по 6 срезов (первое число каждого месяца с июля по декабрь 2020 года).
Для отбора кандидатов в прокси-метрики мы составили обширный список. Он включал в себя признаки, связанные с:
Заказами: количество, давность последней покупки, средний чек, выручка и т.д;
Добавлением товаров в корзину: за всё время, за последнюю неделю;
Знакомством с каталогом магазина: кол-во просмотров товаров, категорий, кол-во просмотров за последнюю неделю;
Использованием поисковой системы сайта: кол-во запросов в поисковой системе сайта за всё время, за последнюю неделю;
Временем, проведенном на сайте: разница в днях между первым и последним посещением сайта, давность последнего посещения сайта, активность на сайте в рабочие и нерабочие часы, в конкретные дни недели;
Фактом подписки: оставил email или нет, как давно стал подписчиком;
Устройством, с которого посещал сайт: компьютер или смартфон, точная версия браузера, IP пользователя;
Разным отношением признаков и агрегатов: например, доля просмотров товаров за последнюю неделю к просмотрам за всё время, суммарное количество просмотра категорий, товаров и поиска, доля поиска во всех действиях пользователя на сайте и т.д.
Мы провели исследование для всех 27 магазинов, но для простоты покажем в качестве примера результаты двух наиболее крупных и отличающихся друг от друга. У «Магазина 1» больше всего посетителей, совершающих заказы, и короткий период потребления, а у «Магазина 2» наоборот – меньше всего посетителей, совершающих заказы, и длинный период потребления.
Отбор признаков по степени влияния на целевую переменную
Целевая переменная бинарная – пользователь либо совершит покупку, либо нет – поэтому силу отдельных признаков и модели целиком мы измеряли с помощью метрики ROC AUC.
Для начала посмотрели, насколько значим каждый признак с помощью алгоритма бустинга над решающими деревьями. Затем оставили признаки с высоким значением ROC AUC. Таким образом мы отсеяли слабые признаки и обнаружили среди оставшихся много хороших кандидатов в прокси-метрики с высокими показателями ROC AUC.
На графиках ниже – примеры сильных признаков.
По графикам видно, что даже в совершенно разных магазинах признаки работают одинаково. Также отметим, что признаки «количество просмотренных товарных позиций» и «давность последнего посещения сайта» никак не связаны с заказами и при этом работают ничуть не хуже.
Отбор признаков по коррелированности
Среди признаков было много пар с высокой корреляцией. Включать их вместе в итоговый список прокси-метрик LTV бессмысленно, так как меняются они одинаково, а отслеживать большое количество признаков затруднительно. Также, если обучать модель на коррелированном наборе признаков, то могут возникнуть проблемы со стабильностью параметров и дальнейшим использованием модели.
Например, есть три сильных признака:
Количество просмотров товара;
Количество разных просмотренных товаров;
Количество разных просмотренных категорий.
Корреляция между ними больше 80%: все говорят о том, что пользователь ознакомился с каталогом магазина и заинтересован в его товарах. Следовательно, любой из этих признаков можно взять в качестве прокси-метрики. Скорее всего, для магазинов с большим числом категорий полезнее будет «количество разных просмотренных категорий», а для магазинов с несколькими категориями, но большим количеством разных товаров – «количество разных просмотренных товаров».
Мы оставили признак «количество разных просмотренных товаров», так как он отвечает за ознакомленность с каталогом и связан с эффективным размером каталога. Также мы отталкивались от обзорной статьи, в которой он оценивается как имеющий бизнес-ценность.
В свою очередь метрика «количество просмотров товара» не всегда устойчива к выбросам в данных. Например, если посетитель аномально много раз посмотрел один товар, то для бизнеса это не имеет большой ценности.
Аналогично мы поступали и с другими парами коррелирующих признаков. В итоге оставили несколько признаков о заказах (они коррелированы, но часто используются нашими клиентами как прокси-метрики LTV) и самые сильные признаки, не связанные с заказами:
Давность последнего заказа в днях;
Посетитель оставил email;
Давность последнего посещения сайта;
Количество разных просмотренных товаров;
Длительность взаимодействия пользователя с сайтом в днях (разница в днях между первым и последним посещением);
Количество запросов в поисковой системе сайта;
Количество добавленных в корзину товаров.
Как мы видим на графиках выше, между собой коррелируют только связанные с заказами признаки и еще несколько пар:
Тип браузера и тип устройства имеют относительно слабую корреляцию, поэтому оба этих признака могут быть полезны магазину. Однако для каких-то магазинов их, возможно, лучше объединить в один;
Количество добавленных в корзину товаров и количество заказов также имеют корреляцию, так как перед заказом товара его обычно добавляют в корзину. Степень коррелированности этих признаков зависит от особенностей магазина, например, от доли брошенных корзин. На графиках мы видим, что для «Магазина 1» корреляция невысокая;
Факт подписки и связанные с заказами признаки могут коррелировать между собой, потому что в некоторых магазинах пользователи автоматически становятся подписчиками после совершения покупки.
Проверка стабильности работы признаков по времени
Признаки одинаково влияют на оценку будущего LTV, независимо от даты среза. Например, если у пользователей с 10 просмотрами разных товаров в среднем будущий LTV выше, чем у пользователей с 2 просмотрами, то это справедливо для каждого месяца.
Чтобы проверить это утверждение, мы построили графики, на которых разбили посетителей на группы по интервалам значения признаков и для каждой отобразили долю посетителей, совершивших заказ в будущем.
По графикам выше видно, что независимо от выбранного среза признаки работают одинаково: например, чем больше разных товаров смотрит посетитель, тем вероятнее совершит покупку в будущем. Соответственно, найденные нами зависимости стабильны по времени.
Вклад отдельных прокси-метрик в качество модели
На основе отобранных признаков мы построили модель с помощью бустинга над решающими деревьями – последовательно добавляли признаки в следующем порядке и измеряли ее качество:
Признаки, связанные с заказами;
Количество добавленных в корзину товаров;
Посетитель оставил email;
Количество запросов в поисковой системе сайта;
Длительность взаимодействия пользователя с сайтом;
Количество просмотренных разных товаров;
Давность последнего посещения сайта;
Такой порядок был необходим, чтобы понять, несут ли признаки, не связанные с заказами, дополнительную полезную информацию для модели по сравнению со связанными с заказами признаками.
Как мы видим выше, связанные с заказами признаки (средний чек, выручка, давность последней покупки) добавляют мало дополнительной информации к признаку «количестве заказов», поэтому среди прокси-метрик можно оставить какой-то один показатель, связанный с заказами. Мы выбрали самый устойчивый к выбросам – «количество заказов». На этом графике также можно заметить, насколько важны все последующие признаки – каждый добавляет информацию об LTV, не содержащуюся в предыдущих признаках.
Такую аналитику мы провели для всех 27 магазинов – и везде отобранные нами признаки, не связанные с заказами, показали сильную связь с LTV и добавили много дополнительной информации к признакам, связанным с заказами.
Часто один признак, например, «количество разных просмотренных товаров» или «давность последнего посещения сайта» имел ROC AUC больше, чем все признаки о заказах вместе взятые. Это связано с тем, что по сравнению со всей массой посетителей интернет-магазинов заказы совершает очень маленькая доля пользователей. Соответственно, данных по ним меньше. В нашей выборке только у одного магазина доля пользователей с заказами составила 10%, у остальных она была 2-5%.
Затем мы поменяли порядок добавления признаков и посмотрели, как меняется модель, если сначала загружать в нее не связанные с заказами признаки, а потом связанные.
По графику видно, что связанные с заказами признаки несут в себе дополнительную полезную информацию, но есть магазины (в данном случае это «Магазин 2»), где дополнительная информация практически отсутствует.
Сделанные в этой главе выводы мы проверили на всех исследуемых магазинах, и они подтвердились.
В следующей части обсудим, как бизнесу работать с полученными метриками, чтобы повышать LTV пользователей, а вместе с ним и долгосрочную выручку онлайн-магазина.
Авторы: Айбатов Серик, Носков Артем, аналитики RetailRocket
Как в Flo повысили долю успешных A/B-тестов на 30% через внедрение нового процесса работы с гипотезами
Эту статью вместе с GoPractice написал Дима Золотухин (Facebook, Telegram) – Head of Analytics в компании Flo. Дима занимается дата-аналитикой 8 лет, с 2017 года – в продуктовых компаниях.
Далее повествование ведется от лица Димы.
В Flo (мобильное приложение № 1 в сфере женского здоровья) мы увеличили долю успешных экспериментов на 30%. Для этого мы много инвестировали в то, чтобы наладить эффективный процесс по работе с гипотезами.
Одна из важных составляющих процесса – отсутствие монополии на формулирование гипотез, что приводит к тому, что вся команда участвует в создании гипотез, их приоритизации и тестировании.
В таком случае процесс работы с гипотезами важно знать и понимать всем членам команды, которые касаются продукта: продуктовым менеджерам, аналитикам, дизайнерам, UX-исследователям и даже разработчикам.
В этой статье мы обсудим, как правильно формулировать и приоритизировать гипотезы для последующего A/B тестирования.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.
Еще больше ценных материалов и инсайтов — в телеграм-каналах GoPractice и GoPractice Insights. Добавляйтесь в чат Ask Kevin!, чтобы участвовать в обсуждениях с другими участниками нашего коммьюнити.
Шаблон построения гипотезы и ее компоненты
Гипотеза — утверждение, которое требует доказательства и потенциально может быть проверено с помощью эксперимента.
То есть у правильно сформулированной гипотезы есть как минимум четыре обязательных компонента.
Давайте разберем стандартную гипотезу по компонентам.
Шаблон гипотезы. Описание изменений
Самый удачный вариант для описания изменений — небольшой мокап, на котором любой участник команды быстро поймет, что конкретно для пользователя будет меняться. Это можно сделать как в специальных инструментах вроде Figma (если меняется UI) или Miro (если изменения касаются логики серверной части), так и нарисовав скетч от руки.
Из нашего опыта люди воспринимают и запоминают визуальную информацию намного лучше, чем текст.
Шаблон гипотезы. Сегмент пользователей
На этом этапе нам нужна только примерная оценка сегмента аудитории. Важно, чтобы это был именно определенный сегмент пользователей, обладающий общими задачами и/или паттернами поведения.
Благодаря сегментации аудитории всем участникам команды проще понимать пользователей продукта. Сегментацию вовсе не обязательно (скорее даже нежелательно) делать при помощи продвинутых ML-методов.
Например, мы в Flo делим пользователей на сегменты в зависимости от цели использования приложения. Цель использования мы уточняем на онбординге. Список сегментов (целей) мы определяли и подтверждали качественными исследованиями исходя из того, какую основную цель могут ставить перед собой пользователи в приложении.
Шаблон гипотезы. Ключевая метрика и иерархия метрик
В Flo мы опираемся на OKR компании при выборе метрик. KR на уровне компании представляют собой микс бизнесовых (монетизационных) и UX-метрик.
В итоге, мы изначально понимаем, какие именно показатели хотим улучшить. Это позволяет ограничить набор гипотез и выбирать только релевантные идеи.
Продуктовая команда не всегда может непосредственно и значимо влиять на верхнеуровневые бизнес-метрики. Кроме того, часто они составные. Пример — LTV пользователя, который в подписочных приложениях состоит из сложной воронки: конверсия в триальную подписку, далее конверсия в платеж и последующие конверсии в продление.
Поэтому мы много инвестируем в единую иерархию метрик в компании, которая поможет:
Такая систематизация сильно упрощает выбор метрики в команде. Двигаясь по иерархии метрик, участники лучше понимают, на что именно они могут повлиять, как это связано с топлайн метрикой.
Построение иерархии актуально не только для больших и сложных продуктов, но и для более простых. Ведь основная цель этого упражнения для команды — понять, кто и на что она может эффективно влиять.
Шаблон гипотезы. Прокси-метрики для оценки экспериментов
Довольно часто в экспериментах требуется оптимизировать долгосрочную метрику, например, долгосрочный retention, но ждать месяцы или даже годы у команды возможности нет. Измерять эффект быстрее, но с некоторыми погрешностями помогут прокси-метрики.
Сходство бинарных метрик можно оценивать с помощью коэффициента Жаккара. На иллюстрации видим, что метрика retained М1 (возврат во второй месяц после установки, отсчет с нуля) на 60% сходна с метрикой retained up to D7 (возврат между вторым и восьмым днем после установки). В первом случае нам надо ждать два месяца для того, чтобы получить оценку эффекта, во втором — восемь дней.
Не всегда очевидно, как работать с трейд-оффом между точностью и скоростью расчета. Принимать решение будет проще, если установить внутренний KPI по точности (сходству).
Шаблон гипотезы. Business vs. UX
В некоторых случаях оптимизация бизнес-метрик может вступать в противоречие с User Experience и общей ценностью продукта для пользователей. Например, если делать более агрессивную монетизацию.
Такие кейсы можно контролировать с помощью health-метрик, которые как раз отвечают за UX. Health-метрика, как правило, разнонаправлена с основной метрикой эксперимента (если это бизнес метрика), и главное — ее не «уронить».
Самый популярный пример health-метрики — Retention, но мы используем и другие метрики на разных уровнях иерархии. Например, часто смотрим “активацию” конкретной фичи приложения, чтобы быть уверенными, что изменения ее не обвалили.
Шаблон гипотезы. Масштаб изменения метрики
Мы пришли к одному из самых сложных вопросов — как определить потенциал изменения метрики.
На этапе приоритизации гипотез, как правило, сложно получить супер-достоверную оценку, поэтому надо стараться получить оценку примерную, которая может также быть подтверждена интуицией (об этом чуть позже).
Мы знаем сегмент аудитории, на которую должны повлиять изменения. Но откуда получить информацию об эффекте?
1. «Холодный расчет»
В некоторых случаях масштаб изменений можно просчитать. Например, перед запуском новой фичи можно опросить своих пользователей, насколько они заинтересованы в запуске новой Feature X. Исходя из этого, можно оценить интервал потенциальных конверсий и планируемый эффект.
2. История экспериментов
Историю экспериментов надо хранить как минимум для этого. Находим похожие эксперименты, которые, например, запускались на другой платформе/языке/стране или похожи по теоретическому масштабу изменений. Берем средний эффект. В крайнем случае можем посмотреть вообще все эксперименты с нужной нам метрикой и взять медиану, 75-й перцентиль или максимум изменения в зависимости от вашей уверенности в гипотезе.
3. Рыночное исследование
Иногда оценить эффект от изменения можно по косвенным признакам из рыночного исследования. Как правило, это касается гипотез с рынка, подсмотренных в каком-то виде у конкурентов или просто у других продуктов. В известных сервисах вроде AppAnnie мы можем посмотреть, какой эффект оказало обновление на верхнеуровневые метрики конкурентов. Желательно, чтобы это работало в обе стороны: берете гипотезу/фичу с рынка — обязательно посмотрите на ее влияние в том продукте, где она реализована.
4. Just Noticeable Difference (JND)
Мы можем предлагать что-то суперпрорывное и вообще ничего не понимать с точки зрения эффекта. Рекомендуем определить Just Noticeable Difference на каждом уровне иерархии метрик — масштаб изменений, который точно будет заметен на необходимом уровне. Тогда в случае запуска эксперимента вы всегда будете понимать, насколько он успешен.
Приоритизация гипотез для тестирования с помощью ICE
Мы научились формулировать гипотезы, но у нас их много, и нам надо понимать, как находить наиболее перспективные.
Мы пользуемся чек-листом из пяти пунктов, которые позволяют упростить выбор и найти хорошие гипотезы.
Итак, гипотеза хорошая, если:
Легко заметить, что некоторые пункты чек-листа могут противоречить друг другу и, по сути, являются утопией.
На помощь нам приходит методика приоритизации ICE, которая поможет выстроить бэклог из гипотез.
Чек-лист легко превращается в элементы ICE:
Мы в Flo используем Data Informed ICE: аналитики информируют команду о прогнозном Impact (влиянии изменения), но каждый принимает решение об оценке для ICE лично. Это позволяет привнести элемент продуктовой интуиции в процесс приоритизации и снижает разброс оценок, который бывает при отсутствии бейзлайна.
Запуск экспериментов (A/B тестов)
Получив бэклог из гипотез, мы идем далее по процессу:
Именно так работают продуктовые команды Flo. Внутри два взаимосвязанных, никогда не заканчивающихся процесса — работа с гипотезами и экспериментирование.
Документирование – важный этап процесса приоритизации и тестирования гипотез
Чтобы работа с гипотезами была действительно системной, надо их сохранять и документировать.
Сейчас приоритизацию мы храним и делаем в Google Sheets. Там же мы храним связь гипотез — сводную таблицу планируемых гипотез, которые влияют на одну Objective. Это не очень удобно. И мы в процессе поиска более удобного инструмента, который позволяет эффективно миксовать OKR, работу с гипотезами и результаты экспериментов.
С похожими проблемами столкнулись ребята из соседней статьи и разработали свой инструмент.
Результаты внедрения процесса работы с гипотезами
Мы работаем по описанному процессу уже несколько кварталов и можем отметить:
Сформулировать продуктовую гипотезу правильно не так уж просто, и приоритизация не дается с первого раза. Но если этот процесс настроить и правильно запустить, то скорость и качество развития вашего продукта значительно улучшатся за счет осознанности и эффективной командной работы.
Если вы хотите глубже разобраться в том, как создаются, развиваются и масштабируются продукты, пройдите обучение в симуляторах GoPractice.
Не знаете с чего начать? Пройдите бесплатный тест для оценки навыков управления продуктом. Вы определите свои сильные стороны и слепые зоны, получите план профессионального развития.
Еще больше ценных материалов и инсайтов — в телеграм-каналах GoPractice и GoPractice Insights. Добавляйтесь в чат Ask Kevin!, чтобы участвовать в обсуждениях с другими участниками нашего коммьюнити.
Эссе и образовательные симуляторы про продакт-менеджмент, продуктовую аналитику, маркетинг и рост