На сегодняшний день все наиболее интересные истории на тему производительности включают в себя ту или иную форму А/В тестирования, когда сравниваются две группы пользователей и с научной точки зрения демонстрируется, что более быстрые веб-страницы приносят большую выгоду для бизнеса. Хотя длинный список примеров заставил убедиться в этом многих технических директоров, некоторые все еще хотят, чтобы А/В тестирование лишний раз показало ценность ускорения.

На конференциях вроде Velocity техническая элита говорит об А/В тестировании, как о чем-то простом и само собой разумеющемся. Часто можно услышать о том, что потребовались лишь «минуты» для получения статистически жизнеспособного результата из совершенно небольшой доли трафика, и о том, как эти результаты легко было собирать и анализировать. Практический же опыт в проведении А/В тестирований производительности сайтов можно назвать как угодно, но не “легким”.

На протяжении нескольких лет сотрудники Strangeloop под руководством президента Джошуа Биксби разрабатывали собственные методологии проведения тестирований для своих клиентов и вынесли из этого опыта несколько уроков. В статье будут представлены некоторые из них.

Во-первых, будет рассказано о типичных случаях, встречающихся в работе с клиентами. Во-вторых, будут рассмотрены мельчайшие детали тестирования. И, наконец, довольно большая часть времени будет посвящена проблеме того, как убедиться, что полученные результаты являются статистически значимыми.

Реальные сценарии А/В тестирования
Д. Биксби довелось поучаствовать во многих А/В тестированиях, касающихся производительности. Целью этих тестирований была попытка оценить объем улучшения производительности (или, в даном случае, комплекс улучшений). Для теста обычно берутся две отдельные группы: Ускоренная и Базовая.

Обычно тестирования проходят согласно двум сценариям:

Сценарий 1: Хороший (или тот, о котором рассказывают)

  • День 0: Технический директор хочет, чтобы А/В тестирование доказало выгоду от ускорения сайта. Он немного нервничает и хочет начать с небольшой доли подвергнутого ускорению трафика (скажем, 5%).
  • День 0,5: Техническому директору не поступает жалоб от клиентов, сайт работает нормально.
  • День 1: Технический директор и аналитик не отрываясь следят за показателями. Прибыль начинает расти.
  • День 2: Технический директор видит, что может заработать больше, и немедленно увеличивает долю ускоренного трафика до 50%.
  • День 5: Он убедился в полезности ускорения и переводит весь трафик в сегмент “Ускоренный”.

Сценарий 2: Плохой (или тот, о котором не говорят)

  • День 0: Технический директор хочет, чтобы А/В тестирование доказало выгоду от ускорения сайта. Он немного нервничает и хочет начать с небольшой доли подвергнутого ускорению трафика (скажем, 5%).
  • День 0,5: Техническому директору не поступает жалоб от клиентов, сайт работает нормально.
  • День 1: Технический директор и аналитик не отрываясь следят за показателями. Прибыль начинает падать.
  • День 2: Технический директор видит, что теряет деньги, и немедленно завершает тестирование.
  • День 3: Технический директор теряет всяческий интерес к проблеме, попытки убедить его начинаются с нуля.

Хотя Сценарий 1 намного более предпочтителен, они оба могут оказаться некорректными. Чтобы тестирование ускорения считалось успешным, его результаты должны обладать статистической значимостью, должны учитываться долгосрочная изоляция сегментов и проблема повторной сегментации.

Но, прежде чем рассматривать проблемы, стоит изучить вопрос сбора информации…

Проблема 1: Использование таких аналитических инструментов, которые будут соответствовать принципам сегментации и позволят получить необходимую информацию

Проблема: Основа сегментации — это базовый принцип разделение пользователей на А/В группы, не важно, в помощью back-end кода или как-то еще. Но принцип разделения — это не аналитический инструмент. Поэтому иные инструменты (такие как Google Analytics или Omniture) должны быть использованы для сведения воедино результатов тестов и их демонстрации в привычном для аналитики виде (в виде отчетов, графиков и т.д.)

Решение: Во время подготовки тестирования убедитесь, что выбранные вами аналитические инструменты согласуются с принципами сегментации и позволят получить необходимые данные. В Strangeloop, например, Google Analytics интегрирован в сам продукт, так как многие клиенты его используют. Клиенты могут видеть показатели, представленные следующим образом:

или даже проще:

Strangeloop также помогли своим клиентам интегрироваться с Omniture, обновляя уже существующий код для сбора информации по сегментам.

Выяснив, каким образом следует собирать данные, вы столкнетесь со следующим…

Проблема 2: Необходимость убедиться, что пользователи остаются в одном сегменте

Проблема: Необходимо снова и снова проверять, чтобы пользователи оставались в одном сегменте, особенно если пропорции сегментации должны остаться неизменными.

Почему? Есть две причины:

Во-первых, потому, что выгода от ускорения страниц не является однократной. Она проявляется на протяжении все истории взаимодействия пользователя с сайтом. Известно, что удовлетворенные пользователи с большой вероятностью вернутся на ваш сайт, также известно, что, если у данной группы пользователей страницы грузятся слишком долго, потребуется около шести недель на восстановление трафика от этой группы до нормального уровня. Если вы пытаетесь понять поведение пользователя, но при одном посещении предоставляете ему доступ к ускоренной странице, а при другом — к стандартной, у вас не получится собрать полезной информации.

Во-вторых, у браузера есть кэш, и то, что остается в кэше после посещения вашего сайта, меняет долгосрочную историю посещений сайта. Если при первом посещении пользователь попал на ускоренную страницу, а при повторном — нет, нельзя сказать, что для них скорость загрузки будет базовой, так как в кэше их браузера уже сохранены оптимизированные данные.

Решение: При подготовке к тестированию убедитесь, что пользователи, при первом посещении сайта помещенные в «Ускоренную» группу, попадут в нее же при повторном посещении, и наоборот.

Проблема 3: Подсчет пользователей до, во время и после тестирования

Проблема: Вам необходимо иметь возможность определять, является ли пользователь, которого вы анализируете, новым или он заходил на ваш сайт раньше. И вот почему: пользователь — назовем его Боб — был на сайте два дня назад, до того, как вчера началось А/В тестирование. Боб возвращается на сайт сегодня и попадает в «Ускоренную» группу. В аналитических отчетах Боб отображается как повторный посетитель. Исходя из правил проведения ускорения, сайт должен работать действительно быстро, так как у пользователя должен был быть сохранен оптимизированный кэш. Но первый визит Боба был до того, как сайт начал предоставлять хороший кэш. Итак, если смотреть в целом, Боб на самом деле является новым, а не повторным посетителем, так как его нельзя рассматривать как пользователя с уже загруженным оптимизированным кэшем.

Решение: Пользовательский опыт Боба практически идентичен опыту любого нового посетителя с начала проведения тестирования, и именно к этой группе пользователей его следует относить.

Проблема 4: Подсчет и оптимизация пользователей до и после ресегментации

Проблема: Эта проблема схожа с Проблемой 3. Пользователь — скажем, Элис — впервые посетил сайт два дня назад, через неделю после начала тестирования, и попал в «Базовую» группу. Но вчера пропорции А/В тестирования были изменены, и когда Элис вернется на сайт сегодня, она попадет на ускоренный сайт. И снова, в аналитическом отчете она отобразится, вероятно, как повторный посетитель, возникает так же проблема, что с Бобом в предыдущем пункте: ее кэш не был оптимизирован ранее.

Решение: Есть два варианта:

  1. Рассматривать Элис как нового посетителя (и каким-то образом убедиться, что аналитический инструмент будет отсеивать повторных пользователей; в Google Analytics такой возможности нет), или
  2. Внести в принципы сегментирования пункт о том, что Элис навсегда останется в первоначальной группе. Если пойти этим путем, распределяться по группам, по сути, будут только действительно новые пользователи и, один раз попав в определенный сегмент, останутся в нем и в дальнейшем. В этом случае следует учитывать, что простое соотношение между пользователями из групп А и В не будет на самом деле отражать соотношение, указанное в принципах распределения по группам (но пропорция новых пользователей должна).

Проблема 5: Как насчет многовариантного или А/В/С/D тестирования?

Теперь, когда вы увидели всю сложность А/В тестирования, представьте, сколько головной боли связано с многовариантными тестами. Что если мы решим проводить А/В/С/D тест (А=Базовый, В=Ускоренный с одним набором технологий, С=Ускоренный с другим набором технологий, D=Ускоренный с третьим набором технологий)? В этом случае все эти проблемы становятся гораздо серьезнее.

Будем считать, что вы узнали обо всех возможных проблемах. Настало время рассмотреть шестой и самый главный вопрос: статистическую значимость.

Проблема 6: Необходимость убедиться, что результаты тестирования статистически значимы.
В начале данной статьи говорилось о хорошем и плохом сценариях проведения тестирования, и есть кое-то, на что не обратили внимания технические директора в обоих случаях.

Проблема: Многие клиенты хотят, чтобы вводимые меры по ускорению сайтов оказали значимое влияние на показатель конверсии. Часто показатели конверсии существенно варьируются, поэтому реальные данные могут выглядеть следующим образом:

Дата Ускоренный Базовый
15 ноября 3.78 3.77
16 ноября 3.77 3.68
17 ноября 3.88 3.70
18 ноября 4.96 4.77
19 ноября 2.53 2.28

Итак, каким образом вы определите, что эти цифры доказывают корреляцию между ускорением и конверсией?

Решение: Существует статистический тест (он называется хи-квадрат тест), который можно использовать для определения статистической значимости. Не вдаваясь в математические расчеты, можно показать, как использовать бесплатный онлайн сервис Split Test Calculator, чтобы получить ответ.

Прежде всего, нужно собрать и обобщить полученные в Google Analytics данные о количестве посетителей, числе целевых транзакций как для ускоренного, так и для базового сегментов. В таблице ниже представлены данные за 15-19 ноября:

Ускоренный Базовый
Посетители 485882 55423
Целевые транзакции 18985 2093
Общий показатель конверсии 3,91% 3,78%

Затем нужно внести цифры в форму в Split Test Calculator, используя «Ускоренные» значения для Группы А и «Базовые» для Группы В.

В данном случае, Split Test Calculator определил, что нет победителя с 90% уровнем уверенности. Другими словами, существует более чем 10% вероятность, что разница между 3,91% «Ускоренного» и 3,78% «Базового» показателей возникла из-за вариативности входных данных и не является статистически значимой. Полезным в этом калькуляторе является то, что он подсчитывает, что четкий победитель может быть определен при сборе информации о 101703 дополнительных пользователей — потребуется продлить тестирование еще на несколько дней.

90% вероятность может показаться слишком высоким значением для такого типа эксперимента, и для хи-квадрат теста может быть установлен более низкий уровень уверенности. Для подобных данных разница является значимой при 85% вероятности. Иными словами, существует менее 15% шанса, что разница в показателях конверсии является случайной.

Что стоит запомнить:

  • Используйте Split Test Calculator, чтобы определить количество посетителей, необходимое для получения надежных результатов. Будьте дисциплинированы и не делайте выводов, пока у вас нет жизнеспособного образца.
  • Если любое тестируемое вами ускорение оказывает какое-либо влияние на кэш браузера, убедитесь, что вы знаете, как избежать смешивания пользователей из разных групп.
  • Если вы планируете изменить пропорции сегментации во время проведения тестирования, убедитесь, что вы знаете, как избежать смешивания пользователей из разных групп.

Перевод.
Автор оригинальной статьи Джошуа Биксби.

Метки: