В моей статье Tealium iQ и Adobe Client Data Layer я примерно определил термин уровень данных следующим образом:

Уровень данных – это объект JavaScript с набором пар "ключ:значение". На объект ссылаются при построении аналитики и маяков/запросов martech, что снижает потребность в очистке содержимого страницы, файлов cookie или других уязвимых источников данных. Этот доступный, предсказуемый, центральный источник данных чаще всего создается и заполняется в начале процесса загрузки страницы, часто не меняясь до следующей загрузки страницы.

Я также включил мысли о том, что многие называют «управляемым событиями» уровнем данных или EDDL:

Управляемый событиями уровень данных обычно строится как массив JavaScript, принимая новые значения и информацию по мере того, как данные становятся доступными. Когда данные помещаются в массив, уровень данных обновляется. Этот подход позволяет динамически улучшать и изменять уровень данных на протяжении всего взаимодействия с пользователем. Любой ресурс, наблюдающий за обновлениями, немедленно уведомляется и может действовать (например, // запускать аналитические маяки) или игнорировать событие.

Последующие разговоры привели меня к выводу, что не все уровни данных созданы одинаковыми: существуют статические объекты javascript, массивы и генерируемые события. Существуют пользовательские SDK, API и другие подходы. Каковы различия? Что делает одно статическим, другое управляемым событиями, а третье - комбинацией этих двух? Что делает что-то не уровнем данных или не управляемым событиями?

Типы уровня данных

Статический объект Javascript (оригинальный)

  • Исходный уровень данных был статическим объектом Javascript, как определено в начале этой статьи. Обычно он определяется и заполняется как часть загрузки страницы, без дополнительных обновлений без обновления страницы или события навигации. Любые происходящие обновления будут производиться незаметно, без уведомления страницы об изменении.
  • На мой взгляд, utag_data Tealium подходит под эту категорию. (Кстати, utag_data и utag.data — это не одно и то же. Они сосуществуют и даже дополняют друг друга, но служат разным целям.)
  • Я стараюсь избегать такого подхода, но признаю, что это не всегда возможно. В этих случаях мы вынуждены в значительной степени полагаться на настраиваемые возможности обработки событий в нашей TMS (при условии наличия диспетчера тегов [TMS]). Будь то собственные функции TMS или множество пользовательских JavaScript, статический объект наряжается во что-то более мощное.

Массив Javascript — EDDL (одаренный)

  • Использование собственной возможности массива Javascript .push() позволяет разработать уровень данных, управляемый событиями (EDDL). Некоторые EDDL (например, // ACDL) достаточно интеллектуальны, чтобы сохранять определенные значения по мере их передачи. Другие требуют отправки всей необходимой информации каждый раз, когда происходит обновление. Что особенного в EDDL, так это то, что вы можете подписаться на них. Вы можете отслеживать их изменения и действовать — или нет — как только эти изменения произойдут.
  • Я называю это «одаренным», потому что за свои деньги он обычно справляется со всем, что мне нужно. А с вариантами с открытым исходным кодом, такими как ACDL, я точно знаю, чего ожидать. Помимо реализации действий .push(), для выполнения того, что мне нужно, требуется очень мало пользовательского кода.

Пользовательское генерируемое событие (Забывчивый)

  • В Javascript мы все знакомы с element.addEventListener(). Мы используем это при отслеживании событий кликов, событий наведения мыши, событий прокрутки и т. д. Мы также можем использовать его как часть подхода к пользовательскому уровню данных. Объединение прослушивателя событий с генерированием настраиваемого события — возможно, с именем dataLayerEvent или подобным — позволяет нам немедленно реагировать на появление новой информации.
  • Я называю это «забывчивым», потому что оно само по себе забывчиво. Если вы не создадите пользовательскую логику для сохранения данных, переданных через пользовательское событие, данные будут доступны только при запуске события.
  • Что мне нравится в этом подходе, так это то, что он не зависит ни от поставщика, ни от платформы, и доступен в любой среде, поддерживающей Javascript, без необходимости в дополнительных сторонних библиотеках. Также легко подписаться на события из любого инструмента или сервиса.

Пользовательский SDK/API («Действительно ли это уровень данных?»)

  • Хотя лично я никогда не рассматриваю SDK или API поставщика как уровень данных, недавние разговоры заставили меня передумать. Лучшие примеры здесь относятся к API-интерфейсам Javascript, родным для самых популярных систем управления тегами (TMS). Это работает так, что вы должны запечь вызовы методов, специфичных для поставщика, в свою кодовую базу, вызывая их напрямую. При вызове, как и в случае пользовательского генерируемого события выше, вы передаете полезную нагрузку, содержащую ваш уровень данных. В некоторых случаях это полный слой данных. В других случаях вы передаете улучшения статическому слою данных, который уже находится на странице. Например:
  • Tealium iQ (TiQ) имеет объект utag, который поддерживает utag.link() для отслеживания событий и utag.view() для просмотров страниц. Передача параметра объекта данных с каждым из этих вызовов метода позволяет в реальном времени улучшать уровень данных. Однако улучшения не будут сохраняться после каждого отдельного вызова.
  • В Adobe Launch/Tags есть объект _satellite, который поддерживает _satellite.track(). Подобно событиям TiQ выше, метод принимает параметр уровня данных. Также как и в TiQ, любые улучшения уровня данных изолированы от вызова события.
  • Когда дело доходит до метода SDK/API, я предостерегаю от него. Это работает? Конечно. Стоит ли жестко кодировать ненужный код конкретного поставщика в кодовую базу вашего сайта? Не по моему мнению.

Так много для размышлений — что мне делать?

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

До тех пор мой предпочтительный подход заключается в реализации проверенного EDDL с преимуществами, не зависящими от поставщика, которые не засоряют мою кодовую базу вызовами методов, специфичных для поставщика, и другой логикой. Оттуда я позволяю TMS прослушивать сообщения EDDL и решать, на что реагировать (правила/условия загрузки, срабатывание тегов/маяков и т. д.), а что игнорировать. Этот подход способствует простоте и обеспечивает точность в современных динамических веб-средах.