Кейс: 12 продаж загрузили спустя 24 дня — Метрика не нашла рекламный источник

Продажи были — доказательства опоздали

Сценарий начинался без тревожных признаков. Заявка приходила с рекламы, менеджер делал расчёт, замерщик выезжал, а заказ переходил в производство.

Проблема появлялась после оплаты. CRM собирала сделки весь месяц, а затем одним файлом отправляла их в аналитику.

По правилам Метрики офлайн-конверсию нужно передать в пределах периода учёта. В этой модели записи ушли на загрузку через 24 дня — позднее допустимого окна.

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

Три дня выглядят мелочью, но меняют решение

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

Если смотреть только на отчёт, картина получается убедительной и ложной одновременно: расход есть, заявки есть, а продаж из Директа будто нет.

Отсюда рождается дорогая ошибка: владелец режет ставки или отключает кампанию, которая могла приводить покупателей. Основанием становится не экономика, а неполная атрибуция.

Не ноль продаж, а ноль связок

Нулевая строка в рекламном отчёте не отвечает на вопрос «были ли продажи». Она отвечает только на вопрос «удалось ли связать переданные продажи с визитами по доступным данным».

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

Проверять нужно не только количество загруженных строк. В отчёте «Офлайн-конверсии» важен статус привязки и причина отказа. Яндекс отдельно указывает, что для сопоставления используются ClientID, UserID, YCLID или PurchaseID, а поздняя передача может вывести конверсию за период учёта.

Актуальное правило можно сверить в официальной справке Яндекс Метрики. Это не повод верить файлу на слово — несколько конкретных заказов всё равно нужно пройти от CRM до отчёта вручную.

Месячная выгрузка слишком медленная

Сильное исправление — не «перезалить старый файл ещё раз». Если записи уже вышли за окно, повтор не вернёт им подходящий визит.

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

Второй слой — качество идентификаторов. ClientID и YCLID надо сохранять в момент заявки, не перезаписывать при смене статуса и передавать вместе с устойчивым ID заказа. Телефон или email помогают сопоставлению, но не заменяют дисциплину данных.

Третий слой — контроль дублей. Один заказ не должен превращаться в несколько продаж при повторной выгрузке. Для этого используют постоянный ID заказа и заранее описывают, какой статус считается конверсией.

Рабочая схема без красивого самообмана

• заявка сразу получает источник, ClientID и при наличии YCLID;
• поля источника защищены от случайной перезаписи менеджером;
• целевой статус и сумма заказа выгружаются ежедневно;
• каждый заказ имеет постоянный ID для защиты от дублей;
• в Метрике проверяют не факт загрузки, а факт привязки к визиту;
• перед сокращением бюджета CRM сверяют с отчётом по нескольким реальным сделкам.

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

Чек-лист: что проверить до урезания бюджета

• Как часто CRM отправляет офлайн-конверсии: ежедневно, еженедельно или раз в месяц?
• Сколько дней проходит от фиксации целевого статуса до обработки файла?
• Сохраняются ли ClientID, YCLID и ID заказа в карточке лида?
• Есть ли в отчёте строки «не привязана» и указанные причины?
• Не исчезают ли сделки с длинным циклом только потому, что выгрузка опоздала?
• Совпадают ли число и суммы связанных продаж с выборкой из CRM?

Если отчёт показывает ноль продаж, сначала докажите качество связки данных. Только после этого решайте, что именно выключать в Директе.