Сколько стоит лид — как настроить систему аналитики, если связка Roistat и CRM не помогла

Однажды некоторые технари переходят на тёмную сторону и ищут ответы на дурацкие вопросы: сколько стоит лид, какую прибыль приносит каждый канал с учётом LT пользователей… Да, кстати, а сколько у нас пользователей и какова стоимость их привлечения? А ещё, пожалуйста, посчитайте конверсии в покупку на каждом этапе воронки по каждому из каналов.

Рассказываем о нашем способе выстроить аналитику от потраченных до заработанных каждым маркетинговым каналом денег с помощью GTM, «Яндекс Метрики», Superset, BILLmanager, Data Layer и кастомных скриптов. Способ работает при нашем легаси и любви к космолётам и не претендует на то, чтобы быть оптимальным для всех.

Сколько стоит лид — как настроить систему аналитики, если связка Roistat и CRM не помогла

Для начала — у нас не получилось срастить Roistat, его счётчик на сайте и BILLmanager с помощью стандартных интеграций. А у наших партнёров — вполне.

У коллег Roistat в комплекте с amoCRM работает как часы. Потому что ребята работают почти с каждым клиентом лично и всех заводят в amoCRM. Мы не можем вносить в CRM конечных пользователей: система переполнится записями. Эти клиенты у нас существуют только на уровне биллинга. А CRM есть только для партнёров, с которыми работает отдел продаж. И там своя система аналитики.

Наша схема подойдёт не всем. Тут много рукописных интеграций: ЯМ → BILLmanager, BILLmanager → Superset, ЯМ → Superset. И каждая из них может перестать работать из-за обновлений любого из компонентов. А ещё всё это нужно поддерживать и следить за чистотой данных. Гораздо проще пользоваться нативными интеграциями.

Мы пошли по этому пути, потому что у нас нет CRM в классическом виде для сегмента конечных клиентов: наш продукт продаётся автоматизированно. Вот мы и разработали космолёт из множества интеграций. Если вы пользуетесь BILLmanager, но не готовы интегрироваться с более очевидными решениями вроде amoCRM, возможно, пригодится наша схема.

Без аналитики больно. UTM-метки годятся для отдельных активностей. А вот чтобы проанализировать, какой канал прибыльный, какой — убыточный, куда инвестировать, как оптимизировать конверсии, проанализировать причины роста или падения продаж, — нужно было забуриться глубже.

Например, каждый раз, когда продажи резко росли или падали, причины приходилось раскапывать руками. Долго и мучительно: копались в Brand Analytics — вдруг упомянул блогер, шли в «Яндекс Метрику» — был ли скачок в SEO, думали — а может, что-то из рекламы. Но узнать точно всё равно было невозможно. А значит, повторить или избежать — тоже никак.

Максим Дарулис
Коммерческий директор ispmanager

Мне кажется, мы стали седыми от отсутствия аналитики. Без неё мы фризили многие моменты. Не все гипотезы могли проверить: вот а как мы их будем оценивать, что будет успехом, что — провалом, как измерим ROI. Без ретроданных не могли сравнивать прошлые активности. В какие-то моменты работали «по ощущениям», без увеличения бюджетов на рекламу, сдвигали сроки. Я вечно спрашивал, когда будет готова аналитика. А когда это длится более трёх месяцев, такие вопросы уже не очень приятные.

Ну и, разумеется, прилагался регулярный бонус от руководителей в виде «уже приехали?», вернее: «а когда сможем увидеть аналитику?».

С чего начали, что получили, куда идем дальше

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

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

Теперь видим:

  • Стоимость лида и сколько денег принёс каждый из них, когда стал клиентом.
  • Прибыль по каналам: сколько денег потратили на каждый канал за период, сколько денег с учётом LT пользователей канал принёс.
  • Сколько было пользователей по каналам и стоимость их привлечения.

Следующий этап — видеть конверсии на каждом этапе воронки по каждому из каналов и разбивку по сегментам. Например, по рекламным кампаниям в платном трафике.

Инструменты, которые мы использовали на разных этапах:

Roistat — комплексное решение для аналитики веб-ресурсов, где есть мультиканальная аналитика. Помогает считать затраты на каналы и выручку от пользователей с помощью интеграции с CRM. Roistat присваивает пользователю уникальный случайный номер по которому можно отслеживать действия посетителя.

BILLmanager хранит данные об услугах, которые купили пользователи: лицензии, SSL-сертификаты и модули. А также их тикеты и уведомления от компании.

«Яндекс Метрика» — система аналитики трафика, приходящего на сайт.

Google Tag Manager (GTM) — ПО, позволяющее в конструкторе отслеживать события на сайте и передавать их в нужные аналитические системы — «Яндекс Метрику» или Google Analytics.

DataLayer — технология, которая позволяет передавать события в систему аналитики или GTM. Основное отличие от GTM в том, что можно более тонко навешать события, но разрабатывать скрипт придётся самому. Например, чтобы события срабатывали не на нажатие кнопки, а на факт отправки формы.

Apache Superset — open-source-решение для визуализации данных.

ClickHouse — open-source-решение для управления базами данных и формирования отчётов на их основании.

Дальше расскажу о наших экспериментах подробнее.

Roistat, BILLmanager и гугл-таблицы

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

Вот так выглядела и работала схема. Какое-то время.

Сколько стоит лид — как настроить систему аналитики, если связка Roistat и CRM не помогла

Общих интеграций у Roistat, его счётчика на сайте и BILLmanager нет, поэтому в ход пошли костыльные решения. Мы не стали писать отдельный обработчик данных для передачи из BILLmanager в Roistat, а воспользовались интеграцией Roistat и гугл-таблиц. Из BILLmanager в таблицы передавались данные о лицензиях вместе с Roistat Id — анонимной меткой, которую BILLmanager получал от счётчика Roistat при регистрации или покупке лицензии пользователем. А Roistat забирал данные из таблиц в свою внутреннюю систему и сращивал их с информацией, которую он получал от счётчика.

Метка в BILLmanager должна где-то храниться — нужно было добавить кастомное поле в таблицу «Услуги». Сделать это можно как со стороны фронтенда, так и на бэкенде — с помощью плагинов. Когда мы делали интеграцию, мы с ISPsystem были одной компанией. Поэтому нам помогали ребята из разработки BILLmanager. Они использовали стандартные возможности биллинга для создания плагинов. При необходимости вы сможете создать похожий плагин самостоятельно.

Иван Мешков
Проджект-менеджер BILLmanager

О бэкенде интеграции BILLmanager и Roistat

Интеграция с Roistat состояла из следующих частей:

1. Плагин для BILLmanager на Python.

2. Скрипт isp6stat на Go.

Описание работы плагина BILLmanager

Файлы:

/usr/local/mgr5/etc/xml/billmgr_mod_isp6stat.xml, /usr/local/mgr5/addon/roistat_visit, /usr/local/mgr5/addon/roistat_visit_change_project, /usr/local/mgr5/addon/isp6stat.

В настройках бренда в BILLmanager в html-вставке указываем счётчик, который предоставляет Roistat. В результате для клиентов, которые входят в биллинг, выставляется уникальный roistat_visit в куках.

/usr/local/mgr5/addon/roistat_visit представляет собой событие, которое навешено на функцию soft.order.param. Это событие извлекает roistat_visit и id заказываемой услуги и запускает файл /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat_roistat.sh, передавая roistat_visit и item_id в качестве аргументов.

/usr/local/mgr5/addon/roistat_visit_change_project — событие, предназначенное для передачи существующего roistat_visit при переходе в другого провайдера BILLmanager, чтобы roistat_visit в куках клиента на разных провайдерах был одинаковым. Иначе бы у разных провайдеров был разный roistat_visit — при условии, что у провайдеров заданы разные домены.

/usr/local/mgr5/addon/roistat_visit — функция, которая позволяет сотруднику или вручную с помощью cron через http api запустить сбор статистики по услугам ispmanager 6 с последующей записью в гугл-таблицу. Функция запускает файл /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat.sh

Описание работы скрипта isp6stat

Файлы:

/home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat — исходный скрипт.

/home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat_roistat.sh — bash-скрипт, который запускает бинарник с параметром --set-roistat-label и перенаправляет вывод в logs/isp6stat_roistat_{текущая дата}.log

/home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat.sh — скрипт, который запускает бинарник для сбора статистики по услугам ispmanager 6 с последующей записью в гугл-таблицу. Перенаправляет вывод в logs/isp6stat_{текущая дата}.log

/home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/config.ini — файл настроек.

/home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/gkey.json — ключ google api, используется приложением для записи в гугл-таблицу.

/home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/logs — директория с логами.

Бинарник создаёт отдельную БД isp6stat в СУБД для BILLmanager, в которой создаются следующие таблички:

isp6stat.roistat_visit — хранит информацию о roistat_visit'ах c привязкой к id услуги;

isp6stat.client — информация о сделках. По сути, копия данных в гугл-таблице.

Общий принцип работы

Клиенты с выставленным в куках roistat_visit заказывают услугу. В момент заказа вызывается isp6stat_roistat.sh, сохраняется привязка roistat_visit к услуге.

По расписанию, указанному в crontab, запускается /home/{ИМЯ ПОЛЬЗОВАТЕЛЯ}/isp6stat.sh и собирается статистика по услугам c тарифными планами, указанными в конфиге — запрос sqlItemsQuery в billmgr/billmgr.go. Далее выполняется предобработка. Например: перевод валюты, выставление roistat_visit. Потом данные сохраняются в таблицу isp6stat.client. Потом эти же данные отправляются в гугл-таблицу.

Почему не взлетело. Если бы всё сработало так, как и было задумано, мы бы увидели в Roistat стоимость лида и сколько денег принёс каждый из них, когда стал клиентом. Со стороны Roistat всё работало отлично, только интеграция с гугл-таблицами непонятно почему периодически ломалась. Roistat — сложный и полезный продукт. Там хорошо видны каналы и даже есть мультиканальная атрибуция. Мы бы с удовольствием им пользовались и дальше — но не случилось. Дальше платить за лицензию Roistat было бессмысленно: мы всё равно не видели в аналитике того, что было нужно.

Пришлось искать альтернативу.

GTM, «Яндекс Метрика», Superset и BILLmanager

Идея со сращиванием данных казалась верной, поэтому мы продолжили копать в ту сторону. Но в этот раз отказались от комплексного Roistat с глубокими возможностями веб-аналитики в пользу самодельных решений.

Писать свой счётчик мы не стали — это звезда смерти. Задача настолько большая, что даже непонятно, с какой стороны к ней подойти. Нужно сделать обработку куков, понять, как отслеживать переходы с разных источников и кучу других показателей… Делать всё это мы были не готовы. Поэтому решили построить систему на уже имеющихся элементах: GTM, «Яндекс Метрике», Superset и BILLmanager.

На уровне сайта цели, созданные Roistat, заменили на Data Layer. Data Layer — это технология, которая позволяет передавать информацию о выполнении цели с более глубокой настройкой. Например, информация передаётся не после нажатия кнопки на форме, а после того как бэкенд отработал и отрапортовал, что form submitted. После этого информация подхватывается GTMом и передаётся в «Яндекс Метрику». Так узнаём, какой пользователь какие формы заполнил и какие действия совершил.

После прошлых экспериментов в BILLmanager у нас осталось место, куда можно передавать Roistat ID. Но поскольку поле текстовое, передавать туда можно что угодно. Мы решили запихнуть туда «Яндекс ID», который выполнял ту же функцию, что и Roistat ID.

Superset мы используем, чтобы работать с продуктовой и коммерческой аналитикой. Например, мы смотрим, сколько денег принёс каждый из сегментов нашей аудитории, сколько новых клиентов пришло к нам напрямую, а сколько — от партнёров. Приложение отрисовывает графики на основе информации, которая хранится в базе Clickhouse.

Теперь наша система аналитики выглядит так:

Схема стала существенно сложнее, но общий смысл остался
Схема стала существенно сложнее, но общий смысл остался

Как теперь выглядит аналитика

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

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

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

Создавать кастомные решения, как наша система аналитики, — сложно. Мы задействовали много людей и одного руководителя отдела маркетинга — один из скриптов я писал лично. Но когда вместо десяти часов руководитель тратит пять минут, чтобы понять, что именно выросло и в какой канал можно инвестировать, освобождается прорва времени на то, чтобы заниматься стратегическими задачами. И не приходится распыляться на перекидывание данных из одних таблиц в другие. Это круто.

Ещё мы строим математические модели для прогнозирования количества клиентов. Но о них в другой раз. Увидимся в комментариях =)

1313
14 комментариев

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

Саммари:
- Проблемы интеграции Roistat и CRM привели к поиску решения
- Создана сложная система аналитики
- Использованы GTM, Яндекс Метрика, Superset, BILLmanager
- Сложности с Roistat из-за отсутствия прямой интеграции
- Базируется на ручных интеграциях и адаптации под нужды
- Разработка собственного решения вместо стандартного CRM
- Эксперименты в аналитике для улучшения понимания маркетинга
- Визуализация данных с помощью Apache Superset
- Трудности переноса данных и поддержка системы
- Создание кастомных скриптов для более глубокого анализа данных

Стараюсь выделять самое важное для вас.

1
Ответить

CRM мы не создавали, но спасибо за саммари.)

1
Ответить

Аналитика, кажется, слабое место в большинстве компаний

1
Ответить

На мой взгляд причины тому две:
1. Аналитика — сложная штука сама по себе.) Легко и просто она работает только в том случае, если процесс продажи технически простой и в одном месте. Даже если есть личный кабинет на поддомене — уже начнутся нюансы.
2. В вопросе аналитики не хватает системности со стороны компании. По моему опыту, обычно аналитика создается в разных подразделениях под разные задачи в отрыве друг от друга, и из-за этого порой есть решения внутри компании делающие одно и тоже. Или считающий один показатель по-разному. И даже наличие выделенного аналитика дело не спасает.

Мы тоже в это наступали. Спасает только то, что на уровне компании определяются как и что отслеживаем и для чего. А под это уже строится вся остальная аналитика в компании.

1
Ответить

Всегда удивлял факт, что интеграция с Google Analytics в Billmanager была реализована тучу лет, а с Яндекс.Метрикой - нет.
PS. А почему кстати, не стали использовать интеграцию с Google Analytics? Она ж работает вроде как.

1
Ответить

Субъективные причины, наш опыт и законодательство:

1. Яндекс.Метрика более удобная в использовании (ИМХО),
2. У неё более понятный и прозрачный API (ИМХО)
3. Мы даем рекламу в Яндексе, а для этого, по нашему опыту, лучше делать оптимизацию конверсий через ЯМ.
4. Регуляторные органы не очень хорошо относятся к трансграничной передачи данных из РФ за границу. Поэтому все сервисы, которые обрабатывают данные пользователей из РФ в открытом или анонимном виде у нас находятся на территории РФ.

В нашей структуре GA помогла бы только тем, что можно было бы не передавать в билинг метку с сайта, но все остальное пришлось бы делать все равно.)

Ответить

А мне наоборот с Google Analytics было проще всегда, как и в целом с любыми продуктами гугла. В том числе и поэтому Billmanager в свое время выбрал. Работает там интеграция отлично и с Google Tag Manager, кстати, тоже

Ответить