Comments 25
Первым делом мы выбираем свободные сплит-группы 3 и 6, потом — случайным образом из занятых, например, 4 и 8.
скорее всего имеллись ввиду группы 4-7, а потом 5-9?
Соответственно, если нужно будет проверить какой-то вариант сплит-теста, то для такого пользователя можно будет включить какой-то один сплит-тест после отключения всех всех остальных.
А почему бы не писать автотесты только для победивших вариантов?
Как человек, который пишет подобные тесты, попробую ответить.
Сплит-тесты могут идти долго для сбора значимой статистики. За это время новый код легко может поломать некоторые варианты теста.
Сплит-тесты могут быть внедрены в очень важный функционал, например, в платежи. Поломка даже одного из вариантов будет критична.
Сплит-тесты могут идти долго для сбора значимой статистики. За это время новый код легко может поломать некоторые варианты теста.
Сплит-тесты могут быть внедрены в очень важный функционал, например, в платежи. Поломка даже одного из вариантов будет критична.
Вот в этом месте:
лежат подводные грабли. Через какое-то время вы будете при тестировании новых фич видеть результаты предыдущих тестов, часто смешанных и запутанных.
Надо по крайней мере делать t-test перед началом каждого теста и постоянно гонять A/A тесты.
Ну и новый хеш посчитать для каждого нового теста не может быть неприемлемо долго. Ошибочные результаты тестирования из-за повторного использования сплит-групп обойдутся гораздо дороже.
выдавать новым пользователям (при регистрации) и уже существующим сплит-группу в диапазоне от 1 до 2400 случайным образом.
лежат подводные грабли. Через какое-то время вы будете при тестировании новых фич видеть результаты предыдущих тестов, часто смешанных и запутанных.
Надо по крайней мере делать t-test перед началом каждого теста и постоянно гонять A/A тесты.
Ну и новый хеш посчитать для каждого нового теста не может быть неприемлемо долго. Ошибочные результаты тестирования из-за повторного использования сплит-групп обойдутся гораздо дороже.
Через какое-то время вы будете при тестировании новых фич видеть результаты предыдущих тестов, часто смешанных и запутанных.
Для законченных тестов все пользователи видят один и тот же вариант сайта. Спустя какое-то время эти тесты вряд ли будут как-то значительно влиять на текущие тесты.
Так же есть возможность посчитать KPI-показатели для вариантов теста, начиная с того момента, как пользователям были выданы сплит-группы. Если показатели будут сильно различаться, значит есть какая-то проблема.
Ого, быстро вы, всего за 3 месяца запили с момента начала обсуждения :)
Вопрос: а прикручивать прямо в этом инструменте анализ результатов с учётом статистической значимости планируете?
Вопрос: а прикручивать прямо в этом инструменте анализ результатов с учётом статистической значимости планируете?
А почему не захотели сделать тестирование в привязке к google analytics? Ведь гораздо больше интересной информации можно узнать.
Когда-нибудь мы расскажем почему мы перестати использовать Google Analytics для наших приложений пару лет назад.
Будет интересно очень — потомучто, например я не знаю как вы сможете посмотреть свой сплит в разрезе сегментов.Никак, а посмотреть очень нужно. Ведь зачастую бывает, что если еще глубже полезть в результаты тестирования, можно увидеть интересную информацию. Врятли вы осили всю глубину сегментов, которая там есть.
Мы просто также запили свой полуфреймворк — но смотрим данные в GA. Разумеется отклонение есть, но на длинной дистанции оно не заметно. Ну и clinet_id отлично выравнивает для залогиненых пользователей.
Мы просто также запили свой полуфреймворк — но смотрим данные в GA. Разумеется отклонение есть, но на длинной дистанции оно не заметно. Ну и clinet_id отлично выравнивает для залогиненых пользователей.
Окей, мне кажется я создал повод для ложных ожиданий. Попробую раскрыть тему.
Касательно же предлагаемых интерфейсом GA инструментов нареканий я, действительно, не слышал.
- Начиная с какого-то объема трафика GA начинает очень заметно семплить входящие данные (либо это делает сайт). Платой за аккаунт этот вопрос тоже перестаёт решаться (начиная с какого-то объёма трафика). У меня осталось в памяти, что они просто архитектурно не готовы к крупным источникам трафика.
- Вторым фактором оказалась невозможность покрыть унифицированно все платформы (Web, IOS, Android...) и все приложения.
Касательно же предлагаемых интерфейсом GA инструментов нареканий я, действительно, не слышал.
Посмотрел, что такое сегментирование в GA. Действительно интересная тема, если заниматься анализом незарегистрированных пользователей. Там доступны даже такие занятные атрибуты как уровень дохода. У нас же в свою очередь:
Профиль пользователя в нашей системе насчитывает около 100 различных атрибутов, так что возможности для сегментирования у нас, скомпенсированы в том, что мы можем быстро сегментировать так, как нам хочется, собранные данные. В том числе исторические.
Но, вообще, спасибо, что указали на GA, вероятно, мы вернемся к нему для тех самых "неавторизованных" страниц (там же ведь landing pages и форма регистрации, а они, конечено, важны и слабо покрыты в текущей реализации).
- Практически нет страниц для неавторизованных пользователей.
- Почти все тесты привязаны к профилям пользователей.
Профиль пользователя в нашей системе насчитывает около 100 различных атрибутов, так что возможности для сегментирования у нас, скомпенсированы в том, что мы можем быстро сегментировать так, как нам хочется, собранные данные. В том числе исторические.
Но, вообще, спасибо, что указали на GA, вероятно, мы вернемся к нему для тех самых "неавторизованных" страниц (там же ведь landing pages и форма регистрации, а они, конечено, важны и слабо покрыты в текущей реализации).
Я просто почему спрашивал — похвально конечно, сбор всей даты у себя, но так крутить ее как крутит GA по срезам сложно.
Кстати причем зарегистрированный и незарегистрированный? GA умеет склеивать сеансы по user id.
А так мы сами тоже долго у себя в проекте пилим самопальную полубиблиотеку. Так что идем туда же, куда вы.
Кстати причем зарегистрированный и незарегистрированный? GA умеет склеивать сеансы по user id.
А так мы сами тоже долго у себя в проекте пилим самопальную полубиблиотеку. Так что идем туда же, куда вы.
В целом инструмент годный
но вот После фразы:
Становится понятно, что так можно тестировать только веб-сайты и html-based мобильные приложения
Нативный код который может в AppStore ревьювится до 2х недель так тестировать не получится...
Кроме того, так нельзя тестировать ничего сложнее "поменял заголовок, поправил коэффициенты в формуле, поменял интерфейс заполнения очередной формочки, поменял форму выдачи поисковых резульатов",
тестировать какие то фичи новые, которые меняют логику хранения данных на бекенде например нельзя, потому что после завершения теста не получится привести данные к виду "как было без теста с учетом множественного пересечения с другими тестами"
но вот После фразы:
В дальнейшем мы планируем автоматически ставить задачу на «выпиливание» теста из кода после его окончания.
Становится понятно, что так можно тестировать только веб-сайты и html-based мобильные приложения
Нативный код который может в AppStore ревьювится до 2х недель так тестировать не получится...
Кроме того, так нельзя тестировать ничего сложнее "поменял заголовок, поправил коэффициенты в формуле, поменял интерфейс заполнения очередной формочки, поменял форму выдачи поисковых резульатов",
тестировать какие то фичи новые, которые меняют логику хранения данных на бекенде например нельзя, потому что после завершения теста не получится привести данные к виду "как было без теста с учетом множественного пересечения с другими тестами"
Становится понятно, что так можно тестировать только веб-сайты и html-based мобильные приложения
Нативный код который может в AppStore ревьювится до 2х недель так тестировать не получится...
Мы проводим тесты как на web и мобильном web, так и на мобильных приложениях. Для того, чтобы закончить тест, не нужно менять код. По окончании теста выбирается итоговый вариант и если мобильное приложение нам присылает, что оно поддерживает этот тест, то сервер ему будет всегда отвечать итоговым вариантом. Но т.к. после окончания тест в коде больше не нужен, то хорошим тоном является поставить задачу на то, чтобы подчистить код.
тестировать какие то фичи новые, которые меняют логику хранения данных на бекенде например нельзя, потому что после завершения теста не получится привести данные к виду "как было без теста с учетом множественного пересечения с другими тестами"
Пересечения теста с другими тестами считаются с целью, чтобы менеджер мог посмотреть на них и решить, стоит ли запускать тест с такими пересечениями. Например, тестирование кнопки в мобильном приложении никак не влияет на тестирование страницы профиля пользователя на web-е. Такое пересечение можно просто игнорировать. Если же в пересекаемом тесте проводится тестирование связанного функционала, то нужно, либо провести тестирование в другой стране, либо сделать его позже.
Что же касается изменения логики хранения данных, можно привести пример, когда это будет проблемой?
Что же касается изменения логики хранения данных, можно привести пример, когда это будет проблемой?
ну наверное для вашего продукта это не проблема
скорее это проблема моего продукта в котором сейчас практически вся бизнес логика захардкожена в мобильном приложении, а API это фактически два метода LOAD и SAVE плюс несколько RPC модулей для малозначащих фич...
но в целом спасибо за идею, буду думать как сделать тестовый фреймворк для своего продукта по вашему образу и подобию
Скажите пожалуйста
а после того как появилась информация о том
как считаются целевые KPI? и как они вообще выбираются аналитиками?
это отдельный бизнес процесс в котором аналитики задействованы или инициатор аб-теста может сам посмотреть где нибудь в Tableau и свои целевые показатели с расчетом статистиечкой достоверности результатов?
а после того как появилась информация о том
как считаются целевые KPI? и как они вообще выбираются аналитиками?
это отдельный бизнес процесс в котором аналитики задействованы или инициатор аб-теста может сам посмотреть где нибудь в Tableau и свои целевые показатели с расчетом статистиечкой достоверности результатов?
имелось ввиду после того как собрана информация по тестам
По сути, вы правы, инициатор теста может самостоятельно посмотреть разбивку KPI по группам и сделать drill down. В качестве интерфейса у нас используется Microstrategy. Если же ожидаемый эффект не входит в базовые KPI, то инициатор теста может поставить задачу аналитикам на более сложный анализ результатов. Статистическую достовероность в интерфейсе, насколько я знаю, не расчитываем и не показываем, оставляем этот вопрос на пользователя. Но этот пункт есть в списке фиче-реквестов.
комментарий удален
Планируется ли UserSplit выложить в opensource?
Sign up to leave a comment.
Как устроено сплит-тестирование в Badoo