Comments 7
Спасибо что поделились!
Помогите, пожалуйста, разобраться с несколькими вопросами:
Можно ли править метрики через несколько дней после заведения? Например, если оказалось что в sql события для метрики нужно добавить ещё одно условие, то и в кумулятивной таблице число хитов нужно пересчитать. Если можно, то как выстроен процесс обновления исторических данных?
Происходит ли во время заведения эксперимента в raw mode проверка правильности описания sql события и других полей? Когда пользователь или админ АБ-платформы узнают что в sql события есть синтаксическая ошибка (например, пропустили одну букву в имени функции или забыли скобку)?
Возможно ли посчитать значения метрик в разных комбинациях срезов? Например, узнать значение метрики эксперимента для любого сочетания платформы, страны, и других разрезов, включая выборку по всем, если эксперимент аффектит указанные срезы
Можно ли каким то образом при помощи Omicron посчитать сколько пользователей в тестовой и контрольной группе прошли цепочку действий (важно чтобы одно событие обязательно наступало после другого) и сколько отсеилось на каждом шаге? Например, 100 человек посмотрели рекламное сообщение -> 30 человек перешли на лендинг с промо акцией -> 10 человек оформили покупку по акции
Привет!
Да, можно. Раз в несколько часов запускается джоба, которая проверяет флаги у метрик на изменение. Если оно есть, история в кумулятивной таблице по такой метрике удаляется и начинается ее полный пересчет.
Да, происходит. Когда пользователь создал метрику через Raw Mode, то выполняется валидация на Spark. Сама метрика не вычисляется, а просто объявляется dataframe. Но если что-то не так, то джоба упадет, а в интерфейсе высветится ошибка.
Да, такая возможность есть. В аналитический репозиторий можно загрузить YAML, где будет описано, как нужно собрать датасет с таким-то разрезом (например, по странам), который потом приджойнится к результатам. При заведении эксперимента можно выбрать какие разрезы нужны, но комбинировать их в свободной форме нельзя. Во-первых, - это сильно нагружает расчеты, а во-вторых, - это будет завышать ошибку первого рода и такие эксперименты становится сложнее анализировать. Но если мы понимаем, что нам нужна именно такая комбинация срезов, то можно просто завести новый, где они будут объединены.
Нет, такие метрики посчитать уже нельзя. Проанализировав, мы увидели, что у нас они не очень востребованы. Поэтому мы от них отказались, но взамен получили возможность агрегировать данные (раз теперь не нужно хранить точное время срабатывания события) и от этого ускориться в расчетах. Альтернатива - это воспользоваться Raw Mode, где в filter указать несколько событий, которые должны были произойти. Получится похожая метрика, если последовательность событий все-таки не критична.
А возможен такой вариант что пересчет данных для экспа в кумулятивной таблице ещё не завершен, а уже пришло время готовить новый отчет по результатам экспериментов? Если да, то что будет в отчете?
И по третьему вопросу получается что сведения о стране локации и тд не содержатся в кумулятивной таблице и скорее будут получены из dependencies? И когда вы сказали что при заведении эксперимента можно выбрать какие разрезы нужны, имели ввиду что эксперимент можно раскатить на несколько платформ, стран и тд? Или как ещё в расчетах участвует выбор разрезов при заведении эксперимента?
Если такое произойдет, то эксперименты будут ждать пока досчитается кумулятивная таблица.
Да, срезов в кумулятивной таблице нет, они существуют отдельно. Раскатить на какую-то конкретную аудиторию тоже можно, но чаще всего выкатка будет на всех, так как потом придется поддерживать эти тоглы в коде проектов. Использование срезов позволяет проверять гипотезы для конкретных групп пользователей. То есть сам эксперимент может проводится на всей аудитории, но результаты в отчете мы можем посмотреть и по выбранным срезам тоже, тогда успехом будет считаться улучшение метрик в выбранном сегменте и то, что нет ухудшения на всей аудитории.
Вы сказали что комбинировать разрезы в свободной форме нельзя, а что мешает загрузить в аналитический репозиторий код, в котором датасет будет собираться с помощью методов cube/rollup/grouping sets? Понятно что это тот вариант, который сильно нагрузит расчеты, но интересно, не встречалось ли подобных примеров и что делать если в репозитории появляется такой код?
Расчетная архитектура платформы для A/B-тестов Mail.Ru