Однажды некоторые технари переходят на тёмную сторону и ищут ответы на дурацкие вопросы: сколько стоит лид, какую прибыль приносит каждый канал с учётом LT пользователей… Да, кстати, а сколько у нас пользователей и какова стоимость их привлечения? А ещё, пожалуйста, посчитайте конверсии в покупку на каждом этапе воронки по каждому из каналов.
Рассказываем о нашем способе выстроить аналитику от потраченных до заработанных каждым маркетинговым каналом денег с помощью GTM, «Яндекс Метрики», Superset, BILLmanager, Data Layer и кастомных скриптов. Способ работает при нашем легаси и любви к космолётам и не претендует на то, чтобы быть оптимальным для всех.
Для начала — у нас не получилось срастить Roistat, его счётчик на сайте и BILLmanager с помощью стандартных интеграций. А у наших партнёров — вполне.
У коллег Roistat в комплекте с amoCRM работает как часы. Потому что ребята работают почти с каждым клиентом лично и всех заводят в amoCRM. Мы не можем вносить в CRM конечных пользователей: система переполнится записями. Эти клиенты у нас существуют только на уровне биллинга. А CRM есть только для партнёров, с которыми работает отдел продаж. И там своя система аналитики.
Наша схема подойдёт не всем. Тут много рукописных интеграций: ЯМ → BILLmanager, BILLmanager → Superset, ЯМ → Superset. И каждая из них может перестать работать из-за обновлений любого из компонентов. А ещё всё это нужно поддерживать и следить за чистотой данных. Гораздо проще пользоваться нативными интеграциями.
Мы пошли по этому пути, потому что у нас нет CRM в классическом виде для сегмента конечных клиентов: наш продукт продаётся автоматизированно. Вот мы и разработали космолёт из множества интеграций. Если вы пользуетесь BILLmanager, но не готовы интегрироваться с более очевидными решениями вроде amoCRM, возможно, пригодится наша схема.
Без аналитики больно. UTM-метки годятся для отдельных активностей. А вот чтобы проанализировать, какой канал прибыльный, какой — убыточный, куда инвестировать, как оптимизировать конверсии, проанализировать причины роста или падения продаж, — нужно было забуриться глубже.
Например, каждый раз, когда продажи резко росли или падали, причины приходилось раскапывать руками. Долго и мучительно: копались в Brand Analytics — вдруг упомянул блогер, шли в «Яндекс Метрику» — был ли скачок в SEO, думали — а может, что-то из рекламы. Но узнать точно всё равно было невозможно. А значит, повторить или избежать — тоже никак.
Мне кажется, мы стали седыми от отсутствия аналитики. Без неё мы фризили многие моменты. Не все гипотезы могли проверить: вот а как мы их будем оценивать, что будет успехом, что — провалом, как измерим 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, его счётчика на сайте и BILLmanager нет, поэтому в ход пошли костыльные решения. Мы не стали писать отдельный обработчик данных для передачи из BILLmanager в Roistat, а воспользовались интеграцией Roistat и гугл-таблиц. Из BILLmanager в таблицы передавались данные о лицензиях вместе с Roistat Id — анонимной меткой, которую BILLmanager получал от счётчика Roistat при регистрации или покупке лицензии пользователем. А Roistat забирал данные из таблиц в свою внутреннюю систему и сращивал их с информацией, которую он получал от счётчика.
Метка в BILLmanager должна где-то храниться — нужно было добавить кастомное поле в таблицу «Услуги». Сделать это можно как со стороны фронтенда, так и на бэкенде — с помощью плагинов. Когда мы делали интеграцию, мы с ISPsystem были одной компанией. Поэтому нам помогали ребята из разработки 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.
Теперь наша система аналитики выглядит так:
Как теперь выглядит аналитика
Сравниваем оба массива и совпадения и отрисовываем в виде графиков, которые показывают прибыль по каждому из маркетинговых каналов. И вот что видим — показываем на придуманных данных.
Всё сложно. Мы большие любители кастомизации. Какое бы решение мы ни покупали, какой бы софт ни использовали, всё сводится к тому, что потом мы его допиливаем и дорабатываем, чтобы решать именно наши задачи.
Создавать кастомные решения, как наша система аналитики, — сложно. Мы задействовали много людей и одного руководителя отдела маркетинга — один из скриптов я писал лично. Но когда вместо десяти часов руководитель тратит пять минут, чтобы понять, что именно выросло и в какой канал можно инвестировать, освобождается прорва времени на то, чтобы заниматься стратегическими задачами. И не приходится распыляться на перекидывание данных из одних таблиц в другие. Это круто.
Ещё мы строим математические модели для прогнозирования количества клиентов. Но о них в другой раз. Увидимся в комментариях =)
Статья рассказывает о том, как настроить систему маркетинговой аналитики без использования стандартных интеграций
Саммари:
- Проблемы интеграции Roistat и CRM привели к поиску решения
- Создана сложная система аналитики
- Использованы GTM, Яндекс Метрика, Superset, BILLmanager
- Сложности с Roistat из-за отсутствия прямой интеграции
- Базируется на ручных интеграциях и адаптации под нужды
- Разработка собственного решения вместо стандартного CRM
- Эксперименты в аналитике для улучшения понимания маркетинга
- Визуализация данных с помощью Apache Superset
- Трудности переноса данных и поддержка системы
- Создание кастомных скриптов для более глубокого анализа данных
Стараюсь выделять самое важное для вас.
CRM мы не создавали, но спасибо за саммари.)
вам спасибо за статью :)
Аналитика, кажется, слабое место в большинстве компаний
На мой взгляд причины тому две:
1. Аналитика — сложная штука сама по себе.) Легко и просто она работает только в том случае, если процесс продажи технически простой и в одном месте. Даже если есть личный кабинет на поддомене — уже начнутся нюансы.
2. В вопросе аналитики не хватает системности со стороны компании. По моему опыту, обычно аналитика создается в разных подразделениях под разные задачи в отрыве друг от друга, и из-за этого порой есть решения внутри компании делающие одно и тоже. Или считающий один показатель по-разному. И даже наличие выделенного аналитика дело не спасает.
Мы тоже в это наступали. Спасает только то, что на уровне компании определяются как и что отслеживаем и для чего. А под это уже строится вся остальная аналитика в компании.
Всегда удивлял факт, что интеграция с Google Analytics в Billmanager была реализована тучу лет, а с Яндекс.Метрикой - нет.
PS. А почему кстати, не стали использовать интеграцию с Google Analytics? Она ж работает вроде как.
Субъективные причины, наш опыт и законодательство:
1. Яндекс.Метрика более удобная в использовании (ИМХО),
2. У неё более понятный и прозрачный API (ИМХО)
3. Мы даем рекламу в Яндексе, а для этого, по нашему опыту, лучше делать оптимизацию конверсий через ЯМ.
4. Регуляторные органы не очень хорошо относятся к трансграничной передачи данных из РФ за границу. Поэтому все сервисы, которые обрабатывают данные пользователей из РФ в открытом или анонимном виде у нас находятся на территории РФ.
В нашей структуре GA помогла бы только тем, что можно было бы не передавать в билинг метку с сайта, но все остальное пришлось бы делать все равно.)
Ну это я скорее в сторону разрабов Billmanager бурчал, а не в вашу:) Ваши то потребности понятны и одобряемы:)
А мне наоборот с Google Analytics было проще всегда, как и в целом с любыми продуктами гугла. В том числе и поэтому Billmanager в свое время выбрал. Работает там интеграция отлично и с Google Tag Manager, кстати, тоже
А как вам Billmanager? Гибкое решение? Мы сейчас как раз ищем варианты по биллинговым системам
Зависит от того для каких целей и насколько гибко нужно использовать.) Большинство задач для хостинга и подписочных сервисов он решает.
Но как уже говорил в статье, мы любим все допиливать под себя.) Биллинг не исключение — поэтому пачка самописных модулей у нас есть и тут.
Подойдет ли он именно вам можно узнать только тестами. Тут советую составить самые частые задачи, которые надо решать билингом и проверить разные варианты.
Крутая статья)
А что за источник трафика Internal?
Спасибо.) Это "внутренний переход". Он появляется в трех случаях:
1. Если пользователь открыл страницу и ушел пить чай. Потом посерфил интернет и к нам вернулся через какое-то время. Сессия отваливается по таймауты и Яндекс считает это как "внутренний".
2. Если внутри сайта есть редиректы, на которые ведут внешние ссылки. Если у вас была статья в блоге, вы изменили её адрес, но в соцсетях остался старый, то заход пользователя из соцсетей может промаркироваться как "внутренний"
3. Если на некоторых страницах сайта есть счетчик, а на других нет.
Фактически, это системное значение и его надо снижать.)
Важно видеть реальные примеры работы с данными и аналитикой