Как часто вы совершаете спонтанные покупки или, увидев неожиданное приятное предложение от банка, соглашаетесь на кредитную карту (а ведь еще недавно погасили задолженность и зарекались не брать новую)? Финансовая организация точно рассчитала время, когда предложить вам кредитку. Кажется, это всего лишь совпадение: оффер от банка совпал с поломкой вашего автомобиля и покупкой дорогостоящих деталей. Но поспешим вас огорчить, а если вы маркетолог, то, наоборот, порадовать. Перед нами лишь результат глубокого анализа данных. Как это работает на практике, в новой статье CleverData под катом. 

Продолжая пример, заметим, что вышеупомянутая финансовая организация, вероятно, использует  Customer Data Platform (CDP) – гибкую платформу накопления данных о пользователях для целей персонализации. Она анализирует историческое поведение каждого клиента в интернете (на сайтах, в социальных сетях, на видеохостингах)  для накопления массива данных, с помощью которых можно уже делать персональные рекомендации и целевые акции, предлагать эксклюзивные подборки товаров в офлайн- и онлайн-магазинах или других услуг.

Здесь всплывает главный вопрос, как банк мог узнать, что у его клиента сломалась машина, а уж тем более о покупке деталей, требующихся для ремонта. Все просто. CDP может накапливать данные, не только доступные конкретной компании, но и обогащать их информацией от других поставщиков (страховых компаний, автоцентров или продовольственного ритейла). Эти сведения доступны на бирже данных. Биржи можно сравнить с маркетплейсами: есть поставщики данных, специализирующиеся на сборе данных компании, и потребители (ритейлеры, онлайн-кинотеатры, службы доставки еды и многие другие).

Однако даже при наличии полного портрета клиента/покупателя кажется, что система не сможет так быстро проанализировать все данные и за доли секунды выдать нужную рекламу. Действительно, чтобы реализовать подобную динамику, понадобятся продвинутые CDP-системы enterprise-уровня. Они способны заранее обрабатывать данные из нескольких источников, включающие любые наборы атрибутов пользователя (данные, используемые для идентификации человека - cookie, email, номер телефона), формировать на их основе real-time-сегменты и быстро отдавать их через API веб-сайту компании. 

Продолжим углубляться в вопрос. Рассмотрим, как  по вышеупомянутым идентификаторам происходит формирование единого профиля клиента на примере работы CDP-платформы CleverData Join. 

Роль идентификаторов

Итак, в каждой системе или канале коммуникации имеются данные, которые используются для идентификации человека. К ним можно отнести логин клиента, CRM ID, IDFA- и GAID-идентификаторы мобильных устройств, cookie, email, номер телефона. Платформа CleverData Join позволяет обрабатывать и сохранять произвольное количество идентификаторов профиля разных типов. 

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

• У анонимного веб-трафика и трафика авторизованных клиентов есть общий идентификатор профиля - cookie. Такие данные имеют потенциал к объединению.

• У трафика авторизованных клиентов и сведений из системы мобильной аналитики, вероятнее всего, есть общий идентификатор профиля - логин. Такие данные тоже могут быть объединены.

• У веб-трафика и сведений из CRM может быть общий идентификатор профиля - email. Такие данные также могут быть объединены.

Таким образом данные из разных источников будут сведены в единый профиль и историю событий. Здесь снова предложим подробнее погрузиться в суть. Так вот технически этот процесс становится реализуем благодаря такому инструменту CleverData Join как IDGraph. Если в результате накопления сведений о клиентах обнаруживаются одинаковые идентификаторы, то IDGraph проводит слияние их профилей, что позволяет создавать более точную картину клиентского пути.

Принцип работы IDGraph

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

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

• Найден профиль, среди идентификаторов которого есть один или несколько из тех, которые пришли с событием. Мы уже знаем этого посетителя. Возможно, это не первый его визит на сайт или же необходимые идентификаторы мы получили ранее из других источников. В этом случае произойдёт взаимный обмен идентификаторами - существующий профиль обогатится до этого неизвестными идентификаторами клиента, а в событие будут записаны все идентификаторы, которые имелись в IDGraph.

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

Настройки IDGraph

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

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

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

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

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

Пример использования IDGraph

Узнать больше о применении IDGraph, можно рассмотрев процессы объединения данных для финансовой организации. Предположим, у нашей воображаемой компании есть несколько способов общения с потенциальными клиентами:

• информационный сайт, содержащий информацию о финансовых продуктах,

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

• мобильное приложение клиента, подключенное к системе мобильной аналитики,

• CRM-система.

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

Действие Алексея №1 

Он интересуется условиями разных кредитов и заходит на сайт финансовой организации без авторизации. 

Действие системы №1

При поступлении первых событий с сайта (собираемых посредством кода, размещенного на сайте через СleverData Tag Manager) в системе создается новый профиль А, у которого пока есть только один идентификатор - cookie, хранимый в браузере, через который произошел вход. Все события привязаны к этому профилю.

Действие Алексея №2

Заинтересовавшись условиями кредита, Алексей обращается в организацию - в отделение банка за получением финансового продукта. 

Действие системы №2

Профиль Алексея создаётся в CRM-системе, а Алексей получает логин и пароль от личного кабинета. В следующую выгрузку, регулярно осуществляемую из CRM и импортируемую в CleverData Join, попадут логин Алексея, email и телефонный номер. После обработки очередной выгрузки в системе появится новый профиль Б с этими значениями идентификаторов. При этом никакой связи профилей А и Б пока что нет - CRM-система не знает ничего о cookie браузера Алексея.

Действие Алексея №3

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

Действие системы №3

Система фиксирует событие, содержащее и идентификатор cookie, и логин. IDGraph производит анализ такого события и устанавливает, что профили необходимо объединить по совпадению Cookie, и склеивает профили A и B. После этих действий мы имеем единый профиль пользователя, собранный по данным из трёх систем, и единую историю событий - все действия Алексея во всех этих системах. Это дает возможность финансовой организации начать диалог с Алексеем в разных системах и сравнить, как он реагировал на эти взаимодействия - переходил по ссылкам, открывал письма, интересовался персонализированным предложением на сайте или в мобильном приложении. 

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

Появились вопросы или у вас есть альтернативный опыт использования CDP-платформ? Будем рады обсудить их в комментариях под статьей.  

Хотите узнать больше о работе IDGraph - пройдите регистрацию, и вы получите полную версию материала, в котором мы:

• рассказываем о типах идентификаторов, обрабатываемых CleverData Join,

• рассматриваем на разных примерах особенности обработки потоковых и пакетных данных в системе,

• подробно описываем варианты конфигурирования ID Graph.

Запросить полную версию статьи