Не магия: как агрегируются и обрабатываются данные CDP-платформами

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

О сборе сведений из разных источников CDP‑платформами расскажем на примере CleverData Join. Рассмотрим системы, из которых можно собирать данные, и коснемся главного вопроса — какие задачи можно решать при помощи CDP после успешной настройки загрузки данных в систему.

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

Представим следующую ситуацию. Мужчина, постоянный клиент сервисного автоцентра, забирает машину после успешно пройденного техобслуживания, после чего неожиданно для себя получает сообщение: «Пройдите техобслуживание вашего автомобиля со скидкой в 20% в течение двух недель». Однако осмотр машины уже совершен, и никакой скидки он не получил. Очевидно, что благое намерение маркетологов напомнить об автоцентре постоянному клиенту, вызывает у него лишь гнев и раздражение. Ведь новое посещение сервисного центра в ближайшем будущем точно не предвидится. А случилось это потому, что CDP компании не синхронизирована с CRM‑системой, где хранится информация о прошлых и будущих визитах клиентов. Заметим, что помимо CRM у каждой организации есть и много других путей повышения качества сведений о своих покупателях. Например, можно предоставить CDP возможность сбора информации из всех систем, к администрированию которых имеется доступ.

Но не будем забегать вперед и рассмотрим весь процесс сбора данных поэтапно.

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

В CleverData Join нет жестко заданной типизации видов событий и формата событий — вы вольны собирать любые данные, какие захотите. Эта гибкость достигается за счет наличия трех видов сущностей, с помощью которых настраивается сбор данных:

Давайте посмотрим на очень упрощенный пример того, как это все работает вместе.
1) Пользователь загружает одну из страниц интернет-магазина. В этот момент вместе со страницей загружается и контейнер, который содержит настройки сбора событий в CleverData Join.
2) Сразу после загрузки срабатывает триггер на загрузку страницы. Приводится в действие привязанный к этому триггеру тег, заставляющий собрать и отправить событие, содержащее cookie пользователя в качестве идентификатора, URL и заголовок страницы в качестве атрибутов и константу, определяющую тип события (например, PageLoad).

3) Пользователь нажимает на иконку «Нравится» в карточке товара. Срабатывает триггер на клик по такому элементу, срабатывает привязанный тег. На этот раз он отправляет в систему в дополнение к URL и заголовку страницы ещё и идентификатор товара.

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

Структура данных тела запроса унифицирована и состоит из трех блоков:

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

В каждом из блоков можно передать словарь, где ключами являются номера элементов таксономии, а значениями — значения идентификаторов или атрибутов.

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

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

Другой распространенный пример — возможность отслеживать открытие электронных писем. Код пикселя встраивается в тело письма, и если клиент его открывает — данные поступают в CleverData Join. В этом случае код пикселя встраивается в тело письма, и при переходе по ссылке загружается незаметное изображение минимального размера 1×1 pixel, которое добавляется в письмо. Именно поэтому метод и получил своё название.

Резюмируя, этот метод сбора данных следует использовать:

• если требуется собрать информацию в момент рендеринга HTML‑содержимого в системе‑источнике;
• если в системе источника невозможно разместить сниппет, который выполняет сбор данных через Tag Manager — например, требуется собирать события перехода по рекламному баннеру, размещенному на внешнем сайте.

Настройки адаптера и требования ко входным данным различаются.

• Для адаптера CSV to Client Profile данные должны быть представлены в виде CSV с произвольным разделителем, заголовок может присутствовать или отсутствовать. То есть подойдёт выгрузка из вашей системы в практически произвольном формате. На этапе настройки адаптера вам нужно будет произвести сопоставление колонок набора данных и идентификаторов/атрибутов профиля. После запуска такого адаптера сведения из всех строк CSV‑файла будут подгружены в систему для обогащения сведений о ваших клиентах. Если требуется периодическое обновление, важно убедиться, что порядок колонок в выгрузке не будет изменяться.

• Для адаптера JSON to Client Profile требования к данным строже: на вход подаются многострочные файлы в формате JSON, в строках которого содержатся блоки с массивами данных о номерах идентификаторов и атрибутов в CleverData Join, и о значениях, которые соответствуют этим идентификаторам и атрибутам. Несмотря на то, что такой формат выгрузки может быть сложнее получить при экспорте из системы периметра, он предоставляет гибкость в части набора идентификаторов и атрибутов для каждого профиля. Также вы можете определить стратегию слияния данных — обогащать существующие сведения о профиле, или замещать существующие сведения целиком.

Вы можете автоматизировать загрузку файлов в File Manager с использованием API или периодически загружать свежие файлы импорта в ручном режиме.

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

Теперь перейдем непосредственно к примерам систем, из которых можно организовать поставку данных в CleverData Join.

Например, если пользователь предпочитает взаимодействие с сайтом по поиску товаров или подбору предложений без авторизации и входит в свой личный кабинет только в момент заказа товаров, то сведения о том, какими товарами он интересовался до этого момента, не потеряются — другие механизмы платформы позволят построить единый клиентский путь на протяжении всего периода активности за счёт объединения данных по идентификатору cookie. Использование такого рода информации дает обширные возможности п сегментации клиентской базы, так как позволяет оперировать событиями в динамике. Например, отслеживать сегмент по условию прохождения какой‑либо воронки или выбирать клиентов, которые совершили какое‑либо действие несколько раз.

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

• Благодаря тому, что в системе есть данные о событиях, которые клиент осуществлял на сайте, и сведениям загруженным из CRM, можно построить сегмент клиентов, которые, к примеру, отвечают всем следующим критериям:
• прошли путь через несколько страниц сайта до формы заказа товара, добавили товар (к примеру, дорогой смартфон) в корзину;
• не совершили при этом покупку;
• провели достаточно долгое время на странице «корзина»
• пользовались при этом браузером Safari;
• по данным CRM, возраст покупателей составляет 25–40 лет;
• по данным CRM, уже осуществляли покупки.

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