Валидация продуктовых гипотез при помощи A/B-тестов
Специально унылый заголовок, потому что дальше я буду ворчать. Сильно.
Метриками и А/Б тестами можно завести разработку в кромешную жопу, зато все при деле.
A/B-тест — это когда вы делаете 2 варианта чего угодно, запускаете их параллельно. Потом пытаетесь что-то оценить относительно того, как они себя показали.
На этом теоретическая часть всё, достаточно.
Дальше разбираемся предметно. Докапываться я буду до практически всего.
Сама идея неплохая — а вот то, во что она потом превращается…
Фундаметнальный затык из проблематики, почему такой A/B-инструмент вообще появляется — это «мы не знаем». Запомните эту мысль, она пригодится.
Не знаем мы, или можем не знать, вообще-то многого:
- как новая версия или гипотеза себя поведет технически
- как новый вариант воспримут конечные пользователи
- выиграет ли он по какой-то эргономике
- принесет ли это нам больше конверсий, может нам скажут «о, давно бы так» и начнут больше денег давать
- станет ли у нас больше хорошего, и меньше плохого
- станет ли у кого-то еще больше хорошего, а мы так и быть, потерпим затраты
- так далее, так далее.
И в общем-то инструмент позволяет не угадывать, а попробовать. То есть сделать и замерить. Беда только в том, что если в руках микроскоп (вот этот), все проблемы = гвозди.
А/Б тестированием легко подменить реальные, продуманные, взвешенные и просчитанные (заранее!) прогрессивные убедительные шаги вперёд на бесконечную возню с метриками.
Один раз это сработает. Для действительно непонятного или комплЕксного вопроса — тоже сработает. А дальше гоп-компания аналитиков принимается «пробовать и мерить» всё подряд, потому что это несложно, можно голову не включать. Ни на старте, ни на финише.
Идея «не включать голову» и херачить по накатанной методике работает ровно до тех пор, пока не перестаёт. Но все уже привыкли «пробовать и мерить». Как же так, как мы можем вынести мусорку, не проводив исследование, стало ли лучше?
Один проблемный момент в этой связи я уже описывал: это риск скатиться в реактивные ситуативные шатания, вместо нормального аналитического (и стратегического) подхода. Мы не знаем, что действительно надо делать — поэтому давайте лучше кидать говно в стену, и смотреть, где больше налипнет. Это ж метрика!
Но это уже было, повторяться лень.
Второй проблемный момент от того, что в ваших процессах управления изменениями вырастает обязательный слой псевдо-аналитического буллшита. Ребята из команды_А теперь почему-то не могут просто взять, и сделать нормально (как их просили); им потребуется:
- выкатить список гипотез
- обосновать, какие из них они считают перспективными, и откуда-то выдумать цифры (потому что если они не выдуманные, что вы мерить собрались?)
- «защитить» это всё на совете каких-то скучающих васянов (защитить от чего? от здравого смысла?)
- воткнуть это всё в планы реализаций и выкаток, чтобы не пересекаться с другим буллшитом, который уже кто-то «меряет»
- озадачить инженерный отдел, чтобы минимум две версии не конфликтовали между собой, между инженеркой, между смежными системами и между другими экспериментами
- озадачить тестирование, чтобы они быстренько (тм) сделали двойную+ работу по проверке косяков и взаимных коллизий, причем успев в релизный план
- тормознуть раскатку других фич и развитие смежных систем, потому что «у нас тут эксперимент, неделю ничего делать нельзя, мы данные собираем»
- очень быстро качественно (ха) проанализировать собранное, зафиксировать и презентовать результаты эксперимента
- снова вернуть все системы в состояние, когда механика одна (старая, или новая), желательно не запачкав себе штаны техническим долгом
Это дорого. Это развесисто. Мотивации всё это делать, каждый раз, ради трехгрошовых изменений — исчезающе мало.
И да, это признак анти-паттерна и того, что происходит какая-то хуйня.
Если у вас любой, каждый чих вместо двух дней на реализацю (день + день проверка) обрастает херотой длиною в месяц на 20+ рыл = удачи вам в этом непростом мире.
И продукты у вас будут всё еще говно. Потому что бюрократия ради собственной важности, и дроч ради дрочки. Причем безо всякого удовольствия.
В общем, если мозг не включать — сдуру можно и хер сломать, даром что гидравлика.
Пойдем дальше. А что вы, собственно, меряте? И как вы это делаете?
Если подходить правильно, системно и комплексно, то вы должны мерить (в своем эксперименте) не просто набор метрик, которые выбрали. А вообще все доступные вам метрики, которые вы можете оценить качественно (лучше/хуже), и которые хотя бы гипотетически могут быть затронуты. Чтобы потом понять, нужны ли вам такие улучшения, такой ценой. Если еще будет на тот момент, что оценивать.
- плохой пример: мы ставим задачу «повысить проклик по кнопке», окей, рисуем кнопку размером с весь доступный экран. Еще чтоб мигала, чтоб наверняка. По кнопке — точно не промахнешься, вон как метрика выросла! Все остальные показатели разумеется сходили нахрен, и значительная часть аудитории считает вас рукожопыми дебилами. Booking-com не даст соврать. Дебилам обычно денег не дают.
- плохой пример: «увеличить LTV, снизить показатель отписок». Так давайте кнопку отмены подписки запрячем поглубже, на три экрана, через валидацию заказным письмом. И еще она работать перестанет, нет кнопки нет проблем. И конечно у вас показатель вырастет в моменте; следом аудитория пошлет вас нахрен как разводил и пидорасов (Яндекс, привет), чтобы потом не возвращаться к вам примерно никогда.
- плохой пример: давайте на конверт зальем еще вот такую аудиторию, завлекушечку нарисуем. А то, что аудитория говно, трафик мёртвый и все эти «новые пользователи» отваливаются через месяц, не отбивая даже затраты на привлечение — ну тут увы, тут наши полномочия всё, это уже за рамками нашего эксперимента. Надо ещё один, чтоб наверняка.
- плохой пример: у нас вот здесь поведение кривое-косое, но мы тупые и ссымся просто взять и сделать как надо — давайте рисовать эксперимент, чтобы за тот месяц пользователи прочувствовали, как им элементарный баг починить не могут, они же нас точно больше любить начнут.
Аналитик, который очень хочет показать, как он вот тут поднял метрику, будет максимально вовлечённо и старательно игнорировать все негативные последствия — и решения, и хода «эксперимента» — которые ему невыгодны.
Но это же удобно, голова не включалась, берут своё лень, косность и безразличие. Иногда даже прямо с саботажем идет процесс: как вы можете утверждать обратное, если не проводили эксперимента? Мы здесь аналитики. Этот суд не может судить королеву.
И далее у нас отрастает «эксперимент на эксперимент», потом если повезет «эксперимент чтобы понять, где мы обосрались в первом», «эксперимент чтобы все-таки показать, что получилась лажа» — ой, его же не произойдет, это тогда кому-то станет явно видно, что мы делали херню; не, вот такого эксперимента не будет.
Паровоз едет только вперед. Выкатывая сомнительные «улучшения», эксперименты ради экспериментов, и метрики ради метрик.
Наверное, если быть большим оптимистом, ваш продукт от этого не станет фундаментально в моменте хуже (что, впрочем, тоже не факт). Со временем — естественно, станет.
Но проблемнее то, что и лучше он от всего этого тоже не станет; нормальные исправления, нормальные улучшения, просто требуемые инженерные решения никогда вовремя никуда не доедут, а если доедут, то будут полужопыми, с кучей лишних телодвижений и с опозданием в год.
Дальше «ой, а почему мы закостенелое насквозь устаревшее говно», и «когда мы стали грёбаным мейлру».
Зато столько народу при деле, все чем-то заняты, все зарплату получают. Зачем отказываться.
Еще уместно задать вот какой вопрос. Вы хотите эксперимент, потому что вы не знаете ответа, и хотите его поискать.
Задаю вопрос: а почему вы, собственно, не знаете результата? Причем настолько, чтобы месяц жечь ресурсы — чтобы что? Чтобы расписаться в собственной профнепригодности?
Ситуация «ну мы попробуем и потом решим» это очень слабая позиция, и не надо себя обманывать. У вас аналитически и эмпирически данных нет? Выводы не сделать? Вы настолько не понимаете потребности аудитории, что готовы туда-сюда кровати в борделе двигать? Так это иначе решается.
Если у вас кромешный кризис идей, «что мы должны прямо сейчас улучшить, чтобы стало заебись», то это два варианта:
- либо улучшать уже нечего (так бывает), нечего маяться дурью, мальчик положи молоток где взял, работает = не трогай
- либо ни хрена не одупляете, что для чего и для кого делаете, а значит надо закрыть рот, разуть глаза, и отправиться задавать вопросы к тем, кто в этом что-то понимает
На последнем следует остановиться подробнее.
Самых простых (но не самых правильных) способа сходу два. Попробовать самому — раз, и спросить тех кто вам деньги платит (пользователей) — два.
Понять херню самому и наощупь проще всего, но — для этого надо стать пользователем, хотя бы притвориться, хотя бы по станиславскому. Глобально здесь есть ограничения и потолок, но хотя бы самые элементарные штуки вы сможете найти и выписать на бумажечку.
Спрашивать пользователей — всегда отдельная дисциплина олимпиады для инвалидов, но опять же, хотя бы вектора идей вы нащупать сможете. Которые пойдёте прорабатывать.
Если даже на этих двух подходах прозвучит фраза «давайте соберём A/B эксперимент», следует автору фразы мгновенно уебать с ноги.
Надеюсь, понятно, почему.
Хорошие и качественные подходы (другие!) предполагают проблематику, карту целей, анализ альтернатив + плюс две базовые метрики.
- как дать человеку то, что он действительно хочет, причем быстро и без всякой лажи
- как сделать так, чтобы когда человек несет к нам денег, он не споткнулся в процессе
Но тут думать надо. Порекомендую все-таки начать.
Вы не можете дома взять и вынести мусор, надо обязательно разложить и вынести сначала половину, чтобы оценить перспективы и потенциальную пользу?
Вы в магазине покупаете только половину списка покупок, потому что надо «оценить что станет лучше»?
Механик вам в автомобиле тоже гайки наполовину закручивает? Или только с выбранной стороны на колёсах?
Регулярно моете только половину посуды, чтобы была контрольная группа пользователей, которые едят с немытых тарелок, а то вдруг еще откатим?
Еще можете заплатить только половину налогов, вдруг метрики просядут.
А чорт, таких людей я даже знаю.
Вывод у меня в общем-то простой: использовать A/B инструмент под задачу, и только там, где он действительно нужен + оправдан с точки зрения сожженного времени и тонны затраченных сопутствующих ресурсов.
Но мне по опыту кажется, что если ситуация уже запущенная, «само по себе» так точно не произойдет. Надо на управленческом уровне посчитать косты (включая неявные, типа сожженного ФОТ на дармоедов и проваленного годами time to market), затем записать всю эту дрочку в запрещенный анти-паттерн, и жестко бить по рукам — за подмену результата «взяли и сделали» псевдо-аналитическими бездарными туда-сюда фрикциями.