Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
От автора
Всем привет, я Павел. Из 15 лет отданных ИТ, на протяжении последних 6 лет я работаю в одном из старейших CRM агентств в СНГ на позиции системного архитектора и R&D. Каждый год через меня проходит множество интересных проектов. Некоторые из них добираются до стадии proof of concept, другие закрываются пилотами, третьи стали частью новых компонентов ИТ экосистем или CRM стратегий, идеи которым повезло меньше, остаются на бумаге. В эти непростые для отрасли времена, мне хочется поделиться опытом, рассказать о проектах и подходах, которые смогут вдохновить вас на реализацию новых продуктов и решений.
Введение
Каждый относительно успешный бизнес, связанный с продвижением продуктов или услуг, в определенный момент начинает испытывать неудовлетворенность от соотношения объема вложенных денежных средств к количеству привлеченных потребителей, а также потребность в оптимизации своих расходов, когда их объем становится значимым. Зачастую, поправки в эффективность использования бюджетов, даже при наличии качественной digital- или CRM стратегии, вносят множество незаметных с первого взгляда, но системных факторов, которые касаются организации процессов и распределения рисков. Описанный ниже кейс - яркий тому пример.
Какие проблемы скрывает рынок?
Современный рынок новых автомобилей, который мы наблюдали до 24 февраля 2022 года в России, сложный и каждый из его участников испытывает высокую конкуренцию. В борьбе за клиента импортеры тратят большие бюджеты на маркетинг продукции на уровне макрорегиона. Каждого такого рекламодателя окружает множество подрядчиков (агентств), а бюджеты между ними распределяются вместе с рисками. При этом разнообразие инструментов и технологий, которые применяют агентства так велико, что зачастую прямое взаимодействие между ними может быть затруднено техническими или организационными вопросами (например, агентства не заинтересованы в сотрудничестве будучи потенциальными конкурентами за бюджеты клиента).
Дополнительную сложность для управления CRM и маркетинговыми активностями вносят дилеры, которые ведут деятельность на уровне регионов, юридически являются самостоятельными компаниями, и делятся с импортером только ограниченными сведениями о лидах и проспектах защищая свои коммерческие интересы. Из этого следует, что в глобальном плане автопроизводитель испытывает дефицит знаний об интересах и запросах потенциального клиента.
Учитывая все эти факторы, собрать достаточно информации о потребительских интересах и опыте взаимодействия с брендом до покупки очень сложно. При том что цикл покупки автомобиля в upper-intermediate сегменте по СНГ, на момент проведения проекта, оценивался в 2-3 месяца.
Таким образом CRM агентство живет в условиях высокой неопределенности, в которой его эффективность и достижимость поставленных KPI часто зависит от решений, которые принимают другие компании, инструментов, которые управляются другими специалистами, и решений управленцев, преследующих личные интересы.
Однажды крупный автомобильный бренд поставил нам задачу найти способ повысить конверсию форм лидогенерации, размещенных на сайте, а также pop-up форм, за все это отвечало digital-агентство. Несмотря на большие инвестиции в рекламу и показательно высокий трафик на сайте, KPI по конверсиям в лиды не выполнялись.
Нашей команде предстояло найти проблемные места в пользовательском опыте, а мне разработать архитектуру решения и встроить его в ИТ ландшафт клиента.
Проблемы и гипотезы
Постараюсь тезисно привести факты и гипотезы, с которыми нам пришлось работать.
Вводные:
Дано кольцо сайтов не размещенных на единой платформе, но имеющих схожую, но не идентичную структуру. У сайтов разные владельцы: импортер, множество дилеров;
На сайтах размещены формы, которые имеют разную структуру, но схожие функции, например, заявка на тест-драйв, заявка на кредит;
Кросс-доменного отслеживания трафика и кампаний между сайтами нет;
На сайте импортера установлен pop-up сервис, который показывает попапы с html контентом, в некоторых случаях форму сбора персональных данных.
Гипотезы:
Настроив кросс-доменное отслеживание мы сможем понять как переливается трафик между сайтами и найти точки отказа.
Пользователи выполняют целевые действия в динамических формах, но не отправляют их - нужно собирать анонимные сведения о действиях с формой до сбора контакта.
Например, результатом работы формы калькулятора кредита является примерная ставка, а полезным действием формы для пользователя - форма сбора контакта для обратной связи. Очевидно, что пользователь не оставляет свой контакт.
Всплывающее сообщение можно персонализировать если узнать чего хочет клиент.
Например, независимо от действий пользователя на сайте на каждой странице клиенту показывается одно и тоже сообщение с красным кроссовером за 5М рублей, даже если он смотрел форму расчета trade-in на автомобиль за 1М, при этом pop-up форма настойчиво выскакивает на каждой странице через 10 сек после ее открытия.
Собирая и интерпретируя сведения о действия пользователей на сайтах мы сможем понять их интересы.
Использовать эти сведения можно для улучшения коммуникаций через персонализацию сообщений анонимных и авторизованных пользователей.
Профили авторизованных пользователей можно обогатить интересами и предпочтениями.
Концепция решения
В качестве решения мы решили использовать сведения о взаимодействии пользователей с сайтом и его элементами для определения интереса пользователя к той или иной модели автопроизводителя. Затем использовать эти данные для персонализации рекламы и коммуникаций чтобы повысить релевантность сообщения для потенциального покупателя.
Таким образом мы рассчитывали сократить время необходимое потенциальному покупателю для принятия решения о совершении контакта и будущей покупки, подталкивая его через персонализацию коммуникаций.
Мы сформулировали следующие требования к набору данных который должны получить на выходе:
данные должны описывать интерес пользователя к нескольким моделям бренда,
данные должны содержать идентификаторы пользователей не нарушающие условия анонимности и действующее законодательство,
данные должны иметь TTL позволяющий сохранять релевантность полученных данных для бизнеса,
мы не должны упускать возможность использовать данные полученные с дилерский сайтов.
Также мы разработали функциональные требования, которым должно соответствовать разрабатываемое решение:
для решения задачи должны быть использованы средства машинного обучения,
для сбора данных должны быть использованы существующие инструменты веб-аналитики,
в архитектуре должны быть задействованы платформенные решения или решения с открытым исходным кодом,
результаты работы решения должны быть доступны через API для персонализации коммуникаций на сайте или использования третьими сервисами,
должна быть возможность работать с сырыми и обработанными данными для построения сегментов и выгрузки данных для партнеров и обогащения CRM.
Работа с данными
Учитывая ежемесячную посещаемость сайта от 200 до 300 тыс. пользователей в мес., а также длительный цикл продаж, характерный для автомобильного рынка, мы рассчитывали собрать объем данных, который позволит нам разработать устойчивую модель, за 3-4 месяца. Сайты дилеров дали нам еще 40-50 тысяч уникальных пользователей и знания об их перемещениях между сайтами.
В основу дата-сета с которым предстояло работать должны были лечь сведения о взаимодействии пользователя с сайтом. В качестве источника данных мы рассматривали Google Analytics, но для этого нужно было решить несколько задач:
Настроить кросс-доменный счетчик Google Analytics,
Выделить нужные события на сайте импортера и дилеров, настроить теги GTM, а для отслеживания “сложных” событий написать отдельный код.
Чтобы оптимизировать трудозатраты на разметку нужных событий, было принято решение на сайтах дилеров классифицировать только тематику посещаемых страниц, а на сайте импортера отслеживать полный набор событий, в том числе совершаемые с формами калькуляторов, конфигураторов и других интерактивных элементов.
При решении вопроса стриминга данных были сформированы следующие требования:
сбор данных из уже настроенного источника,
простота реализации в стриминга данных,
низкая стоимость хранения данных.
Идеальным кандидатом, соответствующим этим критерием, стал BigQuery, а также очков в пользу сервиса от Google добавляло наличие инструмента OWOX BI, который позволял передавать события сгенерированные Google Analytics непосредственно в BigQuery. Не очень быстрое, но выгодное во всех смыслах решение для того чтобы накопить данные.
С этого момента тянулись долгие 4 месяца в течении которых мы следили за изменениями на сайте и собирали сведения о поведении пользователей, их взаимодействии с формами, и готовились к тому чтобы приступить к разработке модели.
Разработка модели
Тип задачи, которую должен решать алгоритм, - это классификация пользователей на основе пространства признаков. Был использован класс алгоритмов, которые относятся к разделу «обучения с учителем», выборка была разделена на 3 выборки для обучения и оценки качества модели: обучающую, валидационную, тестовую.
На основе данных, собираемых в Google BigQuery, были предварительно рассчитаны профили пользователей. Данные профили в дальнейшем используются для построения математических моделей, а также обогащены геоданными и сведениями об источниках трафика.
Профиль пользователя состоит из примерно 140 переменных. Для разработки модели мы свели список переменных к тем, которые действительно играют роль в разделении пользователей на группы, то есть провести так называемый feature-selection.
Были проверены несколько алгоритмов – Наивный Байес, Метод опорных векторов, несколько реализаций деревьев решений, леса решений. Оценка алгоритмов проводилась по показателям полноты и точности, а также показателю AUC. В конце была проведена кросс-валидация - данные перемешали, достали рандомные записи и посмотрел, как модель работает. Хотя можно было бы использовать и 2 выборки – что не является ошибкой. Наибольшую точность и полноту показали алгоритмы леса решений и дерево решений.
"Ну ещё бы" (с) Data Scientist из моей команды
Пример результата работы модели:
Техническое решение
К моменту завершения работ над моделью мы уже были на финишной прямой в вопросе завершения разработки инструментов для интеграции с внешними сервисами. Что у нас получилось в итоге?
Архитектура решения включает ряд компонентов, каждый из которых выполняет свою специализированную функцию:
Счетчики сбора статистики на Web-сайте. В качестве источника этих данных использовался GTM, который отправлял детальные данные нашему Web-сервису и на машину в инфраструктуре Google для дальнейшего сохранения в MongoDB и BigQuery.
Google AppEngine (Cron Jobs). Для сбора статистики в BigQuery необходим посредник, который бы аккумулировал поток событий. По мере накопления сохранял бы их в BigQuery.
Google BigQuery. Система для проведения анализа и подготовки данных для расчета модели. В real-time взаимодействии никак не участвует.
Google AppEngine (API). Это Web-приложение, с которым непосредственно общается сайт. Через него происходит разбор детальных данных статистики и сохранение их в MongoDB, запуск расчета и выбор профилей, применение модели к профилю.
Google AppEngine (MongoDB). Для расчета профилей в real-time BigQuery не подходит в силу высокой задержки и дороговизны запусков (ориентирован на пакетную обработку).
Google AppEngine (API ML). Развернутый интерфейс для доступа к модели через API.
Что получилось?
Сервис pop-up форм
Мы перевели сервис на собственный триггер для показа всплывающего сообщения. Получение профиля пользователя для показа оптимального изображения и CTA текста на всплывающей форме. В зависимости от содержания профиля - подбирается нужное сообщение. Если данных по пользователю нет или они устарели, очередной запрос приводит к расчету модели интересов пользователя и возврату нужных показателей.
Что поддаётся кастомизации во всплывающем сообщении: 1) текст и ссылки; 2) изображение; 3) страницы и момент показа.
Например: Пользователь смотрел красный малолитражный автомобиль модели "А" => К его профилю привяжется модель "А" и цвет "красный"; пользователь смотрел страницу кредита => К его профилю привяжется интерес "кредит". При следующем посещении сайта или в ретаргетинге для него будет показан баннер про красный автомобиль с текстом про кредит.
Обогащение данными CRM
Результаты расчета профилей и CRM данные получилось объединить для тех пользователей, которых мы знали или узнали в процессе взаимодействия. За счет обогащения данных стала возможна:
прогрессивная сегментация для персонализации контента и предложений в email коммуникациях,
выстроен процесс регулярной передачи сегментов медиа-партнёрам для повышения точности ретаргетинга и look-a-like.
Рост показателей конверсий
Несмотря на то, что статья про архитектуру и возможности решения - могу сказать что показатели конверсии пришли в норму для той части аудитории, которую охватывал эксперимент. Проводилось А/В тестирование с контрольной группой.
На этом всё. Надеюсь было интересно. Спасибо!
