Как мы строили сквозную аналитику и укрощали бизнес-требования
Привет! На связи Даниил, дата-инженер компании iSpring. Уже 23 года мы создаём инструменты для корпоративного обучения. В статье расскажу, как и почему мы решили внедрить сквозную аналитику в компанию, с какими сложностями столкнулись и как побеждали бизнес-требования.
Сквозная аналитика затрагивает инженерию, маркетинг и аналитику, поэтому я собрал небольшой глоссарий терминов, которые буду использовать в статье. Он поможет сразу понять значение специальных слов и не отвлекаться на их поиск во время чтения.
Глоссарий
Сквозная аналитика (end-to-end analytics) — метод анализа маркетинговой эффективности путём сбора данных о взаимодействии клиента с бизнесом. Она позволяет выстроить цепочку событий, которую совершил клиент от момента первого контакта до покупки, чтобы можно было понять, какой путь прошёл клиент и что побудило его совершить покупку.
Модель атрибуции — метод распределения весов конверсии согласно заданному алгоритму по набору событий. Конверсия определяет, насколько конкретное событие оказалось ценным для достижения цели. Например, насколько сильно посещение страницы сайта повлияло на решение о покупке продукта.
Вход на сайт (Визит, Visit) — одно из событий в сквозной аналитике, которое отражает посещение веб-страницы.
Лог посещений — вся история посещения страниц сайтов пользователем.
Лид (Lead) — потенциальный клиент, который оставил свои контактные данные.
Лид-событие (Lead Event) — событие, которое совершает потенциальный клиент. Оно приводит к появлению лида. Например, обращение в онлайн-чат, отправка запроса на получение пробной версии продукта, звонок менеджеру продаж и т. д.
Триал (Trial) — пробная версия продукта с ограниченным функционалом и периодом пользования.
Хранилище данных (Data Warehouse, DWH) — система централизованного хранения данных, в котором собирается информация из различных исходных систем.
Витрина данных (Data Marts) — подмножество информации в хранилище данных, которое описывает некоторую предметную область.
Что входит в сквозную аналитику
Сквозная аналитика — это система, которая собирает и объединяет данные из разных источников, таких как CRM, рекламные кабинеты, трекеры посещений на сайтах и другие внутренние и внешние системы. Она помогает не просто отследить путь клиента до покупки, но и понять, какие каналы и точки взаимодействия работают эффективнее всего, чтобы лучше управлять бюджетом и повышать конверсию.
Главное в сквозной аналитике — правильно построить цепочку событий и посчитать атрибуцию. Помимо онлайн-событий, таких как клики на сайте, нужно учитывать офлайн-активности (например, звонки или встречи). Для этого данные с этих активностей необходимо оцифровать, чтобы отразить события в пути клиента.
Для хранения и обработки таких данных необходимо качественное хранилище данных (DWH), которое собирает информацию из различных источников данных и обеспечивает высокую скорость обработки запросов. Такое хранилище данных в нашей компании уже было.
Как в iSpring анализировали эффективность до сквозной аналитики
До появления DWH и сквозной аналитики маркетинговый анализ строился на Google Analytics, «Яндекс Метрике» и истории посещения сайтов, которую собирал написанный нами трекер. У всего этого многообразия была большая проблема: три источника правды об одном и том же, которые показывают примерно одинаковую динамику. Данные собственного трекера теоретически можно было связать с другими типами событий, так как почти вся необходимая информация хранилась в нашей системе CRM. Но прямой запрос SQL к CRM получался очень тяжёлым. База данных с трудом выполняла этот запрос или не выполняла вообще. Поэтому мы отказались от идеи построения сквозной аналитики без DWH.
На этом этапе ограничились аналитикой по первому касанию (модель атрибуции First Click). Эта модель оценивает эффективность событий знакомства клиента с продуктом, а все прочие события игнорирует. Недостатком этой модели является то, что мы никак не оцениваем события, произошедшие в середине и конце пути клиента, и, следовательно, мы ничего не можем сказать об их эффективности (какие модели атрибуции существуют, можно посмотреть здесь). Плюс для используемой модели мы никак не дробили цепочку всех событий клиента на единицы конверсии, а значит, и вся конверсия уходила самому первому событию, с которого начался путь клиента. Вот такое несовершенство модели. Разберём на примере, как это выглядело:
Пример модели атрибуции по First Click
На картинке видим путь клиента, в котором были различные посещения сайта, лид-события и три платежа. Первый вход клиента был с канала direct: человек вставил ссылку на страницу в поисковую строку. Во второй раз он зашёл на сайт с рекламы (cpc), взял пробную версию продукта (trial) и спустя время совершил покупку (payment 1). Компания получила деньги, но весь вклад в привлечение клиента (100%) записали на канал direct. Маркетологи недовольны, так как в статистике проигнорировали вклад рекламы, CPC (Cost Per Click) канала.
Спустя время клиент снова зашёл на сайт, кликнув по рекламному объявлению (cpc) и создал лид-магнит (например, оставил свои контактные данные взамен на промокод / подарок / доступ к закрытым материалам и пр.). После этого события случился второй платёж (payment 2). И мы снова засчитали всю конверсию в первый канал direct. Маркетологи снова недовольны.
И третий платёж: клиент зашёл на сайт из email-рассылки (email). Через некоторое время опять зашёл на сайт по ссылке (direct). Потом побывал на конференции, пообщался с нашими менеджерами (offline-лид-событие) и совершил покупку (payment 3). И опять вся конверсия ушла в канал direct. Здесь недовольны не только маркетологи, но и менеджеры продаж, которые общались на конференции с клиентом, а их вклад мы никак не учли.
Модель First Click не отражает реального вклада маркетинга в привлечение клиента, поэтому оценить эффективность маркетинговых активностей и управлять ими на основе цифр невозможно.
С чего мы начали построение сквозной аналитики
Так как мы решили строить сквозную аналитику (внутри команды мы стали называть её «сквозняком»), то заодно решили внедрить и новую модель атрибуции. Модель по первому касанию нас не сильно устраивала, да и к тому же у нас есть Data Warehouse, в котором можно реализовать достаточно сложную бизнес-логику и обрабатывать большой объём данных. И вместо модели атрибуции по первому касанию мы решили внедрить U-shaped модель. В отличие от первой модели, U-shaped распределяет конверсию по всем событиям. Реализуется это по следующим правилам:
Первому и последнему событиям в конверсии присваивается по 40% конверсии.
Оставшиеся 20% равномерно распределяются по всем остальным событиям.
Если же событий только два, то каждому присваиваем по 50% конверсии.
Если взять ту же цепочку событий, что рассматривалась в примере модели First Click, то вот как изменяются веса конверсий по моделям:
Модель атрибуции U-shaped
Теперь каждому событию мы присваиваем вклад в привлечение клиента. Все довольны — и маркетологи, и менеджеры по продажам, хотя степень довольства зависит от того, как распределились веса.
На этапе проектирования первой версии сквозной аналитики мы решили ограничиться набором из трёх типов событий: вход на сайт, лид-событие и платёж. Цепочку последовательностей мы выстроили следующую:
Человек попадает на сайт, где знакомится с продуктом. На этом этапе собирается лог посещений посетителя. На какие страницы веб-сайта он заходит, с какой рекламы совершил переход, из какой страны было совершено посещение и т. д.
Ознакомившись с продуктом, человек берёт пробную версию продукта (триал) или, например, оставляет контактные данные, чтобы мы с ним связались. Здесь создаётся лид-событие, т. е. посетитель сайта конвертируется в потенциального покупателя.
Изучив триальную версию или поговорив с менеджером продаж, потенциальный покупатель совершает покупку. И этот момент мы фиксируем как завершённый путь клиента и считаем за успешную конверсию.
Цепочка событий для пути клиента у нас выстроилась следующим образом: «посещение сайта → лид-событие → платёж», хотя в реальности всё оказалось не совсем так, но об этом далее.
Платёж мы взяли за единицу конверсии и распределяем её следующим образом:
Если это первый платёж — распределяем вес по событиям с самого первого в пути клиента до последнего события, предшествовавшего платежу.
Если это последующий платёж, то распределяем вес по всем событиям между предыдущим платежом и текущим, считая первым событием в конверсии предыдущий платёж. Нам было важно понять, какой вклад покупка одного продукта вносит в покупку другого продукта.
В итоге модель атрибуции стала выглядеть следующим образом:
Реализация первой версии витрины данных для сквозной аналитики у нас заняла около месяца. За это время мы:
домигрировали данные, которых недоставало в DWH;
создали саму витрину и написали пайплайн для её обновления;
написали бизнес-логику и покрыли её тестами;
отдали готовую витрину с данными аналитикам, которые уже собрали дашборд для заказчиков.
Когда витрина данных и логика построения пути клиента были готовы, мы пошли тестировать и смотреть, что у нас получилось. И уже на реальных данных мы обнаружили, что в нашей модели мы не учли некоторые моменты.
Первое, на что упал взгляд при проверке модели, — есть конверсии, в которых нет других событий, кроме платежа, или представлен только один из двух типов событий (нет информации о посещении сайта или лид-событии). Погрузившись в данные, мы накопали несколько кейсов.
Кейс 1 — отсутствие данных
Самый первый и очевидный кейс — данных действительно нет. В исходных системах мы не нашли никакой информации о клиенте и его действиях до совершения покупки (здесь мы сделали глубокий вздох и сказали: «Пу-пу-пу»).
Раз никакой информации нет, мы решили сгенерировать фиктивную. Добавили в логику расчёта конверсий проверку на количество посещений сайта и лид-событий для каждой конверсии. Если какой-то сущности нет в конверсии, тогда добавляется фиктивная сущность, мы назвали их No Weblog и No Lead Event соответственно, и на них также засчитывались конверсии. Распределение весов конверсий по фиктивным событиям сделали для того, чтобы подсветить в сквозной аналитике проблему отсутствия информации. Чтобы все знали, что мы ничего не знаем.
Кейс 2 — офлайновые лид-события
Мы регулярно участвуем в различных конференциях и выставках на тему корпоративного обучения и LMS (Learning Management System, система корпоративного обучения) плюс сами организуем и проводим подобные ивенты (например, конференция iSpring Days). Лид-события с подобных офлайн-мероприятий загружаются в CRM как список из Excel-файла. На данных это выглядит как множество лид-событий, созданных в один момент времени. Но посещений, которые говорят о том, откуда они пришли, — нет. Хотя в реальности и визит (в этом случае это посещение мероприятия), и лид-событие были. Для офлайн-событий мы посчитали некорректным создавать фиктивные No Weblog визиты, ведь был ивент, куда клиент пришёл и где мы с ним контактировали. Так что для офлайновых лид-событий мы добавили ещё один канал визита — Offline Visit. Этот тип визита добавляется для каждого офлайн-лид-события и связывается с этим лидом. Ура, одной неопределённостью меньше.
Когда менеджер продаж забыл загрузить офлайновых лидов
Кейс 3 — старые визиты и свежие лиды
Лид-событие привязывается к последнему визиту и наследует его канал привлечения. Когда мы посмотрели на эту связку, то обнаружили, что бывают лиды, для которых связанный визит произошёл когда-то давно во времени. Например, последнее посещение сайта было с рекламы и произошло месяц назад, а лид-событие появилось только сегодня. Вряд ли к его созданию привёл тот самый переход с рекламы. Скорее всего, были другие активности, которые произошли за месяц, но которые в текущей модели мы не учитываем. Или произошёл сбой, и информации о событиях за этот период не сохранилось. No Weblog поставить было бы некорректно, ведь клиент на сайте был. Собрав статистику и обсудив с заказчиками, решили ограничиться периодом в 24 часа. Если время между визитом и лид-событием меньше 24 часов, тогда считаем, что этот визит привёл к созданию лида, и связываем их. Но если прошло более 24 часов, мы добавляем новый фиктивный визит — No Visits. То есть лид-событие создалось не из визита, а по какой-то другой причине.
Кейс 4 — клиент не только тот, кто платит
Чаще всего наши клиенты — это другие бизнесы, то есть в процессе принятия решения участвует не только покупатель, который указан в платеже, но и, возможно, его коллеги. И вот картина: смотрим на покупателя продукта — лидов нет, лога посещений нет. Поднимаемся на уровень компании, смотрим события по всем контактам — лог посещений и лиды на месте. Сделали вывод, что один человек из компании мог ходить по сайту, изучать информацию, общаться с менеджерами, а оплату совершить другой человек. Приняли решение улучшить сквозную аналитику и смотреть все события на уровне компании. Но оценив, сколько ресурсов у нас займёт переход модели на уровень компании, решили сделать это уже в следующем релизе, а первую версию сквозной аналитики оставили на уровне клиента.
Как сквозная аналитика помогает в решении бизнес-задач
Чтобы оценить, как сквозная аналитика повлияла на маркетинг и продажи, собрали фидбэк у пользователей и заказчиков. Далее краткий список того, что мы получили от её внедрения:
Отразили, какую реальную выручку приносит каждый канал привлечения.
Смогли оценить эффективность рекламных кампаний и скорректировали рекламный бюджет. Какую-то рекламу совсем отключили, а другой увеличили бюджет и повысили частоту показа.
Подсветили, какие активности и события догревают клиента до покупки, и получили возможность их анализа.
Добавление фиктивных событий подсветило проблему отсутствия данных для бизнеса. Это привело к большому проекту по улучшению трекинга посещений на сайте и связыванию кликов на сайте с клиентом. В результате No Weblog у нас упал с 20–25% до 10%.
Команды маркетинга и продаж теперь видят свой реальный вклад в успех бизнеса. Здесь хочется привести прямую цитату из собранных отзывов: «Это стало приятным эмоциональным подкреплением и мотиватором для ребят — видеть, что их труд приносит реальную прибыль».
Как мы будем развивать сквозную аналитику
Проект сквозной аналитики мы будем продолжать улучшать и развивать. Наметили следующие пути развития проекта:
Добавлять новые типы событий в сквозную аналитику. Сейчас есть запросы на добавление событий типа «звонок», «встреча», «действия в продукте» и др.
Анализировать не только успешные кейсы конверсий, когда цепочка привела к покупке, но и смотреть неудачные цепочки, когда клиент где-то по пути застрял и не дошёл до конверсии.
Также рассматриваем возможность перейти от использования U-shaped модели к модели атрибуции, основанной на данных. В этой модели веса также распределяются по всем событиям в цепочке, но значение веса рассчитывается на основе алгоритма машинного обучения.
