Всем привет. На связи Даша Леонова, product owner и ранее product analyst в международной IT-компании Garage Eight. Недавно я открыла конференцию AHA!25 с докладом об A/B-тестах для опытных аналитиков и продуктовых менеджеров. Делюсь: вышло круто. В статье расскажу о том, как вырастить компетенции аналитика за три этапа, начать проводить эффективные A/B-тесты, и стать партнером для компании, а не рядовым сотрудником.
Водите автомобиль? Подумайте, как вы это делаете. Потому что я начну с аналогии. Когда вы за рулем машины, вы думаете прежде всего о своей безопасности. Но я уверена, вы понимаете, что от вас зависит безопасность людей и транспорта спереди, сзади, сбоку. Ваша зона ответственности значительно больше, чем кажется на первый взгляд. И в аналитике и создании продукта это работает так же.
В этой статье я систематизировала типичные ошибки и решения, которые мы встречали в разных проектах Garage Eight. Если вы аналитик — сможете избежать лишних затрат и поломанных метрик, и, конечно, сэкономить бюджет и нервы команды.
Как Роман провалил два А/B-теста и стал сильнее: путь аналитика от middle к senior за 3 шага
Роман — продуктовый аналитик. Недавно он получил повышение до уровня middle. Он умеет строить аналитические end-to-end решения, запускать полный цикл А/B-тестов и продвинутые тесты, разрабатывать кастомные метрики, понимать дисперсию и Bootstrap. Он уже пишет рекомендации и начинает работать в связке с бизнесом.
Чтобы достичь следующего грейда, Роман пройдет несколько квестов. Первый — «Стратегия и метрики», второй — «Качество и аналитический подход», третий — «Коммуникация».
Представим, что он подключился к новому проекту по разработке приложения для обучения инвестированию «Процентик». Зарегистрировался в нем и начал предлагать гипотезы.
Кейс №1. Как дорогие курсы на Главной странице снизили выручку
Совместно с командой Роман решил улучшить рекомендации на Главной. Он руководствовался тем, что если показывать дорогие курсы выше, пользователи будут их чаще видеть и больше покупать → выше выручка.
Идея, казалось, была полезная. Команда запустила эксперимент. Запись на дорогие курсы действительно выросла. Успех? Увы, нет. Команда допустила четыре ошибки, на которых вы можете поучиться.
Ошибка 1: Нет связи с бизнес-метриками
Бизнес-результата не случилось, потому что команда не соотнесла гипотезу с целями продукта. Она занималась подбором курсов и баннеров и не посчитала, сколько денег должно принести улучшение рекомендаций. Если цель — вырасти на 20 млн в год, то каждый успешный тест должен приносить как минимум 2 млн.
В итоге рекомендации стали «лучше». Но не было гарантии, что интересные дорогие курсы дадут реальных платящих пользователей. И не было определено, сколько должно быть таких пользователей, сколько покупок курсов, и как это повлияет на бизнес.
Ошибка 2: Назначили прокси-метрику без доказательной базы
Для оценки успеха A/B-теста команда назначила метрику «запись на курсы, располагающиеся выше на главной странице». Он составил 12% — на бумаге красиво, но верхнеуровневые показатели никак не изменились: пользователи кликали, записывались, но не оплачивали курс. А значит, больше денег не стало.
Ложных и двусмысленных прокси-метрик много:
Например, время, проведенное в продукте. Пользователь мог просто не разобраться в системе навигации, и из-за этого провел много времени в продукте. Другой пример — количество лайков или просмотров публикаций. Это метрика тщеславия, которую мы можем растить долго и усердно, но на самом деле она не повлияет на продуктовую ценность. В таблице я собрала другие похожие примеры.
Проблема прокси-метрик в том, что не всегда выбранная прокси-метрика показывает ценность изменений в продукте.
Ошибка 3: Проигнорированы прошлые инсайты
За последние три года команда Романа провела пять исследований про AHA-момент. Выяснили: если в первую сессию пользователю показывают общий курс «Инвестиции для начинающих», это повышает вовлеченность в продукт с первого дня использования.
Но Роман решил не учитывать этот инсайд. Вместо этого наверх вывели дорогие курсы для продвинутых инвесторов. Ошибка стоила дорого. Если бы команда посмотрела в прошлое и использовала накопленные знания, то могла бы вложить усилия в направление, у которого есть реальный, уже доказанный потенциал.
Ошибка 4: Использовали противоречивые термины
Когда аналитик презентовал результаты, он сказал: «Видим положительное влияние на поведение опытных пользователей».
— Кто такие «опытные»? — спросил продакт.
— Те, кто возвращаются чаще 3 раз в неделю и просматривали курсы хотя бы дважды.
— А почему мы не называем это «активными»?
Все запутались, так как название сегмента было двусмысленным. В итоге обсуждение ушло в споры о терминологии, а не в разговор про результат. Это довольно типичная ошибка в коммуникации, которую часто допускают новички. А вот сотрудникам грейдом выше стоит следить за формулировками, чтобы не допускать недопонимая.
Как Роман перепрошел уровень: способы исправить ошибки
Чтобы следующий A/B-тест не стал новым провалом, Роман:
1. Привязал тесты к бизнес-целям. Например, если годовая цель — увеличить retention с 25% до 30%, нужно считать, какой вклад в эту цель должен дать конкретный тест. Это зависит от масштабности гипотезы, но в нашем кейсе он должен был быть, скажем, 15%. Следовательно, вклад теста в метрику составит 0,75%. От этого зависит выборка и дизайн эксперимента.
2. Построил дерево метрик и связь с прокси-метриками. Оно строится по разным подходам: top-down, bottom-up, от north-star-метрики или от рычагов управления.
Цель — понять, как именно одна метрика влияет на другую. Для этого нужно углубиться в проработку метрик, выделить те, которыми мы управляем, и самое главное — провалидировать связи между метриками, хотя бы через корреляции.
3. Занялся каталогизацией экспериментов. Команда проигнорировала старые гипотезы, не учла инсайты и наступила на грабли. А ведь многие ошибки можно было не совершать, например, не повторять нерабочие гипотезы, потому что их уже опровергли. Поэтому Роман проработал каталог экспериментов.
Важно, чтобы каталогизация A/B-тестов не сводилась к мертвому набору артефактов, которыми никто не пользуется. Нужно не просто зафиксировать метрики, даты и формулировки гипотез, а создать инструмент, который помогает:
понимать, какая метрика и гипотеза были в центре внимания;
знать, какой результат был получен;
отслеживать, что пошло в прод и почему;
генерировать новые гипотезы на основе прошлых, а не с нуля.
Разработка каталога напрямую влияет на рост аналитика: когда он фиксирует, какие изменения были внедрены и какой эффект они дали, появляется чувство ответственности за весь цикл от идеи до внедрения.
4. Поднял вопрос культуры артефактов. Проблема в том, что в одиночку выстроить систему каталогизации экспериментов трудно. У аналитиков есть выбор:
Начать с малого и на уровне своей команды ввести базу экспериментов, которой действительно будут пользоваться.
Взять на себя роль драйвера изменений и поднять вопрос культуры артефактов в компании.
Второй вариант — это уже менеджерский трек и шаг в сторону следующего уровня зрелости аналитика. Для многих специалистов это понятный путь: от уверенной работы с данными — к менеджерскому треку, где фокус смещается на процессы и людей.
Кейс №2. Как push-уведомления убили retention
Команда Романа заметила, что пользователи не завершают уроки. Чтобы подтолкнуть их к этому, она решила сделать две цепочки из push-уведомлений: в одной 5 уведомлений, в другой — 10.
Команда запустила эксперимент. Через два дня — +4% к завершению уроков. Успех? Снова нет. Через месяц ретеншн оказался в минусе. Пользователи стали реже возвращаться в приложение. Пуши раздражали, особенно если приходили ночью. Пользователи писали негативные отзывы. Что пошло не так?
Ошибка 1: Объединили несколько гипотез в одну
Роман и команда зафиксировали, что протестировали цепочки из 5 и 10 пушей и получили прирост, но не разложили гипотезу на составные части. А ведь по количеству касаний это не одна гипотеза, а десять. Или хотя бы две.
Ошибка 2: Не проверили долгосрочный эффект
Если бы команда смотрела на кумулятивный эффект и отслеживала долгосрочные метрики, можно было бы увидеть и проблему с отписками, и перегруз от коммуникации.
Ошибка 3: Не решили, что делать при негативных сценариях
Пользователи писали негативные отзывы и говорили прямо, что пять уведомлений — допустимо, десять уведомлений — перебор. Команда это зафиксировала, но все цепочки оставила в проде.
Ошибка 4: Не контролировали дальнейшую судьбу теста
Команда не разработала план того, что делать с гипотезой в перспективе. В итоге вторая цепочка пушей продолжала приходить пользователям спустя 3 месяца. Количество отписок увеличилось. Следовательно, команда не следила за работой теста. Тут встает вопрос не просто о гипотезе, а об ownership и понимании, что вы не просто делаете фичи, вы отвечаете за судьбу всего теста.
Как Роман улучшил подход: способы исправить ошибки
Вдохновившись опытом Garage Eight, Роман изменил алгоритм тестирования.
1. Внедрил глобальную контрольную группу. 80% аудитории участвуют в быстрых A/B-тестах, 20% — остаются в контрольной группе, по которой потом замеряется реальный эффект в рамках квартала или полугода. Только те изменения, которые показали долгосрочную пользу, масштабируются на весь продукт.
Подход помогает решать две задачи: отслеживать накопленный эффект и удерживать фокус на пользователе, а не только на цифрах на коротких дистанциях.
2. Решил держать на контроле дальнейшую судьбу теста. При проектировании тестов нужно заранее продумывать, какие сценарии возможны, и что можно сделать при каждом из них. Роман решил проверять, что ожидаемый эффект совпадает с реальным, и закладывать изменения в план команд. И не забывать выключать экспериментальные фичи, если они не прошли валидацию.
Кейс №3. Как проверенные решения не увидели свет из-за проблем с коммуникацией
Команда Романа разобралась с замером метрик на долгой дистанции. Победила первая цепочка из пяти уведомлений. Команда пошла к топ-менеджменту с красивыми графиками и предложила остановиться на этом варианте. Ответ был — нет.
Менеджмент мотивировал свой отказ так: если 5 пушей помогли, то 10 точно будут работать еще лучше. Цепочка длиннее, значит мы будем чаще напоминать о себе пользователям.
Почему менеджмент отвергает валидированные данные
Есть три причины:
Сами данные. Данным могут не верить, если они плохого качества — есть ошибки, дубли, плохая структура, устаревшая информация. Вторая причина — недостаток доверия к источникам и отсутствие прозрачности. Третья причина — чрезмерный объем и аналитический паралич.
Когнитивные искажения. Появляются, когда здравый смысл кажется убедительнее, чем аналитика. Особенно, если данные сложны для понимания. Возникает дилемма Сигнал vs Шум и бывает слишком сложно принять решение и выделить важное.
Корпоративная культура. В некоторых компаниях решения принимаются по авторитету, а не по цифрам.
Аналитик может влиять на эти причины по-разному: на данные — сильно, на искажения — умеренно, на корпоративную культуру — почти никак. В таких условиях аргументировать гипотезу приходится особенно тщательно.
Чтобы доказать свои данные, аналитику пригодится знание моделей вроде спиральной динамики корпоративной культуры: большинство компаний находится на красном уровне, где решения принимаются на основе власти и иерархии. И только на синем уровне власть переходит к данным.
Как Роман решил проблемы с культурой и коммуникацией
Для перевода топ-менеджмента с красного уровня на синий и валидации инсайтов, аналитики используют несколько подходов и разные методы.
Вот, что сделал Роман:
1. Развивал оунерство за весь тест. Стремился повысить ответственность аналитиков за весь цикл эксперимента — от гипотезы до внедрения и пост-эффекта. Проверял, действительно ли гипотеза совпадала с тем, что команда фиксировала на самом деле в долгосрочной перспективе.
2. Развивал культуру неудачных экспериментов через каталогизацию. Он давал возможность получать необходимые инсайты из неудачных экспериментов, разбирал постмортемы и проверял доступность кейсов, на которых можно учиться.
3. Строил триады на базе общих проектов и ценностей. Триады — прочные связки между аналитиком, продактом и дизайнером или разработчиком. Они помогают уйти от двусторонних договорённостей к устойчивой системе взаимодействия — особенно важно на «красном» уровне, где решения часто держатся на личных связях.
4. Аргументировал свою позицию. Искал доказательства, подбирал убедительные выражения, обрабатывал возражения для разговоров с менеджментом.
Аналитик становится партнером в продукте: что меняется, когда растешь до сеньора
Роман завершил квест из трех этапов. Прошел через анализ стратегий и метрик, научился работать с качеством и договариваться с руководством. Он прокачался. Но дело не только в новой должности, Роман изменил подход к работе. Раньше он просто запускал качественные эксперименты. Теперь — запускает эксперименты, которые меняют продукт. Он поднялся на новый уровень не по грейду, а по смыслу.
На уровне Middle аналитик:
проводил эксперименты и писал по ним выводы;
опирался в первую очередь на мнение заказчика, а не данные;
знал ключевые продуктовые метрики;
сосредотачивался на процессе запуска и проведении теста, без оценки влияния на бизнес-метрики;
хранил эксперименты «в голове»;
не отслеживал внедрение и пост-эффект теста после релиза.
На уровне Senior аналитик:
формулирует рекомендации, которые улучшают продукт;
аргументирует свою позицию, а не соглашается с заказчиком;
связывает метрики в единую картину, строит дерево или пирамиду метрик;
участвует в процессе до, во время и после теста;
оценивает бизнес-эффект заранее и привязывает результат к деньгам;
документирует эксперименты, чтобы не наступать на старые грабли;
использует четкие формулировки, чтобы сэкономить время;
контролирует внедрение победившего варианта;
формирует устойчивые продуктовые триады, где решения опираются на данные, а не чье-то мнение.
Три описанных квеста — это то, чего не хватает аналитикам, чтобы максимизировать пользу и выйти за рамки «просто запускаем эксперименты», а продактам — выйти из операционного режима «запустили → проверили → забыли».
Зрелый подход к экспериментам: чек-лист
Сеньор помогает бизнесу понять, какие гипотезы действительно влияют на результат, а какие — просто заполняют бэклог. Он говорит не «давайте попробуем», а «вот почему это стоит делать и как это повлияет на компанию». Отмечайте, что у вас уже есть:
Прямая связь с бизнес-целями
Корректные и валидированные метрики
Использование накопленных знаний
Единая терминология
Оценка краткосрочных и долгосрочных эффектов
Контроль за реализацией
Своевременная коммуникация
Рост ответственности и влияние на команду
Эксперименты и A/B-тесты — инструменты развития продуктовой культуры. С ростом зрелости компании и команды, тесты перестают быть технической проверкой и становятся способом принимать решения, фокусироваться на важном и говорить «нет» фичам, которые не приносят пользы. И в этом смысле сеньор-аналитик — это партнер, который несет ответственность за свои решения, основанные на данных и смысле.
А вы замечали у себя в команде переход от «мы просто тестим» к «мы принимаем продуктовые решения на основе данных»? Какие шаги были важными на этом пути и с какими кейсами пришлось работать? Пишите в комментариях.