Что я как продакт делаю, чтобы не облажаться в A/B тестах Где-то чуть меньше года назад я проходила систем-дизайн интервью. Не абы где, а в Яндексе и Тиньке. Спойлер: успешно.

Это отвратительное мероприятие секция собеса, где тебя просят спроектировать систему: объяснить, как всё будет работать, какие базы данных использовать, какие сервисы куда ходят и какие потенциальные узкие места.

Ну и вот честно, до сих пор считаю, что это избыточно для продактов. Ну серьёзно, если ты не вгружен ежедневно в код и архитектуру, то это забывается очень быстро и использовать не приходится.

Но есть нюансы… потом ты запускаешь A/B тест. Радостно смотришь на метрики, планируешь следующий шаг... И тут кто-то задаёт роковой вопрос:

"А версии продукта ты учёл?" 🤪 В одной версии баг, которого в другой уже нет. 🤪 У части пользователей старый дизайн, у части новый. 🤪 Новички ведут себя иначе, чем те, кто видел продукт до теста. 🤪 Результаты теста? Просто набор рандомных цифр.

Вот тут-то и вспоминаешь, что систем-дизайн — не только про сервера и базы данных, а про понимание, как работает продукт (кажется, компаниям можно пересмотреть секция). Запускай А/Б и учитывай: 📌 Версию продукта. Без этого тест может не иметь смысла. 📌 Отсеивай выбросы. Если пользователь мигрирует между версиями – его данные только испортят картину. 📌 Делай сегментацию. Новички ≠ старые пользователи. Их поведение не должно мешать анализу.

Как хорошо, когда в команде есть продуктовый аналитик 😄

repost

74

input message

напишите коммент

еще контент автора

еще контент автора

войдите, чтобы увидеть

и подписаться на интересных профи

в приложении больше возможностей

пока в веб-версии есть не всё — мы вовсю работаем над ней

сетка — cоциальная сеть для нетворкинга от hh.ru

пересекайтесь с теми, кто повлияет на ваш профессиональный путь