Крутой продакт и учёный: что у них общего?
Команда Азата Шакурова за последние несколько лет провела больше всех А/B-тестов в Сбере, и это позволило не просто глубоко погрузиться в тему, но и убедиться, что А/B-тестирование — это мощный инструмент. Он позволяет точно измерить влияние продуктовых изменений и избежать иллюзий, сосредоточившись на том, что действительно работает в развитии продукта. Азат уверен, что внедрение этого метода требует времени и усилий, но результаты точно того стоят.
Моя команда работает над несколькими продуктами: подписка на «Уведомления об операциях» и «Близкие рядом». Подписка на уведомления об операциях подключена у большинства пользователей карт Сбера, если у вас есть карта, скорее всего и вы получаете эти пуши или смс. Другой продукт, которым мы занимаемся, — это «Близкие рядом». Представьте, что ваша пожилая мама живёт в другом городе, и вы хотите знать, достаточно ли у неё денег на жизнь и нет ли у неё подозрительных операций. Вы можете подключить опцию «Совместные уведомления» и получать уведомления обо всех движениях денежных средств вашей матери. Также в рамках услуги доступна бесплатная опция «Проверка операций», позволяющая подтверждать или отклонять операции близкого человека, которые банк посчитает подозрительными.
А/B-тестирование: почему это важно?
Когда дело касается лекарств, мы с вами хотим иметь определённую степень уверенности, что оно безопасно и поможет справиться с конкретной ситуацией, поэтому важно понимать его влияние. Дело касается жизни человека. Именно поэтому в медицине давно закрепился стандарт для проверки новых фармакологических средств — рандомизированные клинические исследования. При выводе на рынок нового лекарства специалисты проводят испытания, включающие в себя следующие элементы:
• наличие контрольной группы, получающей плацебо;
• наличие экспериментальной группы, получающей реальное лекарство;
• распределение участников по группам методом рандомизации;
• соблюдение статистической значимости.
Подобные рандомизированные исследования ещё в середине XX века стали стандартом доказательной медицины. Потому что исследования подтверждают, приносит ли лекарство реальную пользу, какие могут возникать побочные эффекты и как их измерить? В данном подходе применятся научный метод и статистический аппарат, важным элементом которого является – рандомизация.
Почему с цифровыми продуктами должно быть иначе?
Мы тоже хотим создавать пользу: делать нашим пользователям удобно и полезно, а не наоборот, при этом зарабатывать деньги, уменьшать издержки, захватывать долю рынка.
Стремление к созданию пользы
Для бизнеса: Увеличение прибыли (обычно через увеличение: конверсии в покупку, притока пользователей, % удержания клиента, частоты использования продукта, дохода на пользователя), уменьшение издержек, занятие доли рынка для дальнейшей монетизации.
Для клиента: Решение задач клиента, которые никто не решал, создание более эффективного решения задачи по сравнению с альтернативами (быстрее, проще, требует меньше усилий, финансово эффективнее), решение соседних задач клиента, создание более эмоционально привлекательного решения (статус, принадлежность к группе, дофаминовые циклы)
Если так, то какие у нас есть инструменты проверки продукта реальным миром? Глобально их все можно разделить на две группы: сравнение с прошлым и сравнение в настоящем.
Сравнение с прошлым — это когда мы включаем новую версию функционала и смотрим, как изменились метрики после данного включения. Но проблема в том, что поведение пользователей меняется каждый день, неделю, месяц. На это влияют маркетинговые кампании, конкуренты, рыночная конъюнктура, технические изменения и ещё множество факторов, которые мы часто не можем контролировать. Даже если мы ничего не делаем, метрики продукта будут меняться, а значит, мы не можем быть уверены, повлиял ли наш функционал на изменение метрик или это совпадение.
При сравнении в настоящем можем выделить два метода (хотя есть и другие): это А/B-тестирование и то, что мы в Сбере называем «сравнение между блоками», т.е. единицами раскатки = группами пользователей, на которых постепенно включаем функционал. В методе «сравнение между блоками» есть проблема: блоки могут быть демографически разными, а точнее, они всегда такие. Разные по составу группы пользователей означают, что у них уже разное поведение относительно друг друга, а также разное влияние внешних факторов. Это значит, что мы снова не можем быть уверенными, чем вызвано изменение метрик: внедрением нашего функционала, влиянием внешних факторов, составом групп или всем вместе. И снова каждый день поведение пользователей в группах будет меняться относительно друг друга, мы будем видеть разные значения метрик, даже ничего не делая. Получается, проводя тестирование влияния нового функционала подобным методом, мы сами не всегда понимаем, что мы даём нашему клиенту: плацебо, лекарство или яд.
Именно поэтому на рынке закрепился стандарт вывода новой функциональности. А/B-тесты как раз форма того самого рандомизированного контролируемого эксперимента, который проводится при создании новых лекарств.
Благодаря рандомизации, мы создаём группы, идентичные по характеристикам, и единственное, что их отличает, — это версия продукта, которую они видят. Это позволяет нам точно понять, как наши изменения влияют на поведение пользователей.
Более того, А/B-тестирование — это проверяемый инструмент. Мы можем провести A/A-тест, где обе группы видят одинаковую версию функционала, и убедиться, что нет статистически значимой разницы в поведении обеих групп, а значит, что разделение на группы происходит корректно и все внешние и внутренние факторы оказывают идентичное влияние на обе группы.
Так, А/B-тестирование сейчас показывает себя как самый надежный инструмент проверки влияния, показывающий реальные продуктовые изменение, а не мнения и зашумлённые данные.
Что даёт внедрение А/B-тестирования?
1. Ускоряет рост продукта
Но сначала делает больно. Потому что наглядно демонстрирует, что большая часть идей не работает.
Исследования показывают, что 88% новых идей не дают эффекта*. А/B-тестирование позволяет это увидеть и не тратить ресурсы на неэффективные изменения. Это нормально, и важно понимать, что не все гипотезы оказываются успешными. А/B-тестирование помогает отсеивать те, которые не работают, и постоянно наращивать сильную аналитическую и discovery-культуру в компании, анализируя, что на самом деле работает.
2. Мелкие изменения могут дать большой эффект
Кажется, что небольшие изменения в продукте не могут существенно повлиять на метрики, но это не так. Классический пример — эксперимент Google под названием «50 оттенков синего». Компания тестировала разные оттенки синего в своих рекламных объявлениях и смогла увеличить конверсию на, казалось бы, смешные 0,1%. На масштабах Google это принесло дополнительно $200 млн годовой прибыли. Даже небольшие изменения могут иметь огромный эффект, особенно в крупных компаниях.
3. Позволяет увидеть неожиданные побочные эффекты
Иногда даже незначительные изменения могут негативно повлиять на другие метрики. Безобидные правки иногда создают небольшие «пробоины», в которые сливаются конверсии, но заметить этого другими методами не получится.
4. Позволяет точнее отслеживать влияние на деньги
Порой бывает сложно понять, почему продукт не растёт, несмотря на все усилия. В таких случаях помогает метод холдаут групп. Мы выделяем небольшую группу пользователей (например, 1% от общей аудитории), которые не получают никаких новых продуктовых изменений в течение длительного периода. И например, через год мы сравниваем их поведение с теми, кто получал обновления. Это позволяет точно определить, действительно ли изменения принесли пользу или рост метрик связан с другими факторами.
Как проходит А/B-тестирование
Как внедрять А/B-тестирование: Полезные советы, проверенные на себе
1. Выбирайте гипотезы, ориентируясь на количество пользователей
Если у вас меньше 200 000 пользователей, не стоит проверять гипотезы с эффектом 1% и меньше. Вместо этого сосредоточьтесь на более значимых изменениях, которые могут существенно повлиять на метрики. Если у вас есть 10 000 пользователей, то ищите гипотезы, где ожидаемый эффект не менее 5%.
2. Делайте MVP
Прежде чем вкладывать ресурсы в полноценную разработку большой фичи, создавайте MVP и проверяйте её эффективность через эксперименты. Это позволит вам сэкономить время и деньги, если гипотеза окажется неверной. Каждый сценарий большой фичи может быть отдельным А/B-тестом.
3. Комбинируйте А/B-тестирование с другими методами проверки гипотез
А/B-тестирование не отвечает на вопрос, почему пользователи ведут себя так или иначе. Используйте качественные и количественные исследования, чтобы обогатить гипотезы. Например, включённое наблюдение (когда вы наблюдаете за пользователями в реальных условиях) может помочь понять их мотивацию и контекст. Есть довольно известная история с голосовым помощником и картами в такси. Оказалось, что на рынке одной страны водители не пользовались им, потому что не хотели, чтобы женщина говорила им, куда ехать. Такие нюансы невозможно выявить с помощью А/B-тестирования, но они критически важны для понимания пользователей и проектирования продукта.
4. Не попадайте в ловушку локального оптимума
Механический перебор улучшений может быстро исчерпать себя. Иногда нужно полностью пересмотреть подход к продукту. Например, если вы постоянно улучшаете интерфейс и ключевые офферы, но метрики не растут, возможно, проблема не в интерфейсе, а в самой концепции продукта.
И держите в голове, что 88% гипотез проваливаются. Часто в самом начале активного внедрения А/B-тестов команды показывают процент успешных тестов намного выше, а происходит это, просто потому что команды обнаруживают много низко висящих фруктов, про которые они почему-то не думали. Такие фрукты удобно и приятно собирать. Первые полгода-год может сложится ситуация, что вы возомните себя гуру экспериментов, но чем дальше, тем сложнее.
Пример из практики: как мы боролись с оттоком пользователей
Один из наших ключевых продуктов — та самая подписка на «Уведомления об операциях» — столкнулся с проблемой оттока пользователей. В определённый момент мобильное приложение Сбербанк Онлайн стало каналом оттока от услуги: отключений услуги в приложении было больше, чем подключений. Как так вышло? Исторически услуга подключалась в отделениях банка при получении карт. А потом в приложении пользователи могли ее отключить и делали это. Поэтому получилось, что приложение стало ключевым каналом, через который услугу отключали. А задача была в том, чтобы цифровые каналы не только не теряли пользователей, но и приводили новых.
Первая исходная задача, которая перед нами встала, это более глубокое понимание причин оттока. Для этого мы использовали качественные исследования: глубинные интервью, этнографию, телефонные обзвоны и анализ уже имеющихся данных. Мы смотрели метрики, слушали звонки в контактный центр, читали отзывы при отключении услуги, делали анализ сессий клиентов в ключевых местах нашего приложения. В результате мы получили ряд инсайтов и гипотез для последующей проверки и валидации, на основе которых можно было бы понять, через какие продуктовые изменения мы можем поработать с нашим оттоком.
Мы выбрали самые перспективные, на наш взгляд, гипотезы и часть из них провалидировали через опросы. По результатам этих исследований мы получили более 10 причин, почему клиенты отключают нашу услугу, и пошли работать с ними. Мы начали собирать новые версии сценария отключения и каждую версию проверяли с помощью А/B-тестов, насколько она работает или не работает.
Общий подход был следующим: мы знали причины, по которым клиенты отключали услугу, и мы в сценарии отключения прописывали варианты причин отключения. Вариантов было множество. Когда клиент нажимал на ту или иную причину отключения, открывался специализированный экран с определённой коммуникацией, с помощью которой мы старались его удержать, убедить остаться, донести ценность и пр. По итогу у нас остались рабочие варианты, которые реально удерживали клиента от отключения услуги.
Какие варианты причин отключения оставались на финальных итерациях нашей фичи?
1. «Не хочу платить» — самая массовая причина, на которую в сценарии отключения нажимали чаще всего.
И в эту категорию попадало два пласта клиентов. Первый — это те, кто не видят достаточной ценности услуги для себя, чтобы платить текущую цену. В целом они были бы готовы пользоваться этой услугой, но если бы она стоила дешевле или была бесплатной. Без изменения стоимости этих клиентов никак не переубедить. Второй пласт клиентов — те, которые в моменте не осознавали до конца ценность услуги и не видели всех сценариев, в которых могут получить пользу. У нас была возможность понятнее донести до них ценность и пользу, которую они получают, и мы как раз пользовались этим. Часть из этих клиентов получалось убедить оставить подписку на услугу — мы стали удерживать 15% пользователей от всех нажавших на причину.
2. Следующая причина отключения, которую мы взяли в работу: услуга не нужна даже бесплатно.
Это пользователи, которые попробовали услугу и поняли, что уведомления их в целом раздражают и воспринимаются ими скорее как спам, чем нечто полезное. Они предпочитают сами смотреть что-то в приложении по запросу. Удерживать такую категорию клиентов в основном не получалось. То есть те, кто шли по этой ветке, в большинстве своём всегда отключали подписку.
3. Следующая причина для отключений — редкое использование конкретно этой карты, по которой наша услуга предоставлялась.
И тут были варианты: либо клиент начал чаще пользоваться картой другого банка, соответственно ему неактуально платить за уведомления по текущей карте, либо у него была другая карта Сбера, которой он чаще стал пользоваться. Тех, кто стал реже пользоваться картой Сбера, тоже оставить на услуге почти не получилось. У них нет потребности в уведомлениях по карте, которой они почти не пользуются, поэтому тут менее 1% удержания от нажавших на причину. А для клиентов, которые редко пользовались конкретно этой картой Сбера, мы сделали полезные и выгодные для клиента условия. Распространили нашу услугу на все карты пользователя, и цена от этого не увеличивалась.
4. «Получаю много рекламы» — это ещё одна причина отписок.
Часть клиентов раздражаются даже от одного или двух рекламных уведомлений, поэтому они отключают и услугу уведомления об операциях, и все связанные с ней вещи, как спам. Здесь появляется развилка, которую мы можем предложить пользователям: вместо отключения уведомления об операции отключить только рекламные уведомления. А точнее, сконфигурировать, в каких каналах пользователь хочет или не хочет получать те или иные сообщения. Итог, удерживаем 40% от нажавших «получаю много рекламы».
5. Ещё одна причина — технические сложности, из-за которых услуга могла работать не всегда корректно, это тоже приводило к отключению клиентом уведомлений.
Здесь мы сделали следующую развилку: если клиент выбирает причину отписки «Проблемы с получением уведомлений», то в приложении автоматически запускается сценарий, который проверяет все настройки и внутри приложения, и на уровне операционной системы, которые могли бы привести к тому, что уведомления не приходят своевременно. По результатам этой проверки можно устранить причину, по которой что-то работает не так, как надо. Это внедрение помогло поработать с причиной оттока: удерживаем 60% от нажавших на этот пункт.
6. И вот наша причина-финалист — «слежу за балансом и проверяю историю операций только в приложении». С этой когортой клиентов у нас получилось поработать и донести дополнительную ценность именно уведомлений.
После проработки ключевых гипотез мы постоянно вводили и выводили новые пункты и варианты коммуникации из сценария отключения для удержания клиента. Это стало таким органическим, динамичным процессом, но в целом это помогло существенно сократить количество отключений через мобильное приложение.
Более того, мы не только работали с отключением, мы пересобрали то, как идут подключения услуги внутри мобильного приложения, сделали разные сегментные офферы в зависимости от того, какой клиент перед нами. Так, сценарии для разных типов клиентов в разных местах стали работать немного по-новому, это тоже помогло нам увеличить конверсию в подключение услуги уже внутри приложения.
А/B-тесты много раз доказывали нашей команде свою эффективность, но главное, что мы поняли, что это лишь инструмент проверки влияния, сами по себе они не обеспечивают качество гипотезы. Это наша задача — создавать сильные гипотезы качественными и количественными методами. И эти сильные гипотезы уже проверяем через А/B-тестирования.
Больше кейсов и инструментов, проверенных продактами в разных компаниях, будут на Конференции Sbergile: «продакты для продактов». В прошлом году она прошла только «для своих», а 29 мая 2025 впервые станет открытой. Здесь можно следить за всеми новостями конференции, совсем скоро появится программа и возможность зарегистрироваться для очного или онлайн-участия. Давайте делиться опытом и вместе делать нашу индустрию ещё круче!