На схеме всё обычно выглядит просто: реклама привела посетителя, тот оставил контакты, менеджер закрыл сделку. В рабочей системе между этими точками помещается целая цепочка. Человек может несколько раз вернуться на сайт, написать с другого устройства, позвонить вместо отправки формы или оставить две одинаковые заявки. Менеджер тем временем меняет статус в CRM, а маркетолог сверяет цифры в рекламном кабинете.
Если каждый сервис хранит только свой фрагмент истории, отчёт начинает расходиться с реальностью. Поэтому интеграция сайта с CRM и рекламной аналитикой начинается не с графиков. Сначала нужно договориться, что именно считать визитом, заявкой, квалифицированным обращением и результатом.
Заявка открывает процесс, но не завершает его
Форма на сайте сообщает лишь о том, что посетитель передал данные. Она ещё ничего не говорит о качестве контакта, намерении купить и фактическом результате. У заявки должен быть собственный идентификатор, время создания, источник, связанный пользователь и история статусов. Без истории невозможно понять, когда обращение взяли в работу, почему отклонили и на каком этапе возникла задержка.
Во внутренней платформе WowCash уже используется связка «пользователь, заявка, статус». Для проекта клиента эту модель можно расширить под его процесс: добавить направления бизнеса, ответственного менеджера, причину отказа, сумму или иной подтверждаемый итог. Состав полей определяется задачей, а не универсальным шаблоном CRM.
Похожий подход мы применяли при разработке большой торговой платформы. В кейсе LaLaZa видно, почему объявления, продавцы, обращения и действия пользователей приходится рассматривать как связанные сущности, а не как отдельные экраны.
События нужно определить до построения отчёта
У перехода, сессии, целевого действия и продажи разный смысл. Если назвать всё конверсией, цифры будут выглядеть убедительно, но принимать решения по ним станет трудно. Для аналитической модели обычно выделяют несколько уровней:
- источник перехода и рекламные параметры;
- визит или сессию пользователя;
- значимое действие на сайте;
- создание заявки;
- квалификацию обращения;
- подтверждённый коммерческий результат.
У каждого события должны быть время, источник, идентификатор и понятные правила повторной отправки. Например, обновление страницы не должно создавать вторую заявку, а повторный запрос CRM не должен дважды записывать одну продажу.
Как проектируется интеграция сайта с CRM
CRM, учётная система и сайт редко используют одинаковые названия и статусы. На сайте может быть «новая заявка», в CRM — «неразобранное», а в учётной системе уже «заказ покупателя». Поэтому до разработки составляют карту соответствий: какие поля передаются, кто считается источником истины и что происходит при изменении записи с каждой стороны.
Обмен строится через документированный API. Он проверяет права, формат данных и допустимые переходы между статусами. Если внешняя система временно недоступна, операция не должна исчезать: её ставят в очередь, повторяют и записывают результат. Для спорных случаев нужен журнал, по которому можно восстановить последовательность действий. Именно так мы подходим к интеграциям API, CRM и 1С.
Та же архитектура определяет, кто имеет право читать или менять сведения. Отдельно настраиваются роли сотрудников, пользовательские сессии и ключи для внешних систем. Подробнее об этой основе рассказываем в материале о том, как устроены API, роли и доступ ИИ-агентов в AdminCore.
Атрибуция отвечает на вопрос, но не заменяет факты
Первый источник, последний переход и текущий канал описывают разные части пути клиента. Первый контакт помогает оценить, где человек узнал о продукте. Последний показывает, что предшествовало заявке. Текущий источник полезен при анализе повторных визитов. Ни одна из этих моделей сама по себе не является окончательной истиной.
При проектировании модуля атрибуции разумно хранить исходные события и рассчитывать несколько представлений поверх них. Тогда маркетолог может сравнить модели, не переписывая историю. При этом важно честно учитывать ограничения: потерянные параметры перехода, разные устройства, очистку браузера, звонки и офлайн-контакты. Сквозная аналитика не восстановит сведения, которые система не получила.
Партнёрские ссылки и антифрод как отдельные модули
Если бизнес работает с партнёрами, к общей цепочке добавляются идентификатор партнёра, переход, заявка и подтверждённый результат. Вознаграждение безопаснее рассчитывать по проверяемому событию, а не по самому клику. Правила дедупликации, окно атрибуции и основания для отклонения фиксируются заранее.
Антифрод в такой системе представляет собой набор сигналов и правил. Он может отмечать подозрительную частоту действий, повторяющиеся контакты, аномальные источники или несовпадение этапов. Это не обещание автоматически распознать любой обман. Хороший модуль показывает причину срабатывания, сохраняет исходные данные и оставляет возможность ручной проверки.
Запускать лучше поэтапно
Попытка сразу соединить сайт, все рекламные площадки, CRM, телефонию и учёт часто затягивает запуск. Надёжнее начать с одного маршрута: источник, визит, заявка, статус, подтверждённый результат. После сверки данных подключаются дополнительные каналы и сценарии.
- Определяем бизнес-результат и ключевые статусы.
- Проверяем, какие данные уже собираются и где возникают разрывы.
- Проектируем идентификаторы, события и правила дедупликации.
- Подключаем один рабочий процесс CRM через API.
- Настраиваем журнал ошибок и регулярную сверку.
- Расширяем аналитику, партнёрские механики и контроль качества данных.
Такой порядок даёт бизнесу не декоративный отчёт, а проверяемую цепочку от обращения до результата. Видно, откуда пришла заявка, что происходило после неё и на каких данных основан вывод. Если вам нужно связать сайт, CRM и рекламную аналитику под собственный процесс, расскажите команде WowCash о задаче. Начнём с маршрута данных и соберём решение вокруг реальной работы компании.