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

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

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

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

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

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

Максим Дарулис

Коммерческий директор ispmanager

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

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

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

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

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

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

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

• Стоимость лида и сколько денег принёс каждый из них, когда стал клиентом.

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

• Сколько было пользователей по каналам и стоимость их привлечения.

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

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

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

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

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

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

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

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

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

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

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

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

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