Сегментация в CDP CleverData Join

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

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

В контексте сегментации важно, что выбирать профили по значениям атрибутов первого датасета - сведений о профилях - кажется достаточно тривиальной задачей. Однако, массив сведений о событиях также может дать огромное количество информации для определения сегментов. Но воспользоваться ей будет не так-то просто, так как атрибуты события могут существовать вне контекста профиля, но являться характеристикой именно события. Например, легко представить себе ситуацию, что в атрибут профиля передаются сведения об общей сумме покупок за месяц, и наиболее интересующих клиента категориях товаров. Логично, что собрать сегмент клиентов с суммой покупок больше определённого значения - довольно просто, равно как и сегмент интересующихся определённой категорией товаров. А вот построить сегмент клиентов, который часто заходит в карточки товаров определённой категории, при этом имеет низкую или нулевую стоимость покупок в этой категории - может быть нетривиальной задачей. Тем не менее за этой ситуацией и этим сегментом есть определённый паттерн - таким клиентам очень интересна товарная категория, при этом что-то останавливает их от покупки. Может быть, удастся переломить эту ситуацию точечной рекламной кампанией по этому сегменту, или рассылкой с предложением использовать промокод на эту категорию товаров? CleverData Join поможет собрать такую аудиторию с помощью своих механизмов сложной сегментации.

В CleverData Join реализовано несколько механик сегментации, пригодных для использования в различных ситуациях.

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

Результат построения такого сегмента может быть, например, выгружен в рекламный кабинет, или - сохранён в виде файла данных в файловый менеджер системы или на внешнее FTP-хранилище. Это позволит использовать построенный сегмент в интегрируемых решениях.
Учитывая вычислительную сложность задачи одновременного перестроения большого количества сегментов, в системе может быть задан параметр максимальной глубины сегментации. Этот параметр определяется совместно с клиентом в зависимости от сложности решаемых задач. При этом, если требуется решение задач по клиентам с длинным жизненным циклом - этот параметр может быть выставлен в нелимитированное значение, что позволит оперировать всей историей событий клиентов. Более того, имеется возможность настройки индивидуальной глубины сегментации для каждого источника событий, если, к примеру, есть потребность в экономии ресурсов по одному источнику, а из второго источника собираются важные сведения, имеющие ценность на длинном историческом периоде.

RT-сегментация
Этот вид сегментации используется, в свою очередь, в real-time взаимодействиях. Он работает следующим образом - формируется условие сегментации, включающее в себя блок условий по событиям. После каждого нового события, поступающего в CleverData Join, проверяется срабатывание всего условия целиком для профиля, по которому пришло событие, в ограниченном временном окне. Эта механика позволяет отслеживать наступление определенной последовательности событий, и немедленно доставить данные о факте вхождения клиента в сегмент - в модуль оперативного профиля или в другое назначение, например - шину Kafka внешней интегрируемой системы. 
Эта механика позволяет организовывать такие виды взаимодействий, как подстройка контента или коммуникация посредством триггерного сообщения.

SQL-like сегментация
В редких случаях возможностей встроенного языка сегментации не хватает для построения сегмента по бизнес-условию, которое включает в себя многоуровневую агрегацию или, например, подсчёт оконной функции. Это происходит по той простой причине, что встроенные механизмы сегментации агрегируют данные по событиям исключительно в контексте клиента. Если вы столкнулись с задачей такого рода - то можно справиться и с ней с помощью функционала SQL-like сегментации по событиям. Метод заключается в запросе к данным в хранилище событий с помощью синтаксиса SQL, допускающим применение любых функций языка. 
В данный момент этот функционал доступен в beta-версии и используется через запрос в техподдержку.

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

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

• Данных о посещении страниц сайта с предложениями,
• CRM,
• ML-модели, прогнозирующей вероятность успешной продажи продуктов данного класса.

Аудиторией, релевантной для данной задачи, станет группа клиентов:

• Уже побывавших на страницах с указанными услугами, но не сделавшими заказ,
• ИЛИ пользователи, для которых ML-модель спрогнозировала высокую вероятность продажи.
• при этом нам НЕ интересны текущие клиенты, или потенциальные с кредитным рейтингом менее 700.
• Кроме того, мы хотим сузить аудиторию до пользователей MacOS в возрасте от 18 до 40 лет.

Если мы располагаем всеми этими данными, построить правило сегментации становится очень простой задачей: визуальный конструктор поможет выбрать атрибуты таксономии, по которым мы строим условия, а интуитивно понятный интерфейс поможет не запутаться в логических операциях И/ИЛИ, формализовав описание сегмента в терминах, очевидных для восприятия. Вот, например, как может выглядеть такой сегмент в CleverData Join:

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

• В системе зарегистрированы события session_5m, собираемые в случае длинной сессии работы с сайтом,
• Клиент заходил на одну из страниц с предложениями, с которых собираются события с названием "interest_...",
• Клиент НЕ выполнял формирование заявки, то есть по нему отсутствует событие "request_...",
• Совокупное логическое условие достоверно на горизонте последней недели.

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

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

Как можно заметить, инструмент обладает достаточной гибкостью для формирования огромного множества вариантов условий. 
Такого рода условия можно использовать как вместе с классической, так и с RT-сегментацией - разве что во втором случае временное окно просмотра событий будет меньшего размера.

Сегментация по потоку событий не так проста, как кажется на первый взгляд. Здесь условий И/ИЛИ/НЕ, доступных для одиночных событий, зачастую бывает недостаточно. Однако, у правил сегментации есть несколько тузов в рукаве:

Для хранения условий сегментов в системе нам пришлось создать собственный язык запросов, DMPQL, учитывающий особенности хранения данных в платформе и позволяющий формализовывать условия сегментации в коде. Разумеется, для любого выражения, созданного в point'n'click-редакторе сегментов, вы можете получить аналогичное выражение DMPQL, чтобы, например, скопировать его части в другой сегмент или поделиться с коллегами. Но, непосредственное использование языка запросов позволяет получить дополнительные возможности сегментации. Среди этих возможностей:

• Поддержка большего количества агрегирующих функций для агрегации атрибутов событий. Например - функции, которая вычисляет среднее значение по атрибутам событий, попадающих под условие сегментации. С агрегацией такого типа вы сможете, например, построить сегмент клиентов со средней оценкой купленных товаров < 4 баллов за последний месяц.
• Использование арифметических операций и выражений. Вы можете с лёгкостью найти, например, произведение двух атрибутов, или результат пересчёта значения по формуле, использующей числовые константы, перед тем, как проверять значение по условию сравнения. Это может быть полезным, например, если вы хотите построить сегмент по стоимости покупок, но храните покупки в двух измерениях - по стоимости одной единицы изделия, и по количеству изделий.
• Контроль значений даты и времени в атрибутах. Например, если вы хотите для одного из событий правил сегментации установить более узкие временные рамки, нежели основное окно сегментации - это посильная задача. Это даст вам возможность, к примеру, найти аудиторию с суммой стоимостей покупок за последний месяц выше какого то лимита, которые, при этом оставили жалобу в форме обратной связи за последние три дня - тогда, когда сайт работал нестабильно. И адресно повысить лояльность столь ценных для вас клиентов.
• Логическое отрицание и отрицание равенства. Все одиночные правила выборки в UI сформулированы в положительном ключе - значения могут быть равны чему-то, содержать подстроку и так далее. Операции отрицания реализуются через сужение области просмотра. Тем не менее, если проще сразу выстроить условие через "не равно" или "не содержит", можно сделать это в DMPQL.
• Вхождение в список значений. Позволяет проверять наличие значения атрибута в заранее определенном словаре значений. Это позволит отфильтровать клиентов, которые совершали покупки определенных позиций, например - для предложения участия их в бонусной программе.

Функционал встроенного языка запросов гармонично дополняет и расширяет функции графического редактора сегментов. Разумеется, все возможности языка применимы как для классической, так и для RT-сегментации.

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

Именно для этого мы разработали оператор RT-сегментации, который позволяет зарегистрировать событие входа в воронку ожидаемых действий, и установить значение таймера. Если событие выхода из воронки произойдёт - таймер будет сброшен, и RT-сегментация не произойдёт. Если же таймер достигнет нуля, а целевое событие так и не произойдёт, то профиль попадёт в RT-сегмент, и сможет быть доставлен адаптером, к примеру, в модуль оперативного профиля (в виде отметки принадлежности к этому сегменту), или в топик Kafka системы, которая занимается отправкой адресных коммуникаций. Таким образом, задача брошенной корзины будет решена. 

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

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

В качестве примера, рассмотрим следующую ситуацию:

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

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

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

Мы можем решить и такую задачу. Её решение сводится к агрегации событий, связанных с промокодом, по значению промокода. Для каждого значения нужно получить последний статус промокода, и, если есть хотя бы один конечный статус "выдан" - это и станет критерием вхождения в сегмент. Такая задача требует SQL-like подхода к работе с данными событий, и мы готовы предоставить возможность составления такого рода сегментов при помощи механики SQL-like сегментации, описанной выше. Мы выполняем построение таких сегментов по запросу под конкретную задачу.

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

• Возможность обращения к любым атрибутам профиля, доступным в хранилище, а также к атрибутам потока событий,
• Комплексность реализации логических операторов И/ИЛИ/НЕ,
• Механизмы агрегации событий и определения последовательности событий,
• Арифметические операции в синтаксисе сегментации,
• Продвинутая работа с датами,
• Быстрая RT-сегментация для анализа потока событий в реальном времени,
• SQL-like сегментация для более сложных кейсов агрегации данных,
• Гибкая настройка глубины сегментации для каждого источника данных.

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