В отчёте по Яндекс Директ есть конверсии, а отдел продаж подтверждает меньше обращений. Собственник спрашивает, почему рекламная система показывает результат, который компания не может найти в CRM. У маркетолога возникает другая задача: выяснить, какие цифры можно использовать при оценке кампаний.
Причиной бывает цель, срабатывающая при нажатии кнопки до отправки формы. Иногда одно обращение регистрируется несколькими событиями, а после обновления сайта часть целей перестаёт работать. Возможна и другая ситуация: форма отправляется, Метрика учитывает её корректно, но сведения об обращении теряются при передаче в CRM.
Для автоматических стратегий Яндекс Директ эти различия существенны. Выбранные конверсии влияют на оптимизацию показов, а ошибки отслеживания искажают представление о результате. Поэтому при работе с целями специалист проверяет последовательность от действия пользователя до зарегистрированного обращения и отдельно оценивает связь события с рекламой.
После прочтения статьи вы поймёте:
- Какие действия на сайте стоит считать заявками, а какие использовать для анализа поведения.
- Как организовать таблицу целей и выбрать способ регистрации формы, звонка или другого события.
- Что проверять, если Метрика фиксирует конверсию, а обращение отсутствует, или если заявка поступила без зарегистрированной цели.
- Почему достижения целей, целевые визиты и лиды в CRM могут различаться.
- Как выбирать события для автоматических стратегий, особенно при небольшом объёме заявок в B2B.
- Какую работу по проверке и сопровождению аналитики выполняет специалист после запуска рекламы.
1. Какие цели нужны бизнесу: основные обращения и промежуточные действия
Яндекс.Метрика регистрирует действия и условия, которые заданы в настройках целей: отправку формы, посещение определённой страницы, целевое JavaScript-событие, звонок из подключённой системы и другие события. Чтобы статистика была полезна, сначала определяют смысл каждого действия для бизнеса.
Основные конверсии отражают результат, который компания ожидает от сайта: успешную отправку заявки, запрос коммерческого предложения, запись, заказ или зарегистрированный целевой звонок. Дополнительные конверсии показывают промежуточное поведение: открытие формы, клик по номеру телефона, скачивание каталога или начало оформления заказа.
Для производителя промышленного оборудования отдельными основными действиями могут быть запрос расчёта, отправка технического задания и запрос КП. Специалист изучает каждую форму и выясняет, приводят ли эти действия к полноценным обращениям. Если один и тот же человек последовательно открывает форму, нажимает телефон и звонит, в аналитике могут появиться несколько событий. Для оценки числа лидов их смысл необходимо различать.
| Тип сайта | Основные конверсии | Дополнительные события |
|---|---|---|
| Сайт услуг | Отправка формы, запись, целевой звонок | Открытие формы, клик по телефону |
| B2B-производство | Запрос КП, заявка на расчёт, целевой звонок | Скачивание каталога, просмотр документации |
| Интернет-магазин | Оформление заказа, покупка | Добавление в корзину, начало оформления |
| Проектная организация | Отправка проекта на расчёт, запрос консультации | Просмотр кейсов, скачивание презентации |
Скачивание каталога в узком B2B может быть полезным сигналом. Но пока неизвестно, как часто скачивающие затем обращаются, использовать такие события вместо заявок рискованно. Специалист сопоставляет поведение с доступными данными об обращениях и учитывает возможные некоммерческие сценарии: каталог могут изучать студенты, конкуренты и действующие клиенты.
2. Как составить рабочую таблицу целей
На сайте с несколькими формами и внешними сервисами настройки быстро становятся труднообозримыми. Единый реестр позволяет согласовать работу директолога, разработчика и заказчика, а после изменений сайта — проверить, какие события могли перестать передаваться.
В таблице фиксируют название и бизнес-смысл цели, тип регистрации, идентификатор события или URL, способ тестирования и применение в Директе. Для крупных проектов добавляют страницу размещения, источник данных, владельца настройки и дату последней проверки.
В рабочей таблице для сайта услуг можно отдельно указать отправку заявки, запрос расчёта, звонок, открытие формы и скачивание презентации. Для каждого события следует зафиксировать способ проверки и назначение: оптимизация рекламной стратегии или дополнительная аналитика.
Пример таблицы целей для сайта услуг. Для каждой конверсии указаны условие регистрации, проверка корректности и назначение в рекламных стратегиях. (Условные обезличенные данные.)
Для JavaScript-событий полезен единый принцип именования:
| Действие | Условный идентификатор |
|---|---|
| Успешная отправка общей заявки | request_form_success |
| Запрос расчёта | estimate_form_success |
| Запрос КП | proposal_form_success |
| Заказ обратного звонка | callback_form_success |
По таким идентификаторам удобно проверять разные формы. Если события объединены в одну цель, специалист должен понимать, где сохраняется детализация и как она используется в отчётах. Для основных обращений особенно важно избежать случайного совпадения технических условий.
Изменение действующих целей требует отдельной подготовки. Нужно установить, где цель выбрана для оптимизации, сохранить прежние идентификаторы в документации и учитывать возможный разрыв исторических показателей. Удалять старые цели ради переименования опасно: доступность ранее собранных данных в отчётах может быть потеряна.
3. Как Метрика получает события: формы, JavaScript и телефония
Одинаковый для посетителя результат может иметь разную техническую реализацию. Обычная HTML-форма, форма без перезагрузки страницы и форма в стороннем виджете требуют разных проверок. Специалист сначала устанавливает, как сайт подтверждает успешное действие, затем выбирает механизм регистрации.
| Способ | Когда подходит | Риск, который нужно проверить |
|---|---|---|
| Автоматическая цель Метрики | Поддерживаемые типовые события | Регистрируется ли предусмотренное действие |
| Цель «Отправка формы» | Поддерживаемые формы сайта | Не засчитывается ли неудачная попытка |
| Посещение страницы благодарности | Переход по URL после отправки | Можно ли открыть страницу без новой заявки |
| `reachGoal` | Событие определяется логикой сайта | Не вызывается ли оно раньше подтверждения |
| Коллтрекинг | Телефонные обращения | Корректно ли передаются звонки и их связь с визитом |
Если форма ведёт на страницу благодарности
Допустим, после отправки заявки сайт открывает https://example.com/thank-you/. В Метрике можно создать цель «Посещение страниц» с условием для этого адреса. Далее проверяют, появляется ли страница только после успешного действия. При прямом открытии или обновлении страницы достижение URL-цели может возникнуть без нового обращения. В таком случае специалист обсуждает с разработчиком корректировку логики или другой способ отслеживания.
Если форма работает без перезагрузки
Для таких сценариев удобно целевое JavaScript-событие. В Метрике создают цель с идентификатором request_form_success, а на сайте предусматривают вызов:
ym(12345678, 'reachGoal', 'request_form_success');
Пример настройки JavaScript-цели в Метрике: идентификатор события должен соответствовать значению, которое сайт передаёт через reachGoal.
Номер счётчика в примере условный. Смысл настройки определяется моментом вызова: для учёта успешной заявки событие должно передаваться после подтверждения выполнения предусмотренной операции. При вызове на нажатии кнопки в отчёт может попасть неуспешная попытка отправки. Кроме того, успешный ответ сайта ещё не всегда подтверждает доставку данных во внешнюю CRM, если передача выполняется отдельным процессом.
Специалист описывает разработчику условие срабатывания, проверяет совпадение идентификаторов, проводит тест отправки и сопоставляет событие с фактическим обращением. При необходимых доступах и согласованном объёме работ JavaScript-событие может настраиваться непосредственно специалистом агентства.
Если обращения приходят по телефону или через мессенджер
Клик по tel: отражает нажатие телефонного номера. Сведения о реальном звонке предоставляет телефония или коллтрекинг. В такой системе может учитываться длительность, статус ответа и повторность звонка. Порог по длительности разговора описывает техническое условие, но сам по себе не подтверждает коммерческую пригодность обращения.
Переход в мессенджер также следует отличать от отправленного сообщения. Специалист выясняет, что именно способен передавать используемый сервис, и фиксирует ограничения в реестре целей. Если один звонок одновременно представлен кликом и событием из коллтрекинга, обе цели могут сохраняться для аналитики, но не должны автоматически суммироваться как два лида.
4. Как проверить цель и отличить техническое событие от обращения
Удобная модель диагностики включает четыре точки контроля:
Действие пользователя → событие в Яндекс.Метрике → атрибуция в рекламной статистике → фактическое обращение в системе компании.
Схема показывает путь конверсии от действия пользователя до обращения в CRM и помогает определить, на каком этапе возникают потери данных, ошибки атрибуции или сбои передачи.
Сбой возможен на любом участке. Если не передаётся reachGoal, искать причину в CRM преждевременно. Если событие зарегистрировано, а заявка отсутствует в системе обработки обращений, проверяют дальнейшую передачу. Когда все данные получены, но рекламный источник определяется неожиданно, проверяют атрибуцию и интеграции.
Отладчик Яндекс.Метрики
К адресу проверяемой страницы добавляют параметр _ym_debug=2, например https://example.com/contact/?_ym_debug=2. После загрузки выполняют действие и просматривают информацию в панели отладки. Нужно проверить номер счётчика, идентификатор события и появление достижения в отчётах с учётом возможной задержки обработки. Для предыдущего кода счётчика Яндекс предусматривает проверку через консоль браузера. Если действует фильтр «Не учитывать мои визиты», тест проводят с учётом этого ограничения.
Полная инструкция размещена в справке Яндекс.Метрики.
В отладчике Метрики видно событие request_submit, переданное сайтом после действия с формой. Для подтверждения успешной заявки дополнительно проверяют её фактическое получение.
Матрица тестирования формы
| Сценарий | Ожидаемое поведение основной цели |
|---|---|
| Корректно заполненная форма успешно отправлена | Цель достигается |
| Обязательное поле осталось пустым | Цель успешной заявки не достигается |
| Ошибка проверки номера или email | Нет успешной конверсии |
| Несколько нажатий на кнопку создали одну заявку | Нет дополнительных фиктивных обращений |
| Страница благодарности открыта напрямую | Не возникает новая фактическая заявка; возможность срабатывания URL-цели отдельно оценивают |
| Форма отправлена из мобильной версии или модального окна | Достижение фиксируется по той же согласованной логике |
| Форма обновлена разработчиками | Цель продолжает работать после повторного теста |
Для внешних форм, iframe, нескольких доменов и динамической загрузки страниц проверяют дополнительные сценарии. Одинаково оформленные формы могут использовать разные обработчики, поэтому выборочной проверки одного элемента не всегда достаточно.
Как проверить рекламный источник
Специалист убеждается, что событие поступает в нужный счётчик, затем проверяет доступные данные о визите и источнике. При переходах между доменами, работе сторонних форм и подмене телефонных номеров возможна потеря ожидаемой связи с рекламным переходом. Такие расхождения требуют проверки конкретной конфигурации и модели атрибуции. Тестовая заявка может подтвердить часть цепочки, однако для полноценного вывода её сопоставляют с рабочими данными.
Подробности сопоставления источников и методики отчётности вынесены в статью «Какие отчёты по рекламе в Яндекс Директ должен предоставлять подрядчик».
5. Почему возникают ложные конверсии и дубли
Три внешне похожих расхождения требуют разных действий: неуспешная заявка засчитана как конверсия; одно обращение породило несколько событий; реальное обращение не появилось в аналитике. Перед исправлением нужно выяснить, какой именно случай произошёл.
| Симптом | Возможная причина | Решение специалиста |
|---|---|---|
| Заявка поступила, цель отсутствует | Не вызывается событие, изменился обработчик | Проверить код и восстановить регистрацию |
| Цель достигнута без заявки | Срабатывание до успешной отправки | Перенести момент вызова или изменить способ учёта |
| Одно обращение соответствует нескольким целям | Клик, отправка формы, переход на страницу благодарности | Разделить назначение событий и правила подсчёта |
| Одинаковое событие отправлено повторно | Дублирующий обработчик | Устранить лишние вызовы |
| Звонки зарегистрированы, но не видны в Метрике | Ошибка передачи из телефонии | Проверить интеграцию и условия цели |
| После обновления сайта конверсии исчезли | Изменился код формы | Повторно протестировать затронутые сценарии |
В течение одного целевого визита Метрика может зафиксировать несколько достижений одной цели, но на одном счётчике регистрирует достижение этой цели не чаще одного раза в секунду (правила подсчёта достижений). Это ограничение не заменяет корректную обработку повторных обращений. Например, если сервер создал одну заявку после нескольких нажатий кнопки, регистрация успешного действия должна соответствовать фактическому результату. Когда пользователь самостоятельно отправил два разных обращения, их дальнейший учёт зависит от принятых компанией правил.
Почему в Директе, Метрике и CRM разные цифры
В Метрике есть показатели достижений целей, целевых визитов и целевых посетителей. CRM использует собственные правила создания и объединения обращений. Дополнительно на результат влияют периоды анализа, атрибуция, статус звонка и повторные действия одного пользователя. Поэтому численное расхождение сначала проверяют на сопоставимость показателей, а уже затем ищут технические ошибки.
Если сама посадочная страница не позволяет пользователю завершить обращение, потребуется отдельный аудит её работы. Диагностика таких ситуаций описана в материале «Как понять, что проблема не в Яндекс Директе, а в сайте».
6. Какие цели выбрать для автоматических стратегий Яндекс Директ
Автоматическая стратегия использует выбранные события как сигналы для оптимизации. Поэтому специалист оценивает три характеристики цели: достоверность регистрации, частоту достижения и связь с коммерческим результатом. Для принятия решения важны также бюджет, ограничения кампании и распределение конверсий между рекламными сегментами.
| Ситуация | Предпочтительный подход |
|---|---|
| Полноценные заявки стабильно фиксируются | Рассматривать их как основные цели оптимизации |
| Есть несколько сопоставимых типов обращений | Проверить совместное использование и пересечения |
| В узком B2B очень мало заявок | Проверить полноту данных и условия стратегии до перехода на промежуточные события |
| Много скачиваний или открытий форм | Не назначать им ценность заявки без подтверждённой связи с обращениями |
| Клик по телефону и звонок используются одновременно | Разделить ценность этих событий и модель учёта |
| Расхождение Метрики и CRM не объяснено | Сначала провести диагностику, затем менять цели стратегии |
Пример решения при небольшом количестве заявок
Представим условную B2B-кампанию: за месяц зарегистрировано четыре заявки через формы, есть телефонные обращения и заметно больше скачиваний технического каталога. На основании этих цифр нельзя сразу выбрать скачивание как основную цель.
Специалист сначала выясняет, все ли обращения отражены в Метрике, правильно ли поступают события телефонии и соответствуют ли четыре формы уникальным заявкам. Если обнаружены дополнительные полноценные обращения, появляется основание рассмотреть несколько основных целей совместно. Затем оцениваются ограничения стратегии и достаточность данных на уровне кампании.
Если решение всё же связано с промежуточным событием, проверяют его связь с последующими обращениями и задают соответствующую относительную ценность. Результат такого изменения оценивают по реальным лидам, поскольку рост скачиваний сам по себе не подтверждает улучшения лидогенерации. Это сценарий принятия решения, а не результат конкретного клиентского кейса.
Как несколько целей влияют на оплату
В стратегии с оплатой за конверсии при достижении двух разных выбранных целей в одном визите могут происходить два списания. Например, если условная цена оформления заказа составляет 1 000 ₽, а оплаты — 2 000 ₽, достижение обеих целей может привести к расходу 3 000 ₽. Повторное достижение одной и той же цели в рамках визита оплачивается по отдельному правилу: одно списание по установленной цене. Это следует учитывать при выборе последовательных этапов одной воронки.
Яндекс рекомендует оценивать общую экономику стратегии с несколькими целями, в том числе средневзвешенную целевую стоимость и фактический расход. Подробная механика приведена в официальной инструкции.
Для оценки качества обращений после отправки формы могут потребоваться сведения из CRM — квалификация, сделки, оплаты. Передача офлайн-конверсий и данных CRM решает отдельную задачу и требует собственной проверки. В статье об онлайн-целях достаточно установить границу: сначала проверяют регистрацию обращения, затем при наличии данных оценивают его дальнейший результат.
7. Как специалист поддерживает корректность целей при ведении рекламы
После запуска рекламных кампаний сайт продолжает меняться: обновляют формы, подключают виджеты, заменяют телефонию и CRM. Каждое такое изменение может повлиять на регистрацию целей. Работа с аналитикой поэтому включает контроль изменений и разбор аномалий статистики.
На этапе подготовки специалист проверяет все значимые точки обращения, фиксирует их в реестре, согласовывает способ регистрации и тестирует основные сценарии. Если требуется изменение кода, готовит техническое задание разработчику или выполняет работу самостоятельно в пределах согласованной зоны ответственности.
Во время ведения рекламы проверка становится адресной. Резкое исчезновение конверсий при сохранении фактических заявок указывает на необходимость проверки целей. Рост достижений без соответствующего роста обращений требует анализа состава событий и возможных повторов. После изменения интеграции проверяют прежде всего затронутый участок передачи данных.
| Когда возникла ситуация | Что делает специалист | Какое решение получает бизнес |
|---|---|---|
| Кампания готовится к запуску | Тестирует основные цели и поступление заявок | Можно оценивать рекламу по согласованным событиям |
| На сайте заменили форму | Проверяет её обработчик и достижение цели | Подтверждена корректность новой версии или назначено исправление |
| Конверсии резко снизились | Сверяет реальные обращения и передачу событий | Разделены возможные причины: спрос, реклама, технический сбой |
| Конверсии выросли без роста лидов | Проверяет дубли, новые цели, логику формы | Определено, можно ли доверять увеличению показателя |
| Обновлена телефония или CRM | Сопоставляет записи и передачу данных | Выявлены участки, требующие дополнительной проверки |
При подтверждённом сбое важно установить период его действия. Если основная цель перестала работать после релиза сайта, данные за затронутые дни нельзя без поправок сопоставлять с предыдущими периодами. Также нужно проверить, использовалась ли эта цель в автоматической стратегии, и оценить последствия для дальнейшего управления кампанией.
Не каждое расхождение агентство может разрешить без участия заказчика. Для сверки реальных заявок и квалификации лидов нужны доступ к соответствующим данным и согласованные правила учёта. Поддержка аналитики включает постановку конкретных задач разработчику и проверку результата, а также совместную работу с ответственными за CRM и телефонию.
Ценность регулярного сопровождения проявляется в качестве решений по рекламе. Специалист определяет, какие данные достоверны, находит причины аномалий и учитывает технические ограничения до изменения стратегий или перераспределения бюджета.
Заключение
Цели Яндекс.Метрики полезны бизнесу, когда можно объяснить происхождение каждого основного события и проверить его связь с фактическим обращением. Наличие большого количества целей само по себе не делает аналитику точнее.
При изменениях сайта и интеграций необходимо сохранять правила регистрации, повторно тестировать затронутые действия и отдельно учитывать периоды некорректных данных. Это помогает оценить, насколько показатели пригодны как основание для оптимизации, контроля CPL и планирования бюджета.
