В интернет-продуктах решения есть везде, начиная от названия события, цвета значка и заканчивая интерактивной формой продукта и даже стратегией.
Каждое решение влияет на опыт подмножества пользователей. В долгосрочной перспективе все они в большей или меньшей степени повлияют на стоимость продукта.
Чтобы не ошибиться в принятии решений, нам необходимо сначала протестировать с небольшим потоком. Такие тесты обычно представляют собой эксперименты A/B.
Как провести эксперимент A/B?
Если взять в качестве примера оптимизацию функций продукта, то в соответствии с бизнес-процессом он обычно делится на несколько звеньев: план продукта → разработка функции → запуск функции → принятие решения о продукте, и аналитики данных в каждом звене имеют соответствующую работу.
Экспериментальный дизайн A/B (этап предложения продукта)
На этапе предварительного обзора плана продукта мы можем в основном знать точку оптимизации функции или форму недавно запущенной функции.
На основании суждения бизнеса необходимо вместе с продуктом решить, проводить ли эксперименты A / B. При необходимости нам необходимо выполнить следующие приготовления на ранней стадии.
Прежде всего, аналитикам данных необходимо сформулировать показатели оценки после запуска функции по функциональным характеристикам.
Заранее подготовьте план оценки:
Во-первых, ожидания данных, которые могут быть согласованы с бизнесом всех сторон, могут использоваться в качестве основы для принятия решений, таких как запуск и расширение последующих функций; Во-вторых, чтобы судить, соответствует ли он нашим потребностям в соответствии с индексом оценки. Проверьте текущий журнал или данные о закопанных точках. Если данные отсутствуют, требования к разработке должны быть представлены вместе, чтобы обеспечить возможность оценки экспериментов A/B. Во-вторых, нам нужно определить схему отбора трафика для эксперимента A/B. Выбор трафика желательно должен соответствовать следующим условиям:
Во-первых, количество пользователей в каждой группе эквивалентно, и это может гарантировать, что результаты эксперимента A/B будут читабельны (величина величины слишком велика, чтобы расширить сферу влияния, а величина величины равна слишком мал для получения надежных результатов); Во-вторых, обеспечить, чтобы каждая группа пользователей была разделена на группы случайным образом, то есть не было существенной разницы в каждой группе пользователей, чтобы гарантировать, что в последующем эксперименте экспериментальная группа (группа B) и контрольная группа (группа А) имеет только одну переменную; Наконец, согласно обычной ситуации, лучше всего выделить 2 группы пользователей для каждой схемы, чтобы можно было исключить эффект случайных колебаний разных групп пользователей.
Вы можете спросить, если все вышеперечисленные условия соблюдены, то для плана необходимо как минимум 4 группы пользователей (группа AABB).
Итак, при определенном количестве активных пользователей, если есть несколько экспериментов A/B, которые нужно проводить параллельно, как обеспечить достаточное количество трафика, чтобы разные эксперименты не влияли друг на друга?
Это включает в себя концепцию экспериментального дизайна: пользовательская (трафик) иерархическая ортогональность.
Мы предполагаем, что, исходя из величины текущего количества активных пользователей приложения, для получения статистически относительно достоверных результатов требуется не менее 10% трафика каждой группы.
На этом этапе мы можем случайным образом разделить пользователей на 10 групп, каждая с 10% трафика, а именно A1, B1, C1... Такие результаты группировки могут помочь нам провести 2 эксперимента A/B одновременно (каждая A /B эксперимент, в AABB есть 4 группы пользователей).
Что, если в это время я захочу провести третий и четвертый эксперименты одновременно?
В этот момент мы называем 10 групп, только что разделенных на A1, B1, C1 и т. д., первым уровнем, а затем случайным образом делим пользователей первого уровня на 10 групп второго уровня, то есть 10% трафик группы А1 назначается случайным образом.Разделяется на 10 1% трафика на группы второго эшелона А2, В2, С3 и т.д.
Точно так же B1, C1 и т. д. также случайным образом назначаются каждой группе на втором уровне, так что можно получить 10 экспериментальных групп с 10% трафика на втором уровне.
Таким образом можно получить третий слой, четвертый слой и т.д. С помощью приведенных выше правил наслоения мы видим, что эксперименты между разными слоями не влияют друг на друга, то есть пользователи разных слоев ортогональны.
Таким образом, мы можем проводить несколько экспериментов A/B одновременно.
Верификация скрытых точек (этап функциональной разработки)
Вступая в стадию разработки, если есть новые закопанные точки, нам необходимо проверить точность сообщаемых закопанных точек.
Если вы дождетесь запуска функции, прежде чем вмешиваться, результаты эксперимента A/B могут быть не оценены из-за отсутствия или неточности скрытых точек.
Поэтому проверку скрытых точек необходимо проводить на этапе предварительной разработки, чтобы обеспечить доступность последующих данных.
Экспериментальный анализ (этап запуска функции)
После запуска функции пользователям обычно необходимо обновить и установить новую версию, прежде чем они смогут воспользоваться новой функцией.
Следовательно, для того, чтобы гарантировать, что определенный уровень пользователей испытает новые функции, необходимо обеспечить, чтобы скорость проникновения пользователей новой версии достигла определенного уровня. Также по этой причине эксперименты A/B обычно требуют периода наблюдения.
Продолжительность периода наблюдения связана с формой продукта: для высокочастотных приложений, таких как WeChat и Weibo, обычно достаточно одной недели, для относительно низкочастотных приложений, таких как Taobao, период времени больше.
При оценке метрик нужно обратить внимание на одну вещь:
Мы должны исключить влияние доэкспериментальных различий групп АВ, т.е. различий до АА.
На рисунке ниже показан график количества ежедневных активных пользователей в каждой группе.Если эксперимент запустить на 9-й день, если мы посмотрим только на график тренда после запуска, мы обнаружим, что количество активных пользователей в группе В2 значительно ниже, чем в группах А1 и А2.
Следовательно, можно сделать вывод, что режим экспериментальной группы B2 вызовет снижение DAU.
Однако, если мы посмотрим на данные до запуска эксперимента, мы обнаружим, что DAU группы B2 ниже, чем у групп A1 и A2 до запуска эксперимента, и разница между ними не вызвана экспериментом.
Экспериментальное решение (этап функционального решения)
На предыдущем шаге мы можем получить контраст преимуществ индекса экспериментальной группы и контрольной группы. Для этого необходимо принять решение по программе эксперимента.
Мы знаем, что эксперименты A/B не подходят для долгосрочного наблюдения, потому что для продукта не подходит одновременное наличие нескольких решений, так что между пользователями есть очевидные различия.
Кроме того, клиентский код эксперимента A/B также увеличит размер пакета приложения, и новые пользователи более чувствительны к этому, что может повлиять на конверсию загрузки пользователя; Кроме того, трафик, доступный для экспериментов A/B, ограничен, и занимать трафик в течение длительного времени также является пустой тратой ресурсов. Поэтому необходимо как можно скорее принять решение по результатам эксперимента. Если ключевые показатели экспериментальной группы значительно отрицательны, возможно, необходимо продолжить оптимизацию функции перед выходом в онлайн;
Если наблюдаемые ключевые показатели не сильно изменились, но сильно изменилась сама функция, рекомендуется расширить наблюдение за трафиком, если показатели в экспериментальной группе имеют положительные преимущества, также рекомендуется напрямую протолкнуть их все.