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

В этой статье проведем глубокий анализ наиболее важных технических аспектов при реализации A/B-тестов и кампаний персонализации на стороне сервера через API.

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

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

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

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

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

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

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

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

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

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

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

Рендеринг на стороне сервера используется, когда требуются:

  • Значительные структурные изменения страницы
  • Редиректы на всю страницу
  • Безопасный доступ к внутренним системам (прайсинговые модели, товарные запасы в реальном времени)
  • Персонализация Single Page Apps перед рендерингом

Как реализовать переход к API на стороне сервера?

По мере развития интернет-технологий все больше компаний переходят от A/B-тестирования и персонализации на стороне клиента к серверным API по следующим причинам:

1) Производительность при загрузке страницы (устранение фликеринга, или эффекта «мерцания»).

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

2) Безопасность данных (сохраняется конфиденциальность данных в браузере).

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

3) Интеграция с собственными технологическими стеками.

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

4) Снижение ограничений браузера, таких как ITP и блокировщики рекламы.

Серверный рендеринг позволяет сохранять релевантные пользовательские данные для A/B-тестирования или персонализации в виде cookies первого порядка (cookies на стороне сервера) — то есть cookies, записанные через HTTP-заголовки с веб-сервера, в отличие от cookies или локальных хранилищ, записанных кодом Javascript.

5) Централизованный контроль IT-отдела над структурой сайта и изменениями.

Многие организации предпочитают держать контроль над структурой и содержанием страниц в руках своего IT-отдела.

6) Реализация за пределами веб-сайта (digital-панели в магазинах, мобильные приложения и т.д.).

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

Обеспечение контекста

Для принятия решений о персонализации и таргетинге требуется контекст о пользователе, например, где он находится, какой браузер использует на каком типе устройства и т.д.

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

Если через запрос к API персонализации передается достаточно данных, то можно обеспечить тот же контекст, что и в реализации на стороне клиента.

Гибриды решений персонализации на стороне сервера и клиента: гибкость и новые возможности

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

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

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

Рекомендации при переходе к использованию решения на стороне сервера

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

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

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

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

В настоящее время Dynamic Yield предлагает бесплатную 14-дневную пробную версию API exPerience. Просто зарегистрируйтесь для получения доступа к среде и начинайте экспериментировать.

О Dynamic Yield

Dynamic Yield помогает коммерческим брендам быстро доставлять и тестировать персонализированный, оптимизированный и синхронизированный цифровой клиентский опыт. Маркетинговые команды, команды по продуктам, разработке ПО и электронной коммерции более 400 брендов по всему миру используют платформу по оптимизации клиентского опыта Dynamic Yield в качестве технологического уровня, взаимодействующего с уже имеющимися у них решениями в области CMS, электронной коммерции и ESP. Dynamic Yield позволяет быстрее проводить циклические тесты и алгоритмически подбирать контент, товары и предложения под предпочтения каждого посетителя, что ускоряет рост ценности бизнеса в долгосрочной перспективе.

Если вы хотите узнать больше о решениях Dynamic Yield, пожалуйста, напишите нам (andrey@dynamicyield.com) или отправьте запрос на демо.

11
Начать дискуссию