Привет!

Я Георгий, бизнес-аналитик в компании Crystal Service Integration (CSI). Наша компания занимается разработкой и внедрением кассовых решений в сетевых магазинах по всей России и за ее пределами.

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

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

Предыстория

Практически все ритейлеры, которые выходят за рамки схемы “привези товар - положи на полку - продай через кассу”, задумываются о том, как повысить эффективность бизнеса через работу со своими покупателями. Их задача привлечь к себе клиентов в том числе за счет более привлекательных предложений. 

Тут на помощь приходит программа лояльности - система предоставления преференций покупателям за выполнение каких-то условий при приобретении товаров:

• возьми 3 шоколадки и получи 4-ю бесплатно!

• успей купить до конца недели арбуз по специальной цене!

• купи набор “обои + клей” и получи скидку на чек 10%!

• копи бонусы с каждого чека и трать их на следующие покупки!

• соверши покупку на 5000 и получи купон на бесплатную жвачку!

• ….десятки других механик, о которых и так много написано. 

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

Для нас, как вендора системы лояльности, это тоже хорошо ???? Потому что ритейлерам теперь требуется не просто инструмент предоставления скидок всем подряд, а возможность более тонкого взаимодействия со своей покупательской базой.

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

Сегментация покупателей и внедрение ClickHouse

Подобная потребность вызвала необходимость пересмотреть способы хранения и обработки данных. Ранее мы хранили информацию о покупателях только в транзакционном хранилище (Postgres). Такое решение отлично подходит для точечной работы с конкретными покупателями. Но перед нами стояла задача быстро (за секунды) отобрать определенную часть покупательской базы среди миллионов профилей. Критерии отбора разнообразные:

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

• блок критериев по истории покупок: тут маркетолог может отобрать тех, например, у кого средний чек за период в диапазоне от 2000 до 3000; кто приобрел определенные товары заданное количество раз; кто совершил свою последнюю покупку до начала текущего года и многое другое.

Важно, что все эти критерии могут быть по-разному скомбинированы. В результате нужно, например, сформировать аудиторию покупателей в возрасте от 35 до 40 лет, которые купили за прошедшие 180 дней определенный гель для душа более 1 раза, но НЕ купили за этот период определенный шампунь. 

Решение подобной задачи потребовало использования отдельного аналитического хранилища. Выбор пал на колоночную СУБД Clickhouse. Ответственный за транспорт данных - KAFKA (что это и как используется написал в своей статье другой мой коллега, тоже Игорь, системный архитектор).

Эта связка позволила обеспечить доставку данных с сотен касс через транзакционное хранилище в аналитическое в режиме онлайн. Через 1-3 минуты после регистрации, новый покупатель уже оказывается в ClickHouse; столько же времени нужно на то, чтобы доставить чек с кассы.

Помимо данных с касс, по KAFKA также доставляются другие данные:

• по покупателям (при регистрации нового покупателя, либо при внесении изменений в его анкету)

• по сегментам покупателей

• по накоплениям покупателей

• по акциям

• по купонным механикам

• по бонусным транзакциям

• ….

Ниже показан ландшафт системы, который у нас получился, с основными ее элементами (Set Centrum / Set Retail - это кассовая часть)

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

• кассовые акции. Это выгода, которая предоставляется покупателю в момент совершения покупки на кассе или в онлайн канале (примеры таких акции приведены ранее).

• стимулирующие акции. Это вознаграждение покупателя по определенному триггеру. Например, за вхождение покупателя в сегмент “Самые активные”, ему начисляются бонусные баллы.

• коммуникации (рассылка сообщений по разным каналам связи на определенную аудиторию покупателей)

Модуль аналитики

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

Получить однозначный ответ на эти вопросы сложно, но судить можно по косвенным показателям. Нужно только эти показатели рассчитать и визуализировать.

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

Подготовили макеты - ниже пример одного из дашбордов.

На этом этапе встал вопрос о том, как разрабатывать этот и другие дашборды? Путь, к которому мы привыкли, подразумевал: формализацию требований → разбор с командой разработки → разработку → тестирование → приемку → внедрение. Но данный случай усложнялся тем, что на стороне front-end предстояла очень большая работа с визуализацией, и все разработчики должны были быть глубоко погружены в бизнес домен, чтобы четко понимать, какие именно показатели от них ожидаются. Задумались об альтернативе, когда за визуализацию данных отвечает готовый внешний продукт, интегрированный в нашу систему.

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

Оба подхода ожидаемо имели как плюсы, так и минусы. Приведу нашу таблицу сравнения:

Наш выбор пал на использование готового продукта. Выбор подходящего вынудил провести исследование имевшихся на рынке вариантов (1 квартал 2023):

Исходя из наших продуктовых запросов решили остановиться на Apache Superset. 

Начался этап проектирования и встраивания Superset в наш ландшафт. Результатом стала вот такая архитектура:

Есть и более подробная архитектурная схема. Пишите, если кому интересно.

По результату внедрения в продукте Set Loyalty появилась возможность создания аналитических дашбордов, позволяющих оценить результаты запущенных механик, коммерческие показатели и другую информацию. За этот этап отвечает уже не разработчик/архитектор, а аналитик. Шаги по достижению цели:

• понять бизнес задачу, которую должны помочь решить график/диаграмма/таблица/показатель

• проверить достаточность информации в аналитической базе данных

• сформировать запрос к данным

• построить по ним нужный элемент визуализации

• кастомизировать элемент по необходимости

• проверить корректность и наглядность полученных данных

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

Остановимся поподробнее на создании графика на простом примере: График по среднему чеку.

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

Для его создания понадобилось:

1. В штатном редакторе SQL запросов в Apache Superset составить запрос к БД, который выводил бы результат простого расчета (сумма чеков на продажу - сумма чеков на возврат) / количество чеков на продажу.

2. Указать динамические фильтры с использованием шаблонизации Jinja. Это позволило накладывать условия из выбранных фильтров на дашборде.

3. На основе полученного запроса (датасета) построить график в соответствующем редакторе Apache Superset.

4. Разместить график на дашборде.

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

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

1. Идем в редактор запросов и добавляем несколько строк кода 

2. В редакторе графика обновляем состав показателей 

Готово. Даже, если редактирование запроса требует какого-то времени, оно явно меньше, чем если бы нам пришлось идти по пути привлечения разработчиков. Продемонстрировать изменения и проверить гипотезу можно в течение дня. 

Открыв доступ к модулю нескольким клиентам мы собрали обратную связь и оперативно внесли корректировки. 

Для маркетологов открылись широкие возможности по оценке результатов работы системы лояльности.

Выбрав интересующую акцию и исследуемый сегмент покупателей, маркетолог теперь может посмотреть, а как изменилась активность покупателей, например, после запущенной рассылки? Или, какое количество бонусных баллов выдано тому или иному сегменту в определенных магазинах? Какой оборот в деньгах был по клиентской базе на фоне всего оборота сети?

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

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

2. повышение потребления ресурсов не должно быть больше 15%.

Говоря коротко, эти требования выполнены. Например, рассмотренный ранее график по среднему чеку (по анонимным и идентифицированным покупателям) за последние 4 месяца рассчитывается за 3 секунды. Количество чеков около 15 миллионов за этот период.

Заключение

Стоит упомянуть о том, что у реализации нашего модуля Аналитики есть и свои нюансы:

• если в Superset что-то не настраивается так, как требуется, то “допилить” его довольно проблематично. По крайней мере пока у нас небольшой опыт в этом направлении.

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

• требуются прокаченные навыки в работе с SQL в ClickHouse. Причем эти навыки должны быть у аналитика, а не разработчика.

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