Совет №33
Использование метрик CRM в качестве поведенческих тегов
Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Давайте опишем простой классический пример присвоения поведенческих
тегов сложным шаблонам микро-транзакций, порождаемых нашими процессами
взаимодействия с клиентами, например, звонками контактного центра,
посещениями веб-сайта, системами доставки, а также платёжными системами.
Мы воспользуемся нашими стандартными методами отчётности для хранилища
данных чтобы просуммировать три метрики, описывающие поведение клиента:
свежесть (recency), частота (frequency), и интенсивность (intensity).
Свежесть – это мера того, как давно мы взаимодействовали с клиентом.
Давайте взглянем широко, и посчитаем все транзакции, порождаемые
процессами взаимодействия с клиентами, упомянутыми выше. Действительное
значение метрики свежести – это количество дней, прошедших с момента
последнего контакта с клиентом.
Подобным образом, частота – это мера того, как часто мы взаимодействовали
с клиентом, опять-таки в широком понимании всех процессов взаимодействия
с клиентом. И, наконец, интенсивность – это числовая величина, характеризующая
то, насколько продуктивным было взаимодействие. Наиболее очевидным
показателем интенсивности является сумма, потраченная на покупки,
но, мы можем думать, что общее количество веб-страниц, которые посетил
клиент – это тоже хороший показатель интенсивности.
Все метрики RFI (recency, frequency, intensity) можно подразделить
на различные метрики для каждого процесса взаимодействия с клиентом,
но мы сохраним этот пример простым.
Теперь посчитаем для каждого клиента их метрики RFI для скользящего
периода времени, такого как последний месяц. В результате получится
три числа. Можно вообразить отображение результатов RFI в виде трёхмерного
куба с осями Recency, Frequency, и Intensity.
Теперь обратимся к нашим коллегам по data mining и попросим их
найти естественные кластеры в этом кубе. В действительности, нам
не нужны все числовые результаты: нам нужны поведенческие кластеры,
которые, которые будут иметь смысл для нашего департамента маркетинга.
После запуска алгоритма кластеризации средства data mining, мы найдём,
например, что существует восемь кластеров клиентов. После изучения
того, в каких местах нашего RFI-куба находятся центроиды кластеров,
мы сможем дать поведенческие описания каждому из восьми поведенческих
кластеров:
A: Высокодоходные постоянные клиенты, хороший кредит, малое количество
возвратов товара
B: Высокодоходные постоянные клиенты, хороший кредит, но большое
количество возвратов товара
C: Новые клиенты, кредитной истории нет
D: Непостоянный клиент, хороший кредит
E: Непостоянный клиент, плохой кредит
F: Бывший хороший клиент, в последнее время не появлялся
G: Любитель часто поглазеть на витрины, в основном, непродуктивный
H: Прочие
Мы можем рассматривать теги от A до H как текстовые факты, суммирующие
поведение клиентов. В хранилищах данных небольшое количество текстовых
фактов, но эти поведенческие теги, похоже, представляют собой хороший
пример. Можно разработать временной ряд поведенческих тегов для
клиента – каждый месяц по одному измерению.
Василий Пупкин: C C C D D A A A B B
Что можно сказать об этом временном ряде? Мы успешно преобразовали
Василия Пупкина из нового клиента в непостоянного клиента, а далее
в очень желательного высокодоходного постоянного клиента. Но в последние
месяцы мы замечаем, что Василий проявляет склонность к возврату
товаров. Это недавнее поведение не только порождает издержки, но
и заставляет нас беспокоиться о том, что Василий может разочароваться
в наших товарах и в конечном счёте попасть в поведенческую категорию
F!
Этот небольшой временной ряд достаточно хорошо открывает нам глаза.
Как же нам структурировать наше хранилище данных, чтобы иметь возможность
выкачивать такие отчёты? И как нам накладывать интересные ограничения
на клиентов, чтобы видеть только тех, которые за последнее время
переместились из кластера A в кластер B?
Мы можем моделировать этот временной ряд текстовых поведенческих
тегов несколькими различными способами. Каждый подход обеспечивает
наличие идентичной информации, но они значительно отличаются по
лёгкости использования. Давайте предположим, что мы генерируем по
одному новому поведенческому тегу ежемесячно для каждого клиента.
Вот эти три способа:
1) Запись в таблице фактов для каждого клиента в каждый месяц,
поведенческий тег моделируется как текстовый факт.
2) Медленно изменяющееся измерение Клиент (Type 2), поведенческий
тег выступает в качестве атрибута (поля). Ежемесячно для каждого
клиента создаётся новая запись в таблице измерения. Такое же количество
новых записей ежемесячно, как и в случае №1.
3) Одна запись о клиенте в таблице измерения с временным рядом
из поведенческих тегов за 24 месяца, хранящимся в 24 атрибутах.
Как способ 1, так и способ 2 имеют проблему, заключающуюся в том,
что каждый новый поведенческий тег для каждого клиента хранится
в различных записях. Несмотря на то, что простой подсчёт будет работать
хорошо в обоих этих случаях, сравнения и ограничения будет делать
трудно. Например, поиск клиентов, перешедших из кластера A в кластер
B в последнем периоде, был бы затруднён в реляционной базе, поскольку
не существует простого способа применить a «ограничение с широко
расставленными ногами» на две записи сразу.
В этом примере на нас сильно влияет предсказуемая периодичность
данных. Каждый клиент профилируется ежемесячно. Поэтому, даже если
поведенческий тег является разновидностью текстового факта, вырисовывается,
что выбор дизайна номер является довольно эффективным. Помещение
временного ряда из поведенческих тегов в каждую запись о клиенте
имеет три больших преимущества. Во-первых, значительно сокращается
количество генерируемых записей, поскольку новый поведенческий тег
сам по себе не генерирует новой записи. Во вторых, сложные ограничения
выполнить достаточно просто, поскольку соответствующие поля находятся
в одной и той же записи. И, в-третьих, мы можем легко ассоциировать
сложные ограничения с нашим полным портфелем клиентских таблиц фактов
посредством простого соединения с таблицей измерения Клиент.
Конечно же, моделирование временного ряда как набора полей измерения
Клиент имеет недостаток в том, что как только у вас закончатся ваши
24 поля, вам, возможно, понадобится изменить таблицу измерения,
чтобы добавить туда новые поля. Но в сегодняшней быстро изменяющейся
среде, вам, возможно, понадобится вносить и другие изменения в это
же самое время! По крайней мере, этот изменение является «элегантным»,
поскольку не влияет на существующие приложения.
Мы преуспели в усушке терабайтов транзакционных поведенческих данных
в простой набор тегов с помощью наших коллег по технологиям data
mining. Далее мы упаковали теги в очень компактный и полезный формат,
который поддерживает наши высокоуровневые цели – лёгкость использования
и лёгкость разработки приложений . Теперь мы готовы выкачивать различные
виды интересного поведенческого анализа для наших конечных пользователей
из подразделения маркетинга.
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS