Одна цель на все формы: как выглядит аналитика, которая считает не то
Разбор одного сайта производителя семян, сделанный из открытого кода без доступа к кабинету: счётчик стоит на всех страницах, запись действий включена, идентификатор посетителя уходит на сервер при каждой загрузке — одна из предпосылок сквозной аналитики есть. И при этом в доступном коде две разные формы вызывают одну и ту же цель.
Оговорка, без которой дальше нельзя
Это разбор одного сайта, а не статистика по отрасли. Мы не утверждаем, что так устроено у всех: сегментного замера настроек аналитики не делали, потому что из открытого кода их видно не всегда.
Но конструкция ошибки типовая, и поэтому её стоит разобрать: она возникает не от небрежности, а от того, что цель ставят один раз при запуске сайта, а формы добавляют потом.
Что ломается от одной цели
Форма вопроса по продукту и форма отзыва о компании отправляются на разные адреса обработчика — технически они уже различаются. Но в доступном коде обе вызывают одно и то же событие аналитики. Есть ли в кабинете дополнительные цели и какие из них идут в отчёты, без доступа к кабинету не проверить.
Если отчёт строится по этой общей цели, происходит следующее:
• достижений цели больше, чем обращений — в них попадают отзывы;
• стоимость обращения занижена — делится на раздутый знаменатель;
• каналы сравнить нельзя — у каждого своя доля отзывов, и она неизвестна;
• по одному событию прошлое не разделить — в нём не сохранено, чем именно оно было.
Последний пункт важнее всего. Частично восстановить прошлый период иногда можно по другим журналам — журналу заявок, CRM, адресам страниц, где сработала форма. Есть ли такие данные у разобранного сайта, по открытому коду неизвестно. Но из самой аналитики разделение уже не достать.
Отдельная строка — телефонные ссылки. На странице «где купить» их могут быть десятки: федеральный номер, номера региональных менеджеров, руководители по макрорегионам. Клик по каждому — попытка контакта, но в доступном коде явного вызова цели на них нет. Метрика умеет автоцели по телефонным ссылкам — они включаются в кабинете, и их мы не видели. В категории, где семь показов из десяти по коммерческой фразе приходятся на телефон, звонок часто и есть основной способ обращения.
Рабочая карта целей
Двенадцать целей и четыре механизма, в три очереди — не по важности, а по тому, на чём их физически можно измерить сегодня.
Первая неделя, на существующих страницах:
Дальше по воронке — квалифицированное обращение и продажа; они живут уже в CRM, а не в целях сайта.
Второй поток, когда появятся страницы, на которых это можно измерить: pdf_download, filter_apply, article_read, region_select, contact_scroll.
Параллельно — не цели, а то, без чего цели не читаются: параметры визита по региону и культуре, UTM в скрытых полях формы, первый источник в хранилище браузера с записью в CRM при первом обращении, регулярная загрузка статусов офлайн-конверсиями.
Единственное правило, из которого следует всё остальное: одно действие — одна цель. Заявка и отзыв разделяются на уровне события, а не отчёта. Клик по федеральному номеру и по номеру регионального менеджера — разные цели, чтобы видеть, куда звонят; разные номера сами по себе не доказывают разные стадии решения. Клик — ещё не обращение: он может не закончиться звонком, а один звонок может дать несколько кликов. Поэтому стоимость обращения считается по дедуплицированным полученным обращениям, а у кликов по телефону и мессенджеру — своя цена микроконверсии. Отзывы остаются в отчёте: это тоже результат, просто другой.
Три правки, которые дают почти всё
Разделить формы. Вместо одного события на обе формы — два, плюс параметры визита. Параметры важнее, чем кажется: без них отчёт читается как «обращений стало больше», а с ними — как «Поволжье, рапс, стадия бронирования». Это разные документы для принятия решения.
Поймать телефонные клики одним обработчиком. Ставить цель на каждую ссылку вручную бессмысленно: их десятки, и список меняется. Один делегированный обработчик на клик по a[href^="tel:"] покрывает все, а признак «федеральный номер или менеджер» берётся из data-атрибута ссылки.
Запомнить первый источник. При первом визите метки из адреса строки вместе с реферером и отметкой времени кладутся в хранилище браузера и больше не перезаписываются. Перед отправкой формы это значение подставляется в скрытое поле.
Почему источник надо сохранять в CRM
Три разных ограничения, которые часто сливают в одно «окно»: срок жизни метки в браузере, период атрибуции в рекламной системе и срок загрузки офлайн-данных.
111 дней — не добавка к 21, а срок правки уже привязанного заказа. Окна 90 и 180 дней покрывают часть цикла. Точнее так: часть длинных сделок выходит за ограничения отдельных механизмов. Сверху — браузер: по оценке АРИР (2024–2025), около 40 % трафика уже фактически без стабильных cookie — из-за ограничений браузеров, VPN и других причин; Safari удаляет созданное скриптами хранилище после семи дней без взаимодействия с сайтом.
Практический итог: октябрьская работа, давшая февральский договор, в браузерной атрибуции часто выглядит как прямой заход. Не «канал не сработал» — «канал не виден». Разница принципиальная: в первом случае бюджет режут, во втором чинят учёт.
Связка такая: первый источник из хранилища браузера подставляется в скрытое поле формы, при первом обращении попадает в CRM и дальше хранится у карточки хозяйства — уже независимо от браузера и устройства. Условие одно: источник должен быть сохранён до того, как метка потеряется. Если в октябре посетитель остался анонимным, а в феврале написал с другого устройства, CRM прошлый визит не восстановит. И «первый источник компании» — не то же, что первый источник конкретной сделки. Отчёт строится когортами по месяцу первого контакта, а не сквозным итогом за период.
Предпосылка, которая часто уже есть
Проверьте у себя до того, как закладывать бюджет на коллтрекинг и сквозную аналитику.
Если счётчик передаёт идентификатор посетителя на ваш сервер при загрузке страницы, одна из предпосылок сквозной аналитики у вас есть. Дальше нужно, чтобы идентификатор попадал в конкретную заявку, связывался со сделкой и сохранялся, а атрибуция считалась по понятным правилам. Звонок так не свяжется: человек, прочитавший номер и набравший его вручную, с идентификатором не связан — для этого нужен коллтрекинг или другой механизм связи звонка с визитом.
Наличие вызова в коде проверяется за пять минут: открыть исходный код страницы и поискать обращение к методу получения идентификатора клиента. Работает ли вся цепочка — проверяется только тестовой заявкой и тестовым звонком.
Порядок работ
1. Неделя первая: семь целей первой очереди, разделение заявки и отзыва, делегированный обработчик телефонных ссылок, параметры визита.
2. Неделя вторая: UTM в скрытые поля, первый источник в хранилище браузера, передача его в CRM при первом обращении.
3. До запуска рекламы: реклама не включается, пока цели не приняты. Гнать трафик на неразмеченный сайт — тратить бюджет на подтверждение уже известной проблемы.
4. Сразу после запуска — регулярно: загрузка обращений и обновлений статусов офлайн-конверсиями, не реже чем позволяет 21-дневный срок привязки. Через квартал — первая аналитическая сверка когорт.
Чего этот разбор не доказывает
Это один сайт, а не статистика по отрасли.
Разметка из кода видна не полностью — часть событий и автоцели настраиваются в интерфейсе счётчика. Вывод о том, насколько искажена фактическая стоимость обращения, можно делать только после проверки кабинета и отчётов.
Сроки платформ меняются. Все интервалы приведены на сентябрь 2026 года и требуют перепроверки перед внедрением.
Комментарии (0)