heart Created with Sketch. test
Курс «A/B-тестирование»

A/B-тестирование и персонализация на стороне клиента и сервера: какой метод выбрать и когда | Глава 10

Сравним проведение тестов и кампаний по персонализации на стороне клиента/сервера и разберем наиболее важные технические аспекты вопроса.

← Предыдущий урок

(Перед вами перевод бесплатного курса по A/B тестированию от компании Dynamic Yield. Если вы здесь впервые, то лучше начните сначала)

Автор английской версии: Джон Пилер, директор по разработке корпоративных решений в Dynamic Yield

Варианты рендеринга A/B тестов и кампаний по персонализации 

По мере развития интернета и онлайн-коммерции, проведение A/B тестов и кампаний по персонализации пользовательского опыта уже стало повсеместной практикой маркетинга.

Со временем выделились два основных подхода к проведению A/B тестов и персонализированных кампаний

Мы обобщили суть каждого из подходов и отличия между ними в таблице: 

На стороне клиента (Client-side)Только на стороне сервера (Server-side)
Общий принципВ качестве метода тестирования и персонализации используется Javascript. Все динамические действия выполняются на стороне клиента, в браузере.Javascript теги размещаются в верхней части HTML кода с асинхронной загрузкой. Либо теги можно разместить в асинхронном менеджере тегов.
РеализацияДобавляется на страницу в браузере посредством добавления Javascript тегов.Встраивается в технологический стек вашего веб-приложения на бэкенде.
Сроки реализацииЗапускается довольно просто и быстро путем добавления нескольких строк кода в хедер страницы.Более продолжительное время запуска, потому что требует продуманного дизайна и разработки вашей командой.
Просто использованияБизнес-пользователи могут сами создавать персонализированные опыты через интерфейс вендора. У разработчиков меньше контроля над изменениями, внесенными в сайт.Процесс создания экспериментов и персонализированных кампаний сложнее для бизнес-пользователей, потому что требует знаний структуры веб-приложений и формата JSON. У разработчиков больше контроля над изменениями на сайте.
ВозможностиОбычно ограничены изменениями в рамках самой страницы.Тестирование и персонализацию можно интегрировать с бэкэндовыми системами (например, со складом).
Влияние на загрузку страницыНезначительно увеличивается вес страницы и скорость загрузки.Персонализация выполняется до рендеринга страницы, поэтому никакого эффекта на отображение страницы не оказывает.
ОхватОграничивается веб-браузерами.Можно добиться персонализации на любых устройствах и платформах, способных выполнять вызовы API.

А теперь давайте разберем каждый подход в деталях. 

Как работает тестирование и персонализация на стороне клиента. 

Тестирование на стороне клиента — это самый распространенный способ тестирования, который используют маркетологи сегодня. Этот подход предполагает рендеринг всех экспериментов и персонализированных опытов в браузере клиента посредством Javascript.

Что такое “рендеринг на стороне клиента”? 

Когда вендор услуг по тестированию и персонализации просит вас добавить в HTML-код всех страниц сайта Javascript теги, это дает ему возможность внедрять на ваш сайт SDK для тестирования и персонализации на базе Javascript. Наряду со своими основными SDK вендор внедряет на сайт ваши персонализированные кампании и эксперименты — точнее их код; сами кампании и эксперименты вы настраиваете через интерфейс вендора. После добавления тегов на сайт, вендор может реализовать логику эксперимента/персонализированной кампании и изменить контент страницы в браузере клиента через Javascript. 

Все вендоры используют одну и ту же технику модификации: кусок кода в SDK выполняет нужное действие под отдельно взятый кейс. 

Несколько примеров рендеринга на стороне клиента: 

Как работает тестирование и персонализация на стороне сервера?

Если при традиционном тестировании на стороне клиента персонализация реализуется прямо в браузере посредством Javascript, интеграция на стороне сервера позволяет обратиться к сервису персонализации еще до рендеринга страницы в браузере —  через собственный технологический стек (backend). 

Итак, что такое рендеринг на стороне сервера? 

Тестирование и персонализация на стороне сервера обычно реализуются вендорами в форме REST API, который вызывается из веб-приложения (то есть с сервера) до отправки страницы в браузер. Запросы и ответы к REST API выполняются в формате JSON — широко распространенном и эффективном формате представления данных.

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

Ответ, как правило, представляет собой данные в формате JSON. Парсинг и исполнение ответа происходит на стороне, отправившей запрос. Вы также должны отправлять любую информацию о взаимодействии пользователей с персонализированным контентом и о других значимых событиях обратно на сервер — способом, аналогичным персонализации (POST на API endpoint).

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

Несколько кейсов использования рендеринга на стороне сервера:

Что выбрать: тестирование на стороне клиента или сервера? 

При выборе способа тестирования (на стороне клиента или на стороне сервера) большинство маркетологов в первую очередь беспокоятся об удобстве (баланесе доступности и функциональности); проще говоря, их интересует какой из способов проще интегрировать и использовать? 

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

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

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

Гибридные решения 

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

Неизбежный переход на API 

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

Поэтому рекомендуем все же переходить от простого и быстрого тестирования на стороне клиента на более продвинутые эксперименты на сервере.


← Назад | Продолжение (Глава 11) →


Курс «A/B-тестирование»