Авторы: Аарон Харди, Джо Хури, Джастин Гровер и Дженни Медейрос.
В этой статье рассказывается, как Adobe Experience Platform и Adobe Experience Cloud упрощают вашу реализацию с помощью универсальной библиотеки JS, Adobe Experience Platform Web SDK.
В настоящее время клиентам Adobe Experience Platform необходимо реализовать несколько библиотек JavaScript на своих веб-сайтах для взаимодействия с сервисами в Adobe Experience Cloud. Каждая библиотека имеет свою собственную документацию и должна реализовываться индивидуально, что приводит к сложному рабочему процессу.
В соответствии с миссией Adobe по продвижению наших клиентов вперед с помощью инновационных инструментов и услуг, Adobe Experience Platform Web SDK представляет собой унифицированное решение, предназначенное для значительного упрощения усилий наших клиентов по внедрению. Он предоставляет единую конечную точку для оптимизации HTTP-запросов к решениям Adobe, предоставляя клиентам Adobe Experience Platform более производительный веб-сайт и улучшенную видимость их рабочего процесса.
В этом посте дается обзор веб-SDK Adobe Experience Platform, нашего архитектурного подхода, его сравнения с текущим рабочим процессом и дальнейших шагов в этой замечательной библиотеке.
Оптимизация внедрения нашими клиентами с помощью унифицированного веб-SDK
Adobe Experience Platform Web SDK (название проекта: Alloy) позволяет клиентам взаимодействовать с различными возможностями в Adobe Experience Cloud для потоковой передачи данных в Adobe Experience Platform, который синхронизирует удостоверения, персонализирует контент, автоматически отслеживает ссылки, и отправлять сегменты аудитории сторонним адресатам.
В настоящее время клиенты Adobe Experience Cloud, реализующие Adobe Cloud Identity Service (ECID), Adobe Analytics, Adobe Target и Adobe Audience Manager, должны загрузить и установить следующие четыре библиотеки в Adobe Experience Cloud:
- Visitor.js
- AppMeasurement.js
- AT.js
- DIL.js
Они также должны прочитать отдельную документацию по каждой библиотеке, чтобы понять, как их следует использовать и как они интегрируются друг с другом. Adobe Experience Platform Launch упрощает этот процесс установки, но заказчик по-прежнему должен настроить четыре разных расширения.
В текущей реализации каждая библиотека отправляет вызов сервера отдельной конечной точке до того, как данные достигнут решений Adobe Experience Cloud.
Adobe Experience Platform Web SDK упрощает этот рабочий процесс. Клиентам нужно будет реализовать только одно расширение Adobe Experience Platform Launch, чтобы получать ECID, получать и отображать персонализированные впечатления, обновлять аудитории и передавать данные в озеро данных - и все это за один вызов. Клиенты, не использующие Adobe Experience Platform Launch, смогут реализовать те же функции, установив единую библиотеку на своем веб-сайте.
В этом новом рабочем процессе веб-сайт клиента делает меньше запросов к серверу и хранит меньше файлов cookie. Это преимущество в сочетании со значительно уменьшенным размером кода библиотеки приводит к общему повышению производительности. Кроме того, имея только одну библиотеку на своем веб-сайте, клиенты могут лучше понять их реализацию и быть более уверенными в своих данных.
Наш подход к созданию веб-SDK Adobe Experience Platform
Чтобы создать единый SDK для Adobe Experience Platform, нам пришлось объединить разные команды, стоящие за каждым продуктом. Такой подход позволил создать единую целостную кодовую базу, которая повысила стабильность и надежность для наших клиентов.
Мы создали Adobe Experience Platform Web SDK с использованием компонентной архитектуры, в которой код для каждого компонента в значительной степени независим, но позволяет компонентам координироваться друг с другом через надежные точки интеграции. Эта система дает каждой команде возможность работать над своими соответствующими компонентами с минимальным вмешательством в работу других, а также обеспечивает надлежащую межкомпонентную интеграцию для ускорения разработки и снижения общих затрат на обслуживание.
В архитектуре также используется система ловушек жизненного цикла, чтобы каждый компонент мог должным образом инициировать важные системные события и реагировать на них. Например, в случае загрузки веб-сайта новым клиентом рабочий процесс в Adobe Experience Platform Web SDK будет работать следующим образом:
- Когда страница загружается, «сборщик данных» уведомляется о том, что клиент хочет отправить данные о событии.
- Сборщик данных создает полезную нагрузку и запускает ловушку жизненного цикла (onBeforeEvent).
- Каждый компонент получает полезную нагрузку и может увеличить ее. Например, компонент службы идентификации может добавить ECID, полученный из файла cookie.
- Сборщик данных отправляет запрос в одну конечную точку, позволяя выполнять несколько действий (например, заполнять ответ персонализированной информацией), а также собирать данные для решений Adobe Experience Cloud и Adobe Experience Platform.
- Ответ возвращается сборщику данных, вызывая перехватчик жизненного цикла (onResponseReceived), и процесс каждого компонента, увеличивающего полезную нагрузку, повторяется.
Наконец, мы разработали веб-SDK Adobe Experience Platform с учетом конфиденциальности и производительности. По умолчанию он асинхронный, чтобы ускорить загрузку и с самого начала отдает приоритет одностраничным приложениям (SPA). Он также поддерживает рабочие процессы подписки, чтобы уважать предпочтения конфиденциальности конечных пользователей.
Adobe Experience Platform Web SDK быстрее и прозрачнее, чем существующие библиотеки
Adobe Experience Platform Web SDK - это полностью открытый исходный код, который обеспечивает клиентам большую прозрачность и позволяет им проводить собственную проверку безопасности. Кроме того, опубликованные сборки будут предлагаться как в минифицированном, так и в неминифицированном форматах, что позволит клиентам полностью понимать код во время его работы в их среде и улучшить их способность отлаживать проблемы реализации, которые могут возникнуть.
Чтобы продемонстрировать, как Adobe Experience Platform Web SDK сравнивается с текущей реализацией Experience Cloud, рассмотрим тот же сценарий, когда конечный пользователь впервые посещает веб-страницу. В этой демонстрации заказчик реализует Visitor.js, AppMeasurement.js, DIL.js и AT.js; и их страница настроена только на запуск вызова Adobe Analytics. См. Следующее изображение:
Конечный пользователь дал согласие не на все цели обработки данных, за исключением использования основной библиотеки идентификаторов: ECID. Это заставляет веб-страницу назначать конечному пользователю резервный идентификатор. После того, как пользователь соглашается, ECID назначает другой идентификатор, в результате чего конечный пользователь имеет два разных идентификатора. Затем веб-страница выполняет ряд обращений к серверу и генерирует такое же большое количество файлов cookie для получения персонализированной информации из решений Adobe Experience Cloud.
С Adobe Experience Platform Web SDK библиотека ECID не блокирует сбор персональных данных. При использовании асинхронной реализации любые команды, зависящие от настроек конфиденциальности конечного пользователя, помещаются в очередь в памяти в SDK. После того, как конечный пользователь предоставит свои предпочтения через согласие, эти команды будут продолжены или прерваны.
Для выполнения принятых команд Adobe Experience Platform Web SDK запускает одну полезную нагрузку в комплекте с ECID и персонализированной информацией, собранной из Adobe Target и Adobe Audience Manager (см. Изображение ниже). Этот оптимизированный рабочий процесс приводит к меньшему количеству идентификаторов, назначаемых одному и тому же конечному пользователю, и резкому сокращению количества запросов и файлов cookie, отправляемых между веб-страницей и сервером.
Вызовы
Замена нескольких библиотек одним решением создает несколько проблем с конфиденциальностью. Например, если посетитель веб-сайта отказывается от одного решения, трудно выделить это предпочтение, не отказавшись от других, поскольку все библиотеки находятся в одном месте.
Чтобы решить эту проблему, мы пригласили все инженерные группы Adobe Experience Cloud для коллективного обсуждения стандартного решения для отказа. Это решение должно правильно согласовывать предпочтения клиента по отказу от рассылки, не нарушая работу SDK и не нарушая каких-либо проблем с конфиденциальностью.
Еще одна постоянная задача - найти техническое решение для переноса данных, хранящихся на устройствах конечных пользователей. Не все данные будут перенесены автоматически, но мы определили ключевые данные, которые будут перенесены, например идентификаторы посетителей, ранее сохраненные в файлах cookie.
Что дальше?
Хотя мы гордимся нашим прогрессом с Adobe Experience Platform Web SDK, он все еще находится на раннем этапе разработки. В настоящее время мы работаем над развитием функции включения, чтобы обеспечить более детальный контроль над конкретными целями, которые конечный пользователь может принять.
Кроме того, для обеспечения согласованности данных во всех решениях Adobe предстоящая бета-версия Adobe Experience Platform Web SDK будет поддерживать только отправку данных, которые уже были структурированы в соответствии со схемами Adobe Experience Data Model (XDM). Впоследствии мы предоставим клиентам интуитивно понятный пользовательский интерфейс с функцией сопоставления XDM, чтобы гарантировать, что любые данные веб-сайта, не соответствующие схеме XDM, могут быть правильно сопоставлены с ними до того, как они будут достигнуты в Adobe Experience Platform. Эта гибкая схема позволяет клиентам структурировать свои данные так, как они их понимают, а не следовать предписанной структуре.
Поскольку веб-SDK Adobe Experience Platform в настоящее время находится в стадии разработки, мы рады продолжить оптимизацию рабочих процессов наших клиентов и улучшить способы их взаимодействия с Adobe Experience Platform.
Подробное руководство по использованию Adobe Experience Platform Web SDK см. в нашей документации. Чтобы быть в курсе его развития, посетите репозиторий GitHub.
