«Хотите уменьшить мерцание при выполнении A / B-тестов? Вот гениальное решение всех ваших проблем с мерцанием »

JavaScript - очень уникальный язык. Если вы спросите меня, мне это очень нравится. Потому что это дает мне свободу создавать и вводить новшества, не будучи слишком надежным. В течение года я создавал множество A / B-тестов (не знаю, что такое A / B-тесты? Подробнее об этом здесь), и после их создания я усовершенствовал свое искусство, чтобы решать действительно сложные задачи, даже не касаясь кодовая база.

Эта проблема

Одна из основных проблем, с которыми сталкиваются фронтенд-разработчики при проведении A / B-теста, - это «мерцание». Они абсолютные убийцы настроения. Независимо от того, насколько привлекательный пользовательский интерфейс вы создаете, чтобы побудить пользователя покупать что-то с помощью вашего A / B-теста, если есть мерцание, есть вероятность, что выручка упадет. Поскольку это не дает потрясающего пользовательского опыта.

Вариант использования

Давайте попробуем разобраться в этом на примере использования. Допустим, внизу страницы есть кнопка покупки. И ваша гипотеза такова: перемещение этой кнопки вверх на панели навигации будет привлекательным для пользователя. Чтобы пользователь купил ваш товар. Давайте посмотрим на возможные подходы, с помощью которых вы можете этого добиться.

Традиционный подход

Если вы хотите выполнить какую-либо операцию на узле HTML, он должен присутствовать в DOM. Традиционно мы используем таймер, который через определенное время проверяет, появился ли элемент в DOM. А затем мы вносим наши изменения. Но этот подход уязвим для мерцания.

Решение

Давайте посмотрим на универсальное решение для всех основных проблем с мерцанием. В вашем интерфейсном приложении есть функция, которая отображает кнопку в DOM. Мы хотим переопределить функцию и сначала вызвать исходную функциональность, а затем вызвать наш код.

Когда кодовая база приложения вызывает функцию renderButton. Поскольку мы переопределили функцию, будет вызвана новая функция. И вот здесь происходит волшебство.

Почему это уместно?

В идеале не рекомендуется выполнять переопределение функций в вашей кодовой базе. Потому что это может привести к катастрофе. Предположим, исходная функция возвращает значение 2,, а после переопределения функции возвращает 1. Было бы очень сложно отладить эту проблему, когда ваша кодовая база огромна.
Но но ... выполнение A / B-теста является исключением из этого правила. Потому что вы будете запускать код своего A / B-теста из инструмента тестирования, например, «oracle maxymiser». По завершении экспериментов вы выключите свою кампанию.

Лучшие практики

  1. Всегда имейте отдельный блок try / catch для выполнения ваших исходных функций и ваших новых функций. Потому что, если что-то ломается в вашем новом коде, это гарантирует, что исходная функциональность не будет нарушена.
  2. Всегда имейте заявление о возврате. Если вы переопределяете функцию. Когда вы вызываете исходную функциональность для сохранения возвращаемого значения в переменной. И верните это значение из вашей переопределенной функции.
  3. Никогда не изменяйте возвращаемое значение. Пока вы не будете абсолютно уверены, что он ничего не сломает. Потому что вы никогда не знаете, к какому эффекту может привести изменение возвращаемого значения.

Заключение

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

Следующий

Ваша кодовая база переехала в одностраничные приложения? Мол, React, а вы все еще хотите проводить A / B-тесты на лету? Следите за обновлениями в моих будущих сообщениях в блоге. Я буду демонстрировать, как вы можете использовать переопределение функций, чтобы перехватить внутренний жизненный цикл реакции для выполнения A / B-тестов.