Как перейти от нуля к единице в своем путешествии по экспериментам на стороне сервера

Опубликовано: 2022-08-04

Думайте о своем путешествии как о пользователе Netflix. Если вы чем-то похожи на меня, вы можете посмотреть документальный фильм о дикой природе на своем телефоне, попивая утренний кофе. Ужин может сопровождаться любимой игрой на ноутбуке, например, Форрестом Гампом. По вечерам в выходные дни вы будете переключаться между своим профилем и профилем ваших детей, пробуя новые шоу Netflix, желательно на большом экране.

Теперь предположим, что Netflix проводит кампанию скидок для конкретной страны. Если вы участвуете в этой экспериментальной кампании, проводимой Netflix, как они гарантируют, что вы участвуете в одной и той же кампании каждый раз, когда вы входите в систему, независимо от используемого устройства и профиля, и везде видите одну и ту же рекламу? Как они гарантируют, что ваш опыт работы с вариантом, который вы обслуживаете, будет безупречным каждый раз, и что то, как вы взаимодействуете с вариантом, постоянно отслеживается?

Ответ заключается в многоканальном экспериментировании, что является типичным случаем тестирования на стороне сервера.

Должны ли вы предпочесть тестирование на стороне сервера, а не на стороне клиента?

Приведенный выше пример Netflix будет чрезвычайно сложным для выполнения на стороне клиента и может затруднить взаимодействие с пользователем. На стороне сервера его относительно легко запустить, и он обеспечивает единообразие работы пользователей. Это также обеспечивает минимальное влияние на производительность страницы. Кроме того, он устраняет любые проблемы, связанные с конфиденциальностью, поскольку в браузере как таковом нет активности.

Существуют и другие варианты использования, в которых рекомендуется тестирование на стороне сервера из-за его надежности и гибкости. О них мы поговорим в этой статье. Но сначала, что такое тестирование на стороне сервера и, что более важно, для кого оно предназначено?

При тестировании на стороне сервера варианты теста обрабатываются на веб-сервере. Когда посетитель попадает на тестируемую страницу, вариант загружается непосредственно с сервера и доставляется в браузер посетителя. Никаких последующих модификаций не происходит во внешнем интерфейсе или в браузере. В отличие от этого, при тестировании на стороне клиента исходная страница загружается первой в браузере посетителя, а ваша экспериментальная платформа создает вариант на самом интерфейсе с помощью JavaScript. Давайте разберемся с объемом этих двух форм тестирования на примере.

Представьте, что Майк и Боб — два друга, которые пытаются поэкспериментировать с работой новой машины. Майк за рулем и имеет доступ к тормозам, акселератору, приборной панели и т.п. Боб имеет представление о внутренних компонентах, таких как двигатель, радиатор, аккумулятор и т. д. И то, и другое может по-разному влиять на автомобиль. То, что Боб делает со своим доступом к компонентам автомобиля, может отразиться на внешнем виде Майка. Изменения, которые тестирует Майк, основаны на видимости автомобиля. С точки зрения покупателя автомобиля результаты экспериментов, проведенных Бобом и Майком, могут служить одинаково важным, но разным целям.

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

Какие проблемы можно решить с помощью тестирования на стороне сервера?

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

Стоимость доставки

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

Алгоритмы поиска

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

алгоритм поиска — Различные алгоритмы поиска

Длина формы

Формы запросов на бесплатную пробную версию и демонстрацию имеют решающее значение для предприятий SaaS. Но какова идеальная длина бланка, обеспечивающая меньше пропусков и в то же время фиксирующая всю необходимую информацию? Вы можете проверить необязательные поля с помощью тестирования на стороне клиента. Если ваше поле является обязательным, простое скрытие поля с помощью JavaScript не сработает, так как проверка формы с использованием логики на стороне сервера не удастся. Поэтому рекомендуется проводить тестирование на стороне сервера, чтобы поэкспериментировать с обязательными полями, чтобы оптимизировать длину и сложность формы.

Предложения и скидки

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

Стимулирование продаж

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

Потоки подписки

Сколько шагов в идеале должен включать процесс подписки? Должны ли быть предоставлены социальные логины? Ответить на эти вопросы помогут эксперименты с потоком подписки.

поток подписки — Различные шаги в потоках подписки

Платный доступ

Тестирование на стороне сервера позволяет протестировать различные конфигурации платного доступа надежным способом. Как издатель, вы можете запускать тесты на стороне сервера, чтобы экспериментировать с закрытым контентом и монетизировать его. Не рекомендуется запускать тот же тест на стороне клиента, поскольку посетители могут обойти платный доступ, удалив файлы cookie или отказавшись от них.

Мобильный банкинг

В процессе оформления кредита или кредитной карты можно оптимизировать несколько элементов. Но когда дело доходит до мобильного банкинга, безопасность данных становится первостепенной. При тестировании на стороне клиента конфиденциальные данные, собираемые банками или финансовыми учреждениями, могут подвергаться риску уязвимости. Чтобы избежать этого риска, для банковских приложений обычно рекомендуются эксперименты на стороне сервера.

Давайте теперь разберемся, как вы можете запускать тесты функций на стороне сервера и преимущества этого с VWO.

Как VWO упрощает тестирование на стороне сервера

Для сценариев использования на стороне сервера, описанных выше, VWO дает вам возможность структурировать вашу кампанию либо в виде A/B-тестов, либо в виде функциональных тестов. Тесты функций используются для проверки значений параметров функций и дают вам возможность быстро настроить функцию без написания кода. В некоторых случаях использования, таких как проверка того, какой алгоритм поиска лучше, можно структурировать кампанию как в виде A / B-теста, так и в виде функционального теста.

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

Тестирование функций позволяет такому менеджеру продукта, как вы, быстро тестировать и делать выводы с минимальной зависимостью от разработки и максимальным контролем над конфигурацией. Благодаря возможностям тестирования функций VWO вы получаете установленную структуру, в которой вам нужно писать меньше кода, поскольку платформа делает большую часть тяжелой работы за вас. В тестировании функций алгоритм может быть определен как переменная функции и настроен для управления и изменения эксперимента из самого потока настройки платформы, чтобы проверить, какой алгоритм поиска более эффективен.

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

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

Сложные варианты использования, подобные описанному выше, очень легко тестировать в VWO. Вот пояснительное видео, в котором показано, как можно быстро создать функцию платы за удобство и присвоить ей значение (в данном случае сумму комиссии). Вы можете связать свою гипотезу об определении платы, которая увеличивает доход, не влияя на количество бронирований, выбрать среду, в которой вы проводите тест, и включить свои варианты. Как только вы это сделаете, вам будет предоставлен код кампании, который будет сохранен на вашем сервере. Вам остается только определить цели, которые вы хотите отслеживать, и при желании сегментировать свою аудиторию — вот и все, ваша кампания готова.

Если вы менеджер по продукту и видите на панели инструментов, что вариант 3 не работает для пользователей; это негативно влияет на доход, вы можете убить его прямо сейчас, просто отключив изменение в VWO. Как показано на снимке экрана ниже, это не влияет на код и не требует от вашей инженерной группы внесения каких-либо изменений. Нужно его отключить, нажать «сохранить», и вариант перестанет получать трафик.

Скриншот приложения VWO — Скриншот кампании Feature test в VWO

По сути, код нужно внедрять только один раз за кампанию.

Должны ли вы построить или купить платформу для запуска тестов на стороне сервера?

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

Стоимость владения

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

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

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

Интуитивная отчетность

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

Безошибочный механизм

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

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

Обязательные возможности для запуска сложных тестов на стороне сервера с целостностью

Проведение экспериментов на стороне сервера может быть очень плодотворным при правильном выполнении. Для этого у вас должен быть правильный набор функциональных возможностей. Некоторые из них изложены ниже:

Рандомизация посетителей в каждом тесте. При тестировании, когда вы распределяете свою аудиторию по кампаниям, рандомизация посетителей должна быть действительно случайной, а не псевдослучайной.
Последовательный многоканальный опыт . Хотя группирование пользователей должно быть случайным, вам также необходимо убедиться, что каждый пользователь сталкивается с одним и тем же изменением каждый раз, когда он входит в систему, независимо от используемого устройства. Эксперимент должен продолжаться без каких-либо сбоев.
Взаимоисключающие кампании . Допустим, у вас есть три фактора, которые необходимо учитывать при определении того, должен ли пользователь участвовать в вашем тесте. Это может быть регулярность использования, низкая вероятность оттока и часовой пояс. Помимо учета этих переменных, вам также необходимо определить эксклюзивность — так в скольких тестах может участвовать пользователь, выполняющий эти условия? Это должно быть определено таким образом, чтобы это не приводило к искажению данных и позволяло вам беспристрастно отнести улучшение коэффициента конверсии к правильной кампании.
Стандартизированное соглашение об именах . Независимо от того, настраиваете ли вы новую функцию для тестирования или флаг функции, вам необходимо следовать стандартному соглашению об именах, чтобы избежать путаницы и случаев инициализации неправильных функций или тестов.
Уникальные и удобные идентификаторы кампании . Используйте буквенно-цифровой ключ, чтобы однозначно идентифицировать тест в своем коде и избежать каких-либо проблем на более позднем этапе.
Выбор правильной среды. Вы должны указать среду, в которой вы проводите тест. Например, вы можете развернуть тест в промежуточной среде или в среде контроля качества, чтобы ваша команда контроля качества могла проверить эксперимент. Проверка работоспособности вашего теста имеет решающее значение для его успеха, и у вас должна быть возможность выбрать для него подходящую среду.
Логическое распределение трафика. Когда вы запускаете несколько кампаний или когда у вас есть объявление о важном событии, например, о распродаже «Черная неделя», вам не нужно включать в тест весь набор посетителей, пришедших на вашу страницу. Вы должны выбрать процент трафика, который вы хотите включить в свою тестовую кампанию, а также то, как вы хотите распределить этот трафик между вариантами.
Расчет времени достижения статистической значимости. Расчетное время достижения статистической значимости вашим тестом должно определяться текущим коэффициентом конверсии вашей основной цели и минимальным улучшением, которого вы хотите достичь с помощью своих вариаций. Следует также учитывать 95%-ную вероятность превзойти базовый коэффициент конверсии.

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

В заключение

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

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