Вельми вдячний!
Усі гіпотези ми перевіряємо за допомогою A/B тестування, вірно.
Пересічення експериментів ми не аналізуємо кожен раз, їх занадто багато і назбирати статистичну значимість на кожну варіацію пересічень дуже важко, якщо не неможливо. Але коли ми бачимо неочікувані результати і розуміємо, що це вплив іншого тесту, ми можемо вдатися до «аналізу тесту в розрізі іншого тесту»
Експерименти в нашій команді тривають в середньому від 13 до 17 днів. Цього часу достатньо, щоб назбирати статистично значимий результат, якого достатньо для прийняття рішення. Але також зустрічаються кейси, де adoption задачі маленький і тест треба тримати 1-2 місяці

Дуже дякую!
Вірно підмічено, велика кількість надбудов може призвести до дизбалансу і перевантаження. Тому треба бути готовим до реставрацій і перебудови

Дякую, кину порти хамачі в лінкд ін ;)
Насправді, ми доволі регулярно отримуємо фідбек від користувачів, щоб ми повернули старий функціонал, щоб повернули «старе» Taimi, оскільки юзерів дійсно заплутує новий функціонал. Але ми завжди приймаємо рішення виходячи з данних, якщо юзерів заплутує нова фіча і це видно — ми не закриємо це в тест.

Чи враховуємо ми, що якби ми тестили одну найперспективнішу фічу в квартал, то вона ймовірніше зайшла, бо не була б на фоні інших фіч, які могли теститись? Не враховуємо, але завжди тримаємо в думках. Ми хочемо розганяти нашу динаміку, а даний майндсет нас загальмує. Та якщо дані покажуть нам, що велика кількість фічей в квартал зменшує їх конверт в закриття в тест, ми задумаємось над зміною підходу і бачення

Важка тема, але сподіваюсь, що зміг донести основну думку

Романе, чи вважате ви, що зміни в монетизації треба робити насичено і стрімко, так сказати «широкими мазками», чи все ж це має бути плавний і структуризований процес?