Гибридная персонализация в веб-SDK Adobe Experience Platform

Если вы используете Adobe Experience Platform (AEP), вы, вероятно, уже слышали о Web SDK, также известном как сплав.js. Это клиентская библиотека JavaScript, которая позволяет клиентам взаимодействовать с различными сервисами в Experience Cloud. Если вы читаете это, возможно, у вас уже есть работающая реализация сплава на вашем веб-сайте. И вы даже можете использовать его для отображения персонализированного контента для ваших посетителей.

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

Гибрид что ли?

Многие пользователи Adobe Target уже знакомы с концепцией гибридной персонализации в at.js. Это отличный способ оптимизировать производительность страницы, переместив запрос на персонализацию из браузера на сервер.

Гибридный режим уменьшает задержку и может устранить мерцание страниц, а также гарантирует конфиденциальность данных. Пользователи at.js уже давно пользуются этими преимуществами, а теперь, с выпуском v2.13.0, могут и пользователи сплава (AEP Web SDK)!

Прежде чем мы углубимся в гибрид, давайте сначала рассмотрим три ключа персонализации. А затем изучите первые два варианта реализации, чтобы получить персонализированный контент на веб-сайте через Adobe Experience Platform.

Три ключа к персонализации

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

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

Реализация на стороне клиента

Подход на стороне клиента — самый простой и простой способ получить персонализированный контент. Все, что вам нужно сделать, это включить библиотеку Adobe Experience Platform Web SDK (alloy) на свою страницу, настроить ее и вызвать команду sendEvent. Это самый быстрый способ приступить к работе с AEP в Интернете.

Alloy берет на себя всю тяжелую работу

За кулисами сплав автоматически заботится обо всех трех ключевых технических деталях, упомянутых ранее. Он 1️⃣ считывает файлы cookie посетителей и другие файлы cookie AEP, 2️⃣ создает действительный запрос на основе команды sendEvent и отправляет его в конечную точку интерактивного сбора данных (включая файлы cookie). И, наконец, 3️⃣ отображает контент персонализации непосредственно в DOM. Файлы cookie из ответа API также автоматически сохраняются 1️⃣.

плюсы

• самый быстрый способ начать
• бесплатное управление файлами cookie
• Запросы API обрабатываются за вас
• предложения персонализации могут автоматически отображаться в DOM

минусы

• запрос на персонализацию делается в браузере
• добавленная задержка может привести к кратковременному мерцанию страницы
• больший вес страницы за счет включения сплава

Хотите увидеть клиентскую сторону в действии? Ознакомьтесь с этим полнофункциональным образцом приложения.

Серверная реализация

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

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

Читать файлы cookie

Когда страница загружается, на сервер приложений отправляется запрос. Этот запрос включает в себя любые файлы cookie, которые могли быть установлены ранее. Файлы cookie AEP имеют префикс kndctr_ и должны быть прочитаны вашим сервером приложений. Все файлы cookie с таким префиксом важны, но два наиболее важных для этого варианта использования — это kndctr_orgid_identity и kndctr_orgid_cluster. Эти файлы cookie можно проверить с помощью инструментов разработчика вашего браузера.

Запросить персонализацию

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

Вот пример полезной нагрузки запроса, как показано в инструментах разработчика 👆. Обратите внимание, что файлы cookie указаны в мета-разделе полезной нагрузки. Существует также раздел запроса с указанными данными персонализации.

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

Вот пример запроса через curl 👇. Образец запроса в Node.js можно найти здесь.

curl -X POST "https://edge.adobedc.net/ee/v2/interact?dataStreamId={DATASTREAM_ID}"
-H "Content-Type: text/plain"
-d '{
   "event":{
      "xdm":{
         "web":{
            "webPageDetails":{
               "URL":"http://localhost/"
            },
            "webReferrer":{
               "URL":""
            }
         },
         "identityMap":{
            "FPID":[
               {
                  "id":"xyz",
                  "authenticatedState":"ambiguous",
                  "primary":true
               }
            ]
         },
         "timestamp":"2022-06-23T22:21:00.878Z"
      },
      "data":{

      }
   },
   "query":{
      "identity":{
         "fetch":[
            "ECID"
         ]
      },
      "personalization":{
         "schemas":[
            "https://ns.adobe.com/personalization/default-content-item",
            "https://ns.adobe.com/personalization/html-content-item",
            "https://ns.adobe.com/personalization/json-content-item",
            "https://ns.adobe.com/personalization/redirect-item",
            "https://ns.adobe.com/personalization/dom-action"
         ],
         "decisionScopes":[
            "__view__",
            "sample-json-offer"
         ]
      }
   },
   "meta":{
      "state":{
         "domain":"localhost",
         "cookiesEnabled":true,
         "entries":[
            {
               "key":"kndctr_XXX_AdobeOrg_identity",
               "value":"abc123"
            },
            {
               "key":"kndctr_XXX_AdobeOrg_cluster",
               "value":"or2"
            }
         ]
      }
   }
}'

Постоянные файлы cookie

В ответе есть массив хэндлов. Один из дескрипторов имеет тип state:store. Он содержит массив файлов cookie, которые необходимо сохранить.

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

Визуализация персонализированного контента

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

Содержимое персонализации находится в дескрипторе типа personalization:decisions.

Краткое описание серверного подхода

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

плюсы

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

минусы

• ручное управление файлами cookie
• запросы на персонализацию не генерируются автоматически
• содержимое персонализации не отображается автоматически

Хотите увидеть серверную часть в действии? Ознакомьтесь с этим полнофункциональным образцом приложения.

Гибридная реализация

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

Нет мерцания страницы

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

Запросить конфиденциальность

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

Рендеринг на стороне клиента

В гибридном режиме вам не нужно отображать содержимое персонализации на стороне сервера. Это удобно, потому что вам не нужно читать ответ на персонализацию, извлекать детали и создавать HTML с этим содержимым. Вместо этого вы можете просто передать ответ сплаву и позволить ему делать свое дело.

Как работает гибрид

Гибридный режим расширяет реализацию на стороне сервера, описанную ранее. Отличие заключается в том, как отображается контент персонализации.

Так же, как и в серверной реализации, сервер приложений управляет файлами cookie и отправляет запрос на персонализацию. Затем персонализированный ответ предоставляется сплаву на стороне клиента с помощью команды applyResponse.

Секретный ингредиент Hybrid — команда applyResponse

Команда applyResponse аналогична команде sendEvent. Разница в том, что sendEvent создает и отправляет запрос на персонализацию, а затем обновляет DOM. Но applyResponse не отправляет запрос, а принимает объекты responseHeaders и responseBody и обновляет DOM так же, как sendEvent было бы. Это ключ к гибридному режиму, потому что ответ персонализации получается на стороне сервера и предоставляется сплаву с помощью команды applyResponse. Сервер приложений не отображает контент персонализации, но добавляет на страницу небольшой фрагмент кода JavaScript, который вызывает команду applyResponse с ответом персонализации.

alloy("applyResponse", {
  renderDecisions: true,
  responseHeaders: {...},
  responseBody: {...},
});

Это базовая структура команды applyResponse 👆. Alloy автоматически применит персонализацию к модели DOM, поскольку для renderDecisions установлено значение true. Вы также можете добавить в команду предложение .then и обработать ответ по своему усмотрению (так же, как вы можете это сделать с помощью sendEvent).

плюсы

• высокая эффективность от запроса до рендера
• нулевое мерцание страницы
• максимальная конфиденциальность данных
• предложения персонализации могут автоматически отображаться в DOM
• не может быть заблокирован

минусы

• ручное управление файлами cookie
• запросы на персонализацию не генерируются автоматически
• больший вес страницы за счет включения сплава

Хотите увидеть гибридный режим в действии? Ознакомьтесь с этим полнофункциональным образцом приложения.

Следующие шаги

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