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

В недавно опубликованной статье CleverData постаралась разгадать, как и почему совершаются спонтанные покупки. Над нашими намерениями круглосуточно работают Customer Data Platforms (CDP) — гибкие платформы накопления данных о пользователях для целей персонализации предложений. Именно поэтому оповещение о скидке на абонемент в спортзал приходит тогда, когда мы вдруг решаем худеть и заказываем доставку диетического питания. Как грамотное применение CDP напрямую влияет на продажи, читайте в нашей новой статье под катом.

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

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

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

Итак, как мы уже определились, основной источник данных для CDP — это сайт компании. В составе продукта CleverData Join имеется Tag Manager позволяющий выполнить настройку сбора данных с сайта, а также менять эти настройки при необходимости.

Разумеется, для того, чтобы собирать данные с сайта, нужно, чтобы сайт мог отправлять данные, а система сбора данных могла их получать и агрегировать на своей стороне. Основное преимущество менеджера тегов состоит в том, что для организации процесса сбора данных вы должны внести изменения на сайте только один раз — в момент внедрения проекта по сбору данных. Всё, что вы должны сделать, — это добавить специальный блок кода (сниппет) на ваш сайт. В дальнейшем этот сниппет никак не меняется. Сниппет вызывает загрузку контейнера из CleverData Join, а в контейнере, в свою очередь, хранится актуальная конфигурация сбора данных на момент загрузки страницы.

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

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

• Переменные. Позволяют задать правила определения значений атрибутов будущего события в тот момент, когда это событие формируется. Вы можете настроить сбор значений из объектов данных сайта (использовать URL, элементы DOM, параметры CSS, параметры Data Layer, глобальные переменные JavaScript), ограничиться простой подстановкой константы (например, для именования события), или, напротив, написать сложную Javascript-функцию, которая вернет необходимое значение. Кроме этого, на платформе имеется коллекция готовых переменных, которые соответствуют наиболее популярным при сборе атрибутам события (например, заголовку и URL страницы, или тексту и ID элемента, по которому произошел клик). Вы можете использовать такие переменные без каких-либо дополнительных действий по настройке.

Давайте посмотрим на очень упрощенный пример того, как это все работает вместе.

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

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

Событие, сформированное на сайте, передается в CleverData Join посредством обычного REST‑запроса на специальный эндпоинт. При использовании Tag Manager вам не нужно заботиться о формате запроса — его формирование производится без участия разработчиков сайта.

Однако API для приёма событий может использоваться и другими способами.

• Через него можно отправлять события из другой системы, которая накапливает сведения о событиях и поддерживает возможности интеграции с внешними системами через REST.
• Можно обогатить данные системы событиями об оффлайн‑активности клиентов, если у вас есть такой набор данных. К примеру, если вы агрегируете данные о покупках клиентов в оффлайн‑канале, и у вас есть информация, идентифицирующая клиента (например, номер карты лояльности), то можно создать скрипт, который выполняет пересылку в API событий из такого набора данных.
• Можно отправить в систему событие вручную с помощью любого REST-клиента.

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

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

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

Данные об индивидуальном событии можно передать в CleverData Join и другим способом — при помощи пикселя. В данном случае пиксель — это заранее сформированная ссылка для перехода. В ссылке также содержатся заранее подготовленные данные в виде параметров запроса (идентификатор пикселя) и ряда utm‑меток. 
Этот механизм сбора данных подходит в том случае, если вам требуется собрать данные из внешнего web‑источника, к исходному коду которого вы не имеете доступ, но, например, имеете баннер на этом внешнем источнике. Пиксель должен быть вызван при клике по баннеру. В момент клика в CleverData Join будет отправлен запрос, содержащий сведения, которые были заданы в ссылке, а затем осуществлен редирект на целевую ссылку.
Другой распространенный пример — возможность отслеживать открытие электронных писем. Код пикселя встраивается в тело письма, и если клиент его открывает — данные поступают в CleverData Join. В этом случае код пикселя встраивается в тело письма, и при переходе по ссылке загружается незаметное изображение минимального размера 1×1 pixel, которое добавляется в письмо. Именно поэтому метод и получил своё название.

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

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

Для пакетной загрузки данных о клиентских профилях в системе также предусмотрены файловые адаптеры. Для их использования достаточно реализовать несколько простых условий.

1. Выполнить разовую или настроить регулярную поставку в файловый менеджер CleverData Join данных, в которые входят идентификаторы и атрибуты клиентского профиля. Это может быть CSV или JSON‑файл. Это может быть и выгрузка из вашей CRM‑системы, включающая в себя все собранные данные по клиентам.
2. Создать экземпляр нужного адаптера и настроить его.
3. Выполнить разовый запуск или настроить периодический запуск.

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

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

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

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

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

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

Сайт компании — один из главных источников сведений о клиентском пути персон, которые взаимодействуют с вашим бизнесом онлайн. Резюмируя написанное ранее, с CleverData Join вы получаете инструментарий автоматизированного сбора данных с помощью Tag Manager о любых событиях, наступление которых вы хотите отслеживать. Кроме сведений о событиях, сбор данных с сайта позволит вам обогатить базу идентификаторов и атрибутов клиента, а также собрать воедино его анонимную и не анонимную активность.
Например, если пользователь предпочитает взаимодействие с сайтом по поиску товаров или подбору предложений без авторизации и входит в свой личный кабинет только в момент заказа товаров, то сведения о том, какими товарами он интересовался до этого момента, не потеряются — другие механизмы платформы позволят построить единый клиентский путь на протяжении всего периода активности за счёт объединения данных по идентификатору cookie. Использование такого рода информации дает обширные возможности п сегментации клиентской базы, так как позволяет оперировать событиями в динамике. Например, отслеживать сегмент по условию прохождения какой‑либо воронки или выбирать клиентов, которые совершили какое‑либо действие несколько раз.
Следует понимать, что при взаимодействии с сайтом можно получить ограниченное количество идентифицирующей информации. Прежде всего, это cookie и логин пользователя. В отдельных случаях можно узнать email и телефон пользователя, если такая информация предполагается к указанию при регистрации, или, например, заполняется клиентом в форме подписки на рассылку.

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

Система почтовой рассылки является ценным источником информации о событиях, связанных с процессом коммуникации с клиентом — отправленных письмах, статусах открытия писем, фактах отписки от каналов массовой коммуникации. Эти сведения могут быть представлены как атрибуты клиентов (статус подписки на канал коммуникации), так и события. Как правило, в качестве основного идентификатора для таких систем используется email, а метод интеграции источника данных выбирается, исходя из возможностей рассыльщика и состава данных.

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

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

Разумеется, в этом случае предусматривается двухсторонняя интеграция — ML‑модель является одновременно и источником данных для обучения модели, и принимающей стороной данных, представляющих собой предиктивные атрибуты профиля. С точки зрения источника данных сервис с моделью генерирует значения атрибутов профиля — вероятности оттока, лучшего из каналов коммуникации и т. п. Для ML‑моделей с периодическим характером запуска и пересчёта предсказаний хорошо подходят пакетные файловые адаптеры, чтобы быстро обновить предсказания по всем профилям, хранимым в CDP. Для других (например, для моделей, предсказывающих товарные позиции, которые могут заинтересовать клиента) важно обеспечить близкую к реальному времени скорость обновления соответствующего атрибута. Поэтому имеет смысл встроить в код сервиса модели вызовы API CleverData Join для обмена данными.

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

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

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

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

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

• Совместно используя данные, полученные в результате обработки последних действий пользователя на сайте, а также данных о предпочтениях, сгенерированных ML‑рекомендательной системой, отобразить в профиле клиента его товарные предпочтения. С помощью доступа к данным профиля через API можно настроить персонализацию меню интернет‑магазина и виджет товарных рекомендаций.
• Используя сведения о выдаче промокодов из шины данных компании и идентификаторы клиента в email‑рассыльщике, передать сегмент клиентов, которые достаточно давно получили промокод, но не использовали его для организации массовой рассылки.
• Анализируя в реальном времени поток событий, вычислять факт брошенной корзины на сайте и пересылать такие сведения сразу же в систему рассылки для инициации немедленной триггерной коммуникации.

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