Тестирование на стороне клиента против. Тестирование на стороне сервера: оба выигрывают.
Опубликовано: 2020-05-28
Когда дело доходит до проведения экспериментов, оптимизаторы могут выбирать между тестированием на стороне клиента и тестированием на стороне сервера.
Хотя вы можете запустить почти все тесты на стороне клиента на стороне сервера и несколько легких внутренних экспериментов с помощью тестирования на стороне клиента (используя эксперименты с разделением URL или перенаправлением), это будет не так осуществимо и надежно, как вы. хотелось бы... потому что для любой гипотезы только одна из двух работает лучше всего .
И правильный выбор требует тщательного рассмотрения. Есть много аспектов, которые нужно взвесить, делая этот выбор. Посмотрите на влияние настройки на скорость и SEO, требования к усилиям и времени для жизненного цикла эксперимента, цель эксперимента и многое другое.
Давайте рассмотрим эти факторы и посмотрим, чем тестирование на стороне клиента отличается от тестирования на стороне сервера, а также плюсы и минусы каждого из них.
Тестирование на стороне клиента против. Тестирование на стороне сервера
В чем разница между тестированием на стороне клиента и тестированием на стороне сервера?
При тестировании на стороне клиента, как только пользователь запрашивает страницу, ваш сервер доставляет ее. НО, в этом случае ваш инструмент для экспериментов реализует некоторый Javascript в браузере вашего пользователя, чтобы изменить контент, доставляемый сервером, чтобы конечный пользователь получил соответствующий вариант на основе ваших правил таргетинга. (Браузер является «клиентом».)
С другой стороны, при тестировании на стороне сервера, когда пользователь запрашивает страницу, ваш сервер определяет версию для доставки и доставляет именно ее. Ваш инструмент для экспериментов работает на сервере, а не в браузере вашего пользователя.
Поскольку тестирование на стороне клиента происходит только при выполнении JS на уровне браузера, с его помощью вы можете тестировать только поверхностные вещи, такие как макеты, цвета и обмен сообщениями. Некоторые оптимизаторы называют такие тесты «косметическими».
Однако это не учитывало бы тестирование на стороне клиента.
Тестирование на стороне клиента может показаться простым, но оно действенно.
Легко отвергнуть A/B-тестирование на стороне клиента как «простое тестирование», которое может выполнить каждый. Согласен: это легко реализовать. А иногда это может быть всего лишь тестирование кнопки CTA другого цвета или текста.
Но будь то это или что-то столь же серьезное, как тестирование редизайна или обновленной страницы, тестирование на стороне клиента влияет на итоговую прибыль бизнеса .
Что такое тестирование на стороне клиента?
В двух словах: тестирование на стороне клиента означает, что оптимизация происходит на уровне браузера. В соответствии с установленными вами правилами таргетинга браузер посетителя изменит содержимое, чтобы оно отображалось в нужной версии.
В этом примере компания SaaS использовала Convert Experiences в качестве инструмента A/B-тестирования на стороне клиента, чтобы увеличить прирост потенциальных клиентов на своей домашней странице на 61%:
Вот еще один эксперимент A/B-тестирования с использованием Convert Experiences в качестве инструмента тестирования на стороне клиента для той же SaaS-компании на ее странице с ценами, который привел к увеличению числа лидов на 57 %:
Большинство историй успеха по оптимизации конверсии, которые вы видите в Интернете, — это тесты на стороне клиента, которые успешно оптимизировали опыт на поверхностном уровне и принесли большие плоды.
Но тестирование на стороне сервера действительно позволяет вам тестировать больше.
Когда вам нужно протестировать глубже, чем внешний интерфейс, вам нужно пройти тестирование на стороне сервера.
Что такое тестирование на стороне сервера?
Тестирование на стороне сервера — это тип эксперимента, в котором веб-сервер определяет версию контента для доставки. При тестировании на стороне сервера вся оптимизация осуществляется непосредственно на серверах, а не в браузерах посетителей.
Давайте рассмотрим это в перспективе с несколькими сценариями.
Если бы вы занимались электронной коммерцией, вы могли бы использовать эксперимент A/B-тестирования на стороне клиента, чтобы узнать, может ли переработанная панель поиска увеличить ваши поиски в магазине (и привести к увеличению продаж).
Но если вы хотите протестировать новый алгоритм поиска, который мог бы выдавать более релевантные результаты поиска (и который в долгосрочной перспективе привел бы к увеличению продаж), вам нужно было бы провести эксперимент A/B-тестирования на стороне сервера. .
Если бы вы занимались бизнесом B2B SaaS, вы могли бы провести эксперимент на стороне клиента, чтобы определить, работает ли определенный UVP лучше на вашей домашней странице. Или если длинная копия может превзойти краткую.
Но если вы хотите протестировать более быстрый сервер и посмотреть, может ли он улучшить удержание или вовлеченность, вам нужно будет провести эксперимент на стороне сервера. Если вы хотите протестировать новую последовательность адаптации, вам снова придется провести эксперимент на стороне сервера. Поскольку помимо поддержки вашего нового рабочего процесса адаптации, тестирование на стороне сервера также позволит вам организовать многоканальный эксперимент, охватывающий электронные письма, SMS-сообщения и другие действия на разных устройствах.
Точно так же, если бы вы занимались SaaS-бизнесом B2C, вы могли бы провести эксперимент на стороне клиента, чтобы узнать, может ли определенный тарифный план работать лучше, чем другие.
Однако, если вы хотите протестировать лучший механизм рекомендаций, вам придется пройти тестирование на стороне сервера.
Как вы можете понять из различных вариантов использования тестирования на стороне сервера, оно больше направлено на создание лучших продуктов, а не на немедленную конверсию. В отличие от экспериментов на стороне клиента, направленных на немедленные продажи или конверсии, эксперименты на стороне сервера направлены на оптимизацию продукта или решения, чтобы увеличить пожизненную ценность клиента.
Можно сказать, что если тестирование на стороне клиента предназначено для маркетологов, то тестирование на стороне сервера предназначено в первую очередь для продуктовых и инженерных команд. А инструменты A/B-тестирования, такие как Convert Experiences, предлагают тестирование как на стороне клиента, так и на стороне сервера, чтобы приспособиться как к маркетинговым, так и к инженерным командам.
Попробуйте бесплатно в течение 15 дней!
Поскольку тестирование таких глубоких изменений на уровне продукта требует гораздо большего, чем простое манипулирование JS в браузере, оно не может происходить внутри браузера и должно решаться на уровне сервера.
В то время как тестирование на стороне сервера имеет свои уникальные варианты использования, некоторые компании используют его даже для проведения косметических тестов — тестов, которые будут работать без сбоев даже на стороне клиента.
Они часто делают это, чтобы избежать «мерцания» или феномена «вспышки оригинального контента». Мерцание происходит, когда инструмент экспериментирования изменяет исходный контент, обслуживаемый сервером, после того, как конечные пользователи уже видели его. Представьте, что ваши пользователи видят определенный заголовок, а затем видят, как он мгновенно меняется на другой. (Да, мерцание может серьезно ухудшить впечатление пользователя!)
В других случаях они делают это для повышения скорости. Хотя тестирование не замедляет работу веб-сайта и не вызывает серьезных проблем с производительностью, оно увеличивает воспринимаемую загрузку веб-сайта на секунду или две. Серверная сторона может сделать это быстрее.
Иногда компания может проводить эксперимент на стороне сервера вместо эксперимента на стороне клиента из соображений конфиденциальности или безопасности. Поскольку таргетинг аудитории происходит на сервере, а экспериментальный код находится на сервере при тестировании на стороне сервера, компании лучше контролируют аспекты конфиденциальности и безопасности.
Но реализация эксперимента на стороне сервера не всегда возможна, особенно когда клиентская сторона тоже подойдет.
Реализация экспериментов на стороне сервера
При тестировании на стороне клиента вам потребуются лишь ограниченные ресурсы для проектирования и разработки, чтобы проводить эксперименты и выполнять их. Они вам даже не понадобятся, если вы только вносите изменения в текст или меняете цвет кнопки. Все, что вам нужно сделать, это:
1. Войдите в такой инструмент, как Convert.
2. Используйте редактор WYSIWYG и создайте варианты.
3. Настройте эксперимент (задайте условия таргетинга аудитории, продолжительность эксперимента, размер выборки и разделение, уровень достоверности и т. д.).
Возьмите код JS и добавьте его на свой сайт.
И сделано.
Затем вы бы обратились за помощью в разработке, чтобы развернуть выигрышную версию, если контроль проиграет.
Однако тестирование на стороне сервера не так просто.
Здесь вам придется:
1. Создайте свой эксперимент в Convert Experiences
2. Разработайте и разверните все варианты эксперимента на своем сервере.
3. Сопоставьте свои развернутые на сервере возможности в Convert Experiences с помощью пользовательского кода (используя идентификатор вашего эксперимента, идентификаторы вариантов, заданные в вашем инструменте для экспериментов, и т. д.).
В таких экспериментах на стороне сервера ваш код должен сообщать серверу, какой вариант показывать текущему пользователю. Вы можете использовать файлы cookie, чтобы облегчить это. Например, чтобы реализовать A/B-тестирование на стороне сервера с помощью Convert, вам нужно настроить файл cookie со следующими данными:
Затем сервер прочитает ваш файл cookie и
обслуживать версию (и все последующие сеансы) соответственно.
Поскольку ваш сервер определяет, какую версию отправить пользователю, нацеливание происходит на сервере (а не внутри браузера, как при тестировании на стороне клиента). Точность вашего тестирования будет зависеть от того, насколько хорошо вы сможете закодировать условия таргетинга на своем сервере. Однако с тестированием на стороне клиента вы можете лазерно нацелить свою аудиторию на все ваши впечатления.
Кроме того, тестирование на стороне сервера может усложниться при установке нескольких серверов, а также при необходимости интеграции CDN.
4. Запустите эксперимент.
5. Выкатить выигрышную версию и откатить проигравшую.
Вам также может потребоваться очистить серверы, опубликовать окончательный вариант развертывания/отката.
Как видите, жизненный цикл эксперимента на стороне сервера длинный и сложный, в отличие от эксперимента на стороне клиента. Вот почему тестирование на стороне сервера требует некоторого обдумывания.
В общем, вы бы не проводили эксперимент на стороне сервера, если бы эксперимент на стороне клиента проводился…
Проведение даже одного эксперимента на стороне сервера является сложной задачей, поскольку его разработка и развертывание — это более ресурсоемкий и трудоемкий процесс.
Кроме того, если вы используете тестирование на стороне сервера для проверки изменений, которые можно легко проверить на стороне клиента, вам будет сложно добиться хорошей скорости тестирования и надежной программы экспериментов.
Кроме того, для таких экспериментов выбор экспериментов на стороне сервера, когда у вас есть несколько отличных инструментов A/B-тестирования на стороне клиента, которые позволяют запускать их без мерцания, не влияя на SEO или скорость, не обещает наилучшего использования вашего тестирования. пропускная способность.
Эксперименты на стороне сервера следует отдавать предпочтение только тогда, когда они подтверждают данную гипотезу. И они делают это довольно часто, потому что многие эксперименты, влияющие на итоговые показатели бизнеса, могут происходить только на стороне сервера.
Итак, расскажите нам… проводили ли вы какие-либо тесты на стороне сервера? Если да, то что было самым сложным в процессе? О, и если вы хотите запустить A/B-тестирование на стороне сервера, попробуйте Convert (бесплатно в течение 15 дней!)
