Интеграция сквозной аналитики CoMagic: негативный опыт

В качестве product manager на проекте франшизы (по просьбе компании не указывается название) мы попробовали внедрить CoMagic в качестве инструмента сквозной аналитики. На этом кейсе покажем особенности, слепые зоны этой платформы; как и где могут теряться лиды.

Вводные. Стек технологий: Tilda + CoMagic + AmoCRM. Каждый объект партнерской сети находится на отдельном url — классическая удобная схема с точки зрения SEO и поведенческих факторов ЦА. Под каждый объект в отчете должна создаваться воронка с показателями: посещаемость (в разрезе источника), заявки (в разрезе источника), конверсия, CPA. На каждой странице присутствует минимум 3 лид-формы.

Это франшиза, и новые объекты появляются регулярно. Сеть быстро растет. Поэтому постоянное подключение к CoMagic каждой лид-формы отдельно — слишком трудозатратно. Необходимо подключение по API, чтобы заявки автоматически сохранялись при создании любой новой страницы и лид-формы. Менеджеры CoMagic за отдельную плату предлагают только вариант с отдельным подключением лид-форм. Выбираем API только с самостоятельной интеграцией, используя манул CoMagic т.к. готового коннектора с "Тильдой" нет. Подключаем, правим с разработчиками конфликты. Например, "имя" обязательный параметр для отправки заявки в Comagic. Правим, что если нет имени, то вместо него подставляется телефон и заявка отправляется. И так далее по каждому расхождению с AMO по итоговому количеству заявок за период.

CoMagic никак не консультирует по API и не оказывает помощи в конфликтах данных.

После сохранения заявок в системе CoMagic начинаем настройки Рекламных кампаний (источники заявок). Отслеживание заявок с поискового трафика, любых внешних сайтов; картографических сервисов, конкретных сайтов, taplink — настраиваются более или менее точно. Проблемы начинаются c платными каналами.

Изначально пробуем настроить работу распознавания источников заявок по utm. Отдельные площадки привязываем к домену реферера или конкретной utm источника типа {maps}. Instagram и Facebook привязываем с чуть большей вариативностью:

Создаем дэшборд по объекту с помощью предустановленного виджета. Получаем конфликт посещений и обращений: на 12 обращений — 10 посещений с одной и той же страницы. Значения посещаемости не верны.

Через несколько писем с поддержкой оказывается, что для сбора посещаемости на url необходимо создать заранее отдельный сегмент и потом его привязать к дэшборду. Согласны с тем, что нецелесообразно захламлять сервера записями всех посещений по всем страницам, если нужны только отдельные посадочные. Сбивает столку, что первая сессия и менеджеры никак на этот функционал не указывают. Настраиваем все сегменты в разделе "Аналитика"-"Сегменты", в который будут попадать посетители, которые перешли на нужную страницу.

Итак, мы подцепили нужный сегмент (посещения) в дэшборд и создали рекламные кампании (источники трафика). Теперь надо подтянуть расходы на рекламу из Facebook.

В процессе настройки синхронизации расходов приходит понимание, что настройка по utm — ошибочная стратегия. Не понятно почему ее до сих пор рекомендуют менеджеры CoMagic. CoMagic не обладает достаточной функциональной гибкостью, чтобы подгружать расходы в отчеты и дэшборды, самостоятельно вручную или с помощью csv выгрузок из Facebook. Также при настройке отчетов по объекту надо учитывать сложное устройство кабинета Facebook. На один объект могут приходиться разные рекламные кампании с разных ID рекламных аккаунтов и даже с разных Facebook Business manager.

Убрали сегменты по utm и установили сегмент "Интегрированные рекламные кампании Facebook", как отдельный источник трафика. Это стало возможно после синхронизации админского профиля Facebook, управляющего действующей рекламной кампанией.

Процесс синхронизации является самым нестабильным во всей системе CoMagic. Каждый id рекламного аккаунта Facebook надо было синхронизировать отдельно, и по ходу синхронизации какие-то кампании отваливались. Без изменений на клиентской стороне, на платформе менялось описание ошибки в течение 3 недель.

Проблему решили, но оказалось, что расходы по всем кампаниям не тянутся, т.к. при интеграции автоматически не добавилась в объявлениях необходимая метка cm_id. Метку пришлось добавлять во все объявления вручную, что, естественно, нарушило систему обучения Facebook и снизило количество заявок по всем кампаниям.

По итогу внедрения правки, приступаем к новой итерации сверки данных: Google.Analytics (посещаемость), Tilda (заявки), FB Business manager (Расходы). Находим еще 2 проблемы. CoMagic несмотря на успешную синхронизацию с формами FB (прямые лид-формы от FB), не может выводить информацию по ним в дэшбордах. Также в настройках виджета нельзя было поставить оператор "и", чтобы тянуть расходы из двух кампаний, а не одной.

Чтобы решить эти проблемы пришлось мигрировать все отчеты в новую версию Личного кабинета, о которой есть отдельная статья на vc. Здесь становится понятна ключевая проблема CoMagic: идет функциональное развитие именно нового кабинета, что тянет за собой меньший приоритет устранения багов на прошлом, конфликт функций, управление какими-то функциями в обоих кабинетах и т.д. В новом кабинете каждую неделю возникают проблемы:

• часть элементов интерфейса не кликабельна;
• конфликты в значениях данных, которые раньше были в порядке;
  
• проблемы с кэшем при обновлении страницы.

Помимо верхнеуровневых проблем с построением простой воронки по объекту, в CoMagic много мелких недочетов, которые приходится анализировать самостоятельно, т.к. саппорт не обладает техническим бэкграундом. Например, на платформе действует правило, которое считает равнозначными нижнее подчеркивание и дефис в урле, и поэтому объединяет данные по 2 разным страницам. Также на платформе есть объединение сессии вокруг одного пользователя, что удобно, чтобы видеть первый клик и вычленять повторные заявки.

При этом в дэшбордах эти заявки выводятся как разные — нельзя поставить фильтр на "качественные заявки".

В конце, немного про коммуникацию с CoMagic: очень много менеджеров, раздутый колл-центр, постоянная дезинформация, неправильные инструкции, постоянное перекидывание задач с менеджера на менеджера, при том факте, что "закрепленный менеджер", вроде как есть. Между ответами могут пройти недели. Сами менеджеры CoMagic допускают ошибки в настройке отчетов. Стоит подчеркнуть, что наша схема дэшбордов примитивна с точки зрения функционала платформы:

• строим посещаемость по сегменту к источнику заявок;
• строим заявки к источнику по интегрированным кампаниям;
  
• строим расходы по интегрированным кампаниям.
  

И это только попытка подключить один рекламный источник и классические лид-формы, а не заявки в мессенджерах, google.формы и т.д.

Из плюсов CoMagic: очень хороший потенциал платформы и быстрый баг-фикс. Несмотря на множество проблем, платформа тратила ресурс на их решение, хоть и иногда ломала что-то другое. Думаю, будет лучше, но через год, как протестят новый личный кабинет.