Квалифици­рованные заявки в Яндекс Метрике: передача и проверка офлайн-конверсий

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

Чтобы увидеть разницу, итог обработки нужно вернуть в аналитику. Метрика должна получить само событие квалификации и данные, по которым его можно связать с посещением сайта. Разберём этот путь на одной заявке: от рекламного визита до проверки загруженной офлайн-конверсии. Для примера используем ручную передачу CSV: этого достаточно, чтобы разобраться в формате данных и проверке результата.

Какой статус возвращать в Метрику

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

В компании по установке оборудования подходящим может считаться запрос из обслуживаемого региона на доступный тип работ с подтверждёнными условиями объекта. Для другой компании критерии будут иными. Формулировка должна позволять двум менеджерам одинаково оценить одно обращение. Статус «хорошая заявка» без критериев для этого слишком неопределённый.

Полезно разделить «не подходит», «спам», «дубль» и «пока не удалось связаться». Последний статус ещё не означает, что заявку оставил бот. Иначе качество кампании начнёт зависеть от того, в какое время менеджер попытался дозвониться.

События разных этапов могут понадобиться для анализа, но все они не обязаны одновременно становиться целями оптимизации. Если отправка формы и квалификация одного обращения считаются равнозначными успехами, реклама получает неоднозначную задачу. Сначала определяется результат, который бизнес хочет улучшить, затем — способ передавать его достаточно регулярно и точно.

Офлайн-конверсия в этой задаче — событие, которое произошло вне сайта: менеджер подтвердил подходящее обращение после разговора. Сам клиент при этом мог оставить форму онлайн. Такой маршрут соответствует описанию офлайн-конверсий Яндекса: внешний результат дополняет действия, уже известные веб-аналитике.

Как сохранить связь заявки с посещением сайта

Запись в CRM и визит в Метрике существуют в разных системах. Для сопоставления нужен поддерживаемый идентификатор, сохранённый вместе с обращением. Номер заявки внутри CRM помогает найти запись менеджеру, но сам по себе не сообщает Метрике, какой посетитель её оставил.

Для основного примера возьмём ClientID — идентификатор посетителя, который задаёт Метрика. Метод getClientID возвращает его строкой. На сайте значение получают при работающем счётчике и сохраняют вместе с отправленной заявкой. Реализация зависит от формы и системы приёма обращений; простое наличие счётчика ещё не означает, что идентификатор попал в CRM.

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

Если ClientID отсутствует, это отдельная техническая проблема. Подставлять случайное значение, чтобы заполнить обязательный столбец, бесполезно. Для новых обращений нужно наладить сохранение идентификатора; для прежних — выяснить, есть ли другие допустимые данные для привязки.

Когда подходят другие идентификаторы

UserID — собственный идентификатор посетителя, известный сайту. Связь с ClientID появляется у пользователей, для которых во время посещения вызывался метод setUserID. Произвольный ID из CRM, который никогда не передавался на сайте, этой связи не создаёт. Номер лида и идентификатор пользователя также могут обозначать разные сущности.

В правилах привязки офлайн-данных предусмотрены и другие варианты. yclid относится к рекламному клику из Директа; PurchaseId связывает дополнение с покупкой, ранее переданной через электронную коммерцию. PurchaseId нельзя использовать как любой номер заказа, о котором Метрика ничего не знает. Выбор идентификатора зависит от того, какую связь сайт действительно сохранил.

Телефоны и email поддерживаются в отдельных форматах импорта из CRM. Это другой способ передачи, со своими полями и правилами. Таблица телефонов сама по себе не позволяет надёжно восстановить рекламную атрибуцию: возможность загрузить контакт не означает, что система найдёт нужное посещение. В выбранный ниже CSV офлайн-конверсий столбец с телефоном вместо ClientID не добавляется.

Одна заявка: от визита до записи в CSV

Возьмём условную заявку на установку оборудования. Все данные в примере синтетические; часовой пояс счётчика — Москва, UTC+3.

• 10 октября 2026 года, 09:00. Человек переходит из объявления на сайт. Счётчик регистрирует визит, а сайт получает ClientID 1234567890.
• 10 октября, 09:10. Человек отправляет форму. В записи обращения сохраняются этот ClientID и время отправки.
• 11 октября, 10:30. После разговора менеджер подтверждает регион, тип работ и условия заказа. Заявка получает статус «Квалифицирована»; сохраняется время смены статуса.
• 12 октября, 09:00. Ответственный готовит и загружает запись о квалификации. В файл попадает время события 11 октября, а не время подготовки выгрузки.

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

Цель и минимальная запись

Для ручной загрузки в Метрике создаётся цель типа «Целевое событие». Название можно сделать понятным — «Квалифицированная заявка». Идентификатор события в нашем примере — qualified_lead. Именно идентификатор, а не название цели, используется в данных. Этот путь и состав полей описаны в инструкции по передаче и обработке данных.

Минимальный CSV для выбранной привязки:

ClientID,Target,DateTime
1234567890,qualified_lead,1791703800

ClientID связывает запись с посетителем. Target называет событие квалификации. DateTime содержит время этого события в Unix-формате, в секундах: 1791703800 соответствует 11 октября 2026 года, 10:30 по Москве. Файл сохраняется в UTF-8; названия столбцов здесь взяты из документации ручной загрузки.

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

Время события нельзя заменять временем визита ради удобной привязки. Для офлайн-конверсии Метрика ищет подходящее посещение с учётом идентификатора и времени; у ClientID и UserID это посещение, предшествующее событию. Если человек вернулся на сайт до квалификации, привязка может относиться уже к этому возвращению. Поэтому связь с визитом и трактовка рекламного источника требуют отдельной проверки по правилам сопоставления.

Передача через интерфейс

В счётчике используется путь «Настройка» → «Загрузка данных» → «Загрузка офлайн-конверсий». В окне загрузки выбирается тип привязки по ClientID и подготовленный файл. Комментарий к загрузке поможет потом найти конкретную партию в отчёте. Эти действия соответствуют инструкции ручной передачи.

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

Для регулярной работы тот же маршрут данных можно организовать через API офлайн-конверсий или подходящую CRM-интеграцию. У них свои требования к доступу и формату. Поля примера ручного CSV не стоит автоматически переносить в другой механизм: даже написание заголовков в документации API отличается. Прежде чем автоматизировать передачу, нужно получить понятный результат на одном полном маршруте заявки.

Где проверить, что получилось после загрузки

Успешная отправка файла отвечает только на первый вопрос: данные переданы. Дальше у одной записи есть несколько разных состояний, и каждое требует своего подтверждения.

1. Файл отправлен. Есть запись о загрузке выбранной партии. На этом этапе ещё неизвестно, прочитаны ли все строки и найдены ли визиты.

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

3. Событие связано с посещением. Проверка выполняется в отчёте «Отчёты» → «Сквозная аналитика» → «Офлайн-конверсии». В нём есть идентификаторы, событие, дата, загрузка и поле «Привязка к визиту». Для нашей записи ожидается положительный результат привязки; при отказе отчёт показывает причину. Состав проверки описан в справке отчёта.

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

4. Конверсия видна в аналитике. В нужном отчёте выбираются цель квалификации и подходящий период. Только привязанные конверсии используются в обычных отчётах и оптимизации; дата события и дата связанного визита могут отличаться. Это предусмотрено в описании отчёта офлайн-конверсий. В нашем примере визит относится к 10 октября, квалификация — к 11-му, загрузка — к 12-му. Считать эти даты взаимозаменяемыми нельзя.

5. Сигнал пригоден для стратегии. Цель должна быть доступна в нужной кампании, выбрана в её настройках и достаточно регулярно пополняться подходящими событиями. Корректно переданная единичная запись полезна для проверки интеграции. Она не устанавливает, хватит ли таких данных для обучения на дальнейшем потоке.

6. Улучшился результат бизнеса. Это уже вопрос о последующей работе рекламы: меняются ли качество новых обращений, продажи и затраты на привлечение. Факт загрузки не подтверждает коммерческий эффект. Его оценивают после накопления и обработки данных, с учётом других изменений в кампании и бизнесе.

Для рассматриваемой заявки завершённая техническая проверка означает следующее: статус в учёте соответствует событию, строка прочитана, найдена связь с визитом и квалификация видна в аналитике. Только затем появляется основание решать, как использовать такой поток событий в Директе.

Почему офлайн-конверсия не привязывается или выглядит неверно

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

Ситуация	Возможная причина	Где искать ответ
Посетитель не найден	В поле попал ID лида, значение округлено или отсутствует связь UserID с посещением	Исходная заявка, сохранённый идентификатор и настройка его передачи
Событие не распознано	Target содержит название, номер или другой идентификатор цели	Идентификатор события в настройках нужного счётчика
Неверная дата	Миллисекунды вместо секунд, другой часовой пояс, дата выгрузки вместо квалификации	Исходное время смены статуса и преобразование в Unix-формат
Нет подходящего визита	Посещение неизвестно счётчику, произошло позже события или не попало в окно привязки	Время события, посещения и обработки файла; причина в отчёте
Один лид выглядит как несколько событий	Повторная выгрузка статуса или повторное срабатывание в системе учёта	Журнал передач по заявке и переходам между статусами
Загрузка есть, результат ещё не виден	Обработка не закончена либо выбрана другая цель или период	Статус партии, фильтры отчёта и время ожидания
Конверсии корректны, но их очень мало	Редкая квалификация, долгий цикл или пропуски передачи	Полнота отправки и реальная частота целевого события

У привязки есть временное ограничение. В справке ручной передачи указано: если от последнего визита до начала обработки файла прошло больше 21 дня, добавить такие офлайн-конверсии к визиту не получится. Отчёт также проверяет время события относительно доступного окна. Это не универсальные «21 день после заявки»: нужно учитывать и посещение, и событие, и загрузку. Подробности описаны в правилах окна дополнения визитов.

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

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

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

Что делать со спамом и редкими качественными заявками

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

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

Передача нескольких квалифицированных лидов в месяц может сделать отчёт полезнее, но такой поток не даёт оснований обещать успешное обучение стратегии. Имеют значение регулярность событий, задержка статуса, доля успешно привязанных записей и доступный объём рекламы. Цель, которая точно отражает бизнес, иногда слишком редка для выбранного режима оптимизации.

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

Как организовать передачу без лишних данных

Для показанной записи достаточно идентификатора посетителя, события и времени. Имя, телефон, содержание разговора и комментарий менеджера не нужны этому формату. Подготовку можно проверять на синтетической заявке, сохраняя рабочие контакты в предназначенных для них системах.

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

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

Устойчивая передача начинается с согласованного значения статуса и сохранённой связи с посещением. Затем проверяется небольшой полный маршрут, налаживается регулярность и только после этого оценивается польза сигнала для рекламы. Если нужна работа с Яндекс Директом, данные о квалификации помогают обсуждать качество результата предметно: по подходящим обращениям, которые удалось корректно вернуть в аналитику.