В процессе работы над PersMarket регулярно появляются новые возможности, которые должны быть видны не сразу или не всем. Для таких целей придумали специальный подход - Feature flags (или feature toggles). Я уже упоминал его ранее, когда писал про минимизацию рисков и даунтайма при деплое. Заключается подход в том, чтобы была возможность включать, выключать или менять поведение отдельных функций приложения в реальном времени без повторного деплоя. То есть код и настройки фичи выкатываются очередным релизом, но где-то в базе/конфигах есть переключатель/флаг, по умолчанию выключенный, от состояния которого зависит, работает ли эта функция. И когда приходит момент, флаг просто включают, и пользователи сразу видят новые ништяки. Например, функция оплаты актуальна только после всех согласований с платежным провайдером и обновления юридических документов, хотя код уже должен существовать, чтобы протестировать процессы.

Кстати, имея опыт работы со Stripe, подключал Робокассу. После современных API-управляемых возможностей Stripe Робокасса выглядит, как что-то из нулевых. В Stripe можно построить полноценный тестовый контур, с автотестами, с подписками, платежами, рефандами и т.д. В Робокассе можно сделать только тестовый разовый платеж без истории. То есть узнать его статус позже нельзя, он не хранится. А возвраты и рекуррентные платежи вообще не поддерживают тестирование. Надо будет попробовать других провайдеров еще для сравнения.

Еще сценарии: ▪️Если в функции есть критичный баг, ее можно отключить мгновенно без передеплоя ▪️Можно сделать канареечный релиз - включать функцию сначала малой аудитории, потом больше и больше ▪️Можно проводить A/B-тестирование ▪️Можно тестировать функцию прямо из мастер-ветки (особенно в trunk-based разработке), не включая ее на проде Вот и я себе сделал в админке сервиса такой пункт управления, чтобы включать фичи по мере готовности к ним платформы. А оказывается, есть и готовые решения: Split, Flagsmith, LaunchDarkly, GrowthBook, Unleash. А для PHP - Flagception. Конечно, не всё коту масленица, есть и минусы. Во-первых, появляются условия - сценарии для включенной функции и для выключенной, это усложнение. Во-вторых, если необходимость управления фичей отпадает, появляется технический долг - условия и feature flags надо удалять, а до этого обычно руки не доходят. Короче, знайте меру. #process

Улучшения наоборот Готовим с командой внедрение системы для проведения A/B тестов. Точнее MVP системы, потому что решили сделать сами, а не использовать готовое решение — с ним слишком много зависимостей и согласований, а наши потребности пока ограничиваются простыми экспериментами на веб интерфейсе. Добрался до конца спеки и задумался: какой эксперимент можно будет провести первым, чтобы проверить насколько правильно работает сбор событий по группам? Понятно, что самым первым нужно провести A/A тест, проверить распределение по группам и совпадение метрик. А вот какой тест должен гарантированно изменить целевую метрику? Решил, что это хороший момент попробовать ухудшающий эксперимент. Когда мы для небольшой тестовой группы в A/B тесте специально добавляем сложность в опыт пользователя. Их используют для других целей, когда делать улучшение сложно и долго, а сделать пробное ухудшение легко. Скорость загрузки страницы сайта и её влияние на конверсию хороший пример. Оказалось, что придумать ухудшение в своем продукте даже сложнее, чем его улучшить! Ведь нужно сделать так, чтобы конверсия воронки заметно уменьшилась, но это не стало блокером для всех пользователей из тестовой группы — сравнивать ноль с текущим значением конверсии невозможно. Пришлось посоветоваться с Клодом. Давайте вместе выберем из его предложений гипотезу для ухудшающего эксперимента? Воронка выглядит так: главная страница с описанием продукта и списком популярных товаров ➔ страница товара с его характеристиками и калькулятором кредита ➔ форма заявки на кредит (имя, номера телефона, адрес почты и поле с выбором уровня дохода) ➔ подтверждение номера телефона через OTP ➔ результат предварительной проверки с переходом на установку приложения. Ваши идеи — в комментарии. Или выбирайте несколько наиболее «правильных» вариантов в опросе👇🏻 1. Задержка страницы товара. Если добавить +1,5-2 с к загрузке, то конверсия «товар → заявка» упадёт, потому что часть пользователей уйдёт, не дождавшись. 2. Пустой калькулятор. Если убрать предзаполненные значения и показывать платёж только после клика «Рассчитать», то конверсия «товар → форма» снизится, потому что цену придётся добывать усилием. 3. Лишнее поле в форме. Если добавить пятое поле (например, город или дату рождения), то конверсия «форма → OTP» упадёт, потому что каждое поле добавляет трение и тревогу от запроса данных. 4. Поздняя валидация. Если убрать маску телефона и показывать ошибки только после «Отправить», то доля завершивших форму снизится, потому что пользователи чаще ошибаются и бросают её. 5. Неудобный OTP. Если убрать автоподстановку кода и увеличить кулдаун повторной отправки с 30 до 60-90 с, то конверсия «OTP → результат» упадёт, потому что ручной ввод и ожидание провоцируют уход. 6. Лишний шаг перед установкой. Если после результата добавить экран с кнопкой «Продолжить», то конверсия в переход к установке снизится, потому что каждый лишний клик теряет часть пользователей. Посты по теме A/B тестирования: 📌 Уровень культуры экспериментов в компании. Как измерить и улучшать 📌 A/B тестирование для начинающих. Ответы на стыдные вопросы 📌 Зачем нужны ухудшающие эксперименты. Хорошая статья от GoPractice #productquestion

Самый смешно запоротый A/B в моей практике Как-то раз в A/B тесте нашей модельки с альтернативным решением, заказчику (онлайн-магазину) понадобилось рассказать, зачем нужно брать хэши от айдишников пользователей перед делением на группы, потому что заказчик хотел просто брать четные айдишники в одну группу, а нечетные в другую. Рассказали, что не все вещи, кажущиеся равномерным распределением, правда им являются. Рассказали про то как многие смело разбивают клиентов на группы по последней цифре телефона и потом внезапно узнают, что группы перекошенные. И даже рассказали, что не все хэши одинаково хорошо перемешивают группы и какие предлагаем использовать. Дальше первую неделю A/B видим как стабильно ведем в тесте, радуемся, готовимся праздновать, но на очередном созвоне с заказчиком мимолетом ловим очень тревожную фразу. СТО заказчика решил поделиться своим ноу-хау:«хэш же нам нужен, чтобы результат был максимально непредсказуемым, так что я сделал не hash(id), а hash(id+email), чтобы еще лучше перемешивало группы» 🗿 Осторожно интересуюсь: а когда человек не залогинен, как это работает? СТО: тогда e-mail - пустая строка. Я: а сразу после логина? СТО: сразу после видим e-mail и уже не пустая. В общем, при логине с вероятностью 50% группа менялась, а логин был обязателен для оформления покупки… Кстати, времени у заказчика на еще один правильный А/В не было, так что как вы думаете, что было дальше, и чем закончился проект? :)