Аналитика amoCRM

Это первый вопрос по такому заказу, и он справедливый. Ответ — в четырёх местах, где встроенный конструктор отчётов не помогает вообще.

Канал берётся не из поля «источник», а выводится правилом

В живой CRM канал обращения лежит где угодно: в utm-метке, в поле «Откуда узнали», в тексте, который подставила форма на сайте. Конструктор отчётов amoCRM умеет сгруппировать по значению поля целиком — и на этом всё. «Instagram», «instagram_stories» и «ig» станут тремя разными каналами, а «заявка с лендинга по ремонту» не станет ничем.

Мы завели свою модель канала: любое поле + условие + значение → канал. Условий четыре — равно, содержит, начинается с, заканчивается на. Правил сколько угодно, они складываются, и заказчик заводит их сам в админке, без нас.

Главное здесь — что вывод не остаётся у нас в базе. Система пишет канал обратно в amoCRM тегом на сделке. То есть чинит данные в самой CRM: менеджер видит размеченную сделку у себя, а не в чужом отчёте, до которого он не дойдёт.

Заявки, под которые не подошло ни одно правило, идут отдельной строкой «Канал не определён». Мы не размазываем их по остальным каналам и не прячем — эта строка честно показывает, сколько разметки ещё не хватает.

Доля заявок, у которых реально есть телефон

Отдельная колонка отчёта — «с контактами». Считается не наличие контакта у сделки, а непустой номер телефона внутри контакта: система дотягивает контакты пачками и смотрит в поля с кодом PHONE и названиями «Телефон» / «Phone».

Разница принципиальная. Сделка с прицепленным пустым контактом в amoCRM выглядит ровно так же, как настоящее обращение, — и в любом встроенном отчёте считается наравне с ним. Здесь мусорные обращения отделены от тех, с кем можно связаться, и видно это по каждому каналу отдельно. Канал, который гонит объём без телефонов, вылезает сразу.

Расходы на рекламу, которых в CRM нет вообще

В amoCRM нет и не может быть данных о том, сколько потрачено на рекламу. Поэтому любой встроенный отчёт отвечает на вопрос «сколько пришло», но никогда — «сколько это стоило».

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

Отчёт получают люди без лицензии amoCRM

Отчёт собирается по расписанию — день, неделя, месяц, квартал, полугодие, год — и уходит файлом в Telegram сразу нескольким адресатам.

Это не про удобство, это про деньги. Цифры нужны владельцу, инвестору, маркетологу на аутсорсе — людям, которым незачем сидеть в CRM каждый день. Чтобы посмотреть встроенный отчёт, каждому из них надо оплатить место в amoCRM. Здесь не надо: отчёт приходит сам, в мессенджер, который у них и так открыт.

Это самая честная часть кейса, и видна она не по итоговому коду, а по истории правок.

Первая версия делала очевидное: amoCRM присылает уведомление об изменении сделки, в уведомлении лежат данные — берём и сохраняем. Дальше в репозитории идёт больше десяти коммитов подряд по одному файлу, и названия у них говорящие: «Внедрил вебхук» → «Fix — отсутствие тегов в вебхуке» → «Ещё одно багованное изменение» → «Откат к старой версии».

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

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

Мы пишем об этом прямо, потому что так и выглядит настоящая работа: не «сделали по документации с первого раза», а «уперлись, откатились и заменили источник данных». Ошибка здесь стоила бы не падения, а неверных решений по рекламе на неверных цифрах.

Раз система проставляет теги в боевой CRM, у неё появляется право сломать чужую работу.

Наивная правка сделки заменяет список тегов целиком — и вместе со своим каналом стирает всё, что руками расставили менеджеры. Цена ошибки несимметричная: разметку в CRM никто не откатит, восстанавливать её нечем и неоткуда.

Поэтому запись сделана добавлением, а не заменой — и в amoCRM, и в своей базе: свой тег прибавляется к существующим, чужие не трогаются. Одна строчка разницы в коде, а последствия — на всём отделе продаж.

Редкая часть работы: цифры показываются не только в отчёте, но и плитками на рабочем столе самой amoCRM — рядом с родными.

Что за этим стоит:

• платформа не даёт встроенному окну доступа к своему API — оттуда нельзя спросить у CRM ничего. Единственное, что во фрейм приходит, — параметры адреса, поэтому выбранный период передаётся именно ими, включая произвольный диапазон дат;
• внешний вид родной плитки воспроизведён вручную — прозрачный фон, белый текст, те же кегли и отступы, и даже зелёная и красная стрелки роста нарисованы своими и вшиты картинками прямо в стили. Виджет не должен выглядеть чужим на рабочем столе, иначе им не пользуются;
• сравнение с предыдущим периодом считается честно — берётся отрезок ровно такой же длины, стоящий встык, а не «прошлый месяц» в календарном смысле;
• каждая плитка настраивается: количество, сумма, среднее или конверсия, с фильтрами по каналам, воронкам, этапам и менеджерам, одним числом или списком с разбивкой.

Проект передан заказчику, доступа к его статистике у нас нет — сколько сделок прошло через систему и что изменилось в его продажах, мы не знаем. Придумывать проценты роста ради красивой карточки не будем: в соседних кейсах цифры есть, и они настоящие — Topar, Acuvue, SitWell.

Что в этом кейсе проверяемо — устройство. Модель канала с обратной записью, отделение заявок с телефоном от пустых, расходы и формулы в файле, отказ доверять вебхуку. Это и есть работа, за которую платят, когда «в CRM же есть отчёты».