После сбоя Метрики: как сверить заявки и отчёты
Как сверить CRM, расходы Директа и данные Метрики после сбоя. Шаблон отчёта, проверка дублей и правила расчёта CPL при неполных данных.
После сбоя Метрики сначала восстановите учёт бизнес-результата: расходы, уникальные заявки, заказы и оплаты. Соберите их за один период, уберите дубли и отметьте качество привязки к рекламе. CRM помогает сверить продажи, но не восстанавливает все визиты. Неизвестное значение в отчёте нужно оставить пустым, а не заменить нулём.
Материал подготовлен 12 октября 2026 года, редакционный срез около 20:30 МСК. Яндекс подтвердил повреждения инфраструктуры; срок восстановления оборудования в заявлении не указан. Недоступный кабинет сам по себе не доказывает остановку сбора. Оперативная проверка разобрана винструкции по диагностике Метрики. Здесь закрываем уже прошедший период и готовим отчёт для бизнеса.
Я предпочту отчёт с честной строкой «источник не установлен» таблице, в которой каждый заказ задним числом записали в Директ. Во втором случае цифры сходятся, а следующее решение о бюджете становится хуже.
1. Зафиксируйте период и сохраните исходные выгрузки
Начните с журнала: когда обнаружили симптом, что перестало открываться, когда применили ограничение рекламы и когда подтвердили восстановление. Не подменяйте начало своей проблемы временем публикации новости. Разные сайты, формы и кампании могли пострадать в разные моменты.
Для сверки задайте начало включительно, конец исключительно. Например, интервал 12 октября с 14:00 до 17:00 МСК включает событие в 14:00, но не событие в 17:00. Следующий интервал начинается в 17:00. Это правило защищает от двойного учёта на границе выгрузок. Пример учебный, он не описывает длительность нынешнего инцидента.
Сохраните исходные файлы отдельно: статистику расходов Директа, реестр заявок CRM, заказы сайта, оплаты эквайринга, серверные логи. Рядом запишите время выгрузки, фильтры и часовой пояс. Снимок данных после восстановления может отличаться от первоначального; это причина для версии отчёта, а не для незаметного удаления старого файла.
Нет доступной статистики расхода? Отметьте «ожидается выгрузка». Сумма пополнения или изменение баланса не всегда равны расходу выбранных кампаний за нужные часы. Решение о временном ограничении рекламы описано в разборе сбоя Директа.
2. Заполните шаблон и не умножьте расход на число заказов
Скачать CSV-шаблон сверки и инструкцию к заполнению. Это рабочий реестр для сверки, а не файл, готовый к загрузке в Метрику. Он открывается в табличном редакторе; при импорте проверьте разделитель и текстовый тип идентификаторов.
| Поля шаблона | Смысл | Контроль |
|---|---|---|
| campaign_id, period_start_msk, period_end_msk, spend_rub | Кампания, интервал, расход | Один расход на одну кампанию и интервал |
| order_id, created_at_msk, paid_at_msk, status, amount_rub | Сохранённый заказ и его состояние | Идентификатор заказа и правило статуса |
| utm_source, utm_medium, utm_campaign, yclid, client_id | Признаки источника | Сохранённые значения, без выдуманного заполнения |
| measurement_status, evidence_source, notes | Качество измерения, источник доказательства, пояснение | Причина привязки или неопределённости |
Если у кампании десять заказов, нельзя поставить весь расход в каждую из десяти строк и затем сложить столбец. Ведите отдельную строку расхода на уникальную пару «кампания + интервал», а в строках заказов оставляйтеspend_rub пустым. В шаблоне поле row_type разделяет строки: expense для расходов и order для заказов. Альтернатива — отдельные листы расходов и заказов с объединением уже агрегированных итогов.
Ноль ставьте только там, где источник подтвердил нулевой результат. Пустая ячейка означает, что значение неизвестно или неприменимо. Сохраняйте длинные yclid и client_id как текст: округлённое табличным редактором число уже нельзя надёжно сопоставить.
Как соединить расходы и заказы без повторного счёта
Сначала получите итог из строк expense по кампании и интервалу. Отдельно посчитайте уникальные order_id в строках orderс подходящими статусами. Затем соедините эти два итога. Прямое объединение одной строки расхода с восемнадцатью заказами создаст восемнадцать копий суммы, если потом сложить полученную таблицу. В ячейке расхода строки заказа должно оставаться пусто. Заказ с неизвестной кампанией сохраните в реестре, но не назначайте ему campaign_id ради удобного соединения.
3. Приведите время, статусы и дубли к одному правилу
Все поля с суффиксом _msk должны содержать время Москвы, например 2026-10-12T14:30:00+03:00. Если CRM выгружает UTC, сначала сделайте перевод. Не меняйте просто подпись столбца: заказ в 23:30 UTC относится уже к следующему дню по МСК.
Время создания и время оплаты нужны отдельно. Заявка 12 октября, оплаченная 14 октября, входит в когорту заявок 12-го и в денежные поступления 14-го. Для ROAS когорты используйте дату среза: сколько выручки принесли заявки выбранного периода к указанному дню. Не смешивайте эту сумму с оплатами всех клиентов, поступившими сегодня.
Договоритесь, какие статусы означают полученную заявку, подтверждённый заказ и оплату. «Счёт выставлен» не равен «оплачено». Уточните, включает ли сумма НДС, доставку и возвраты, чтобы обе стороны сравнения считали деньги одинаково.
Сначала разделите строки по row_type. Строки expenseсверяйте по кампании и интервалу; их пустой order_id не служит основанием для удаления. Дедупликацию строк order начните с постоянного order_id. Повторный вебхук и повторное уведомление не создают новую продажу. Но два самостоятельных заказа одного человека остаются двумя заказами. Если стабильного ID нет, выделите подозрительные строки для ручной проверки; совпадение телефона само по себе недостаточно. Тестовые обращения вынесите из расчёта KPI.
Как поступить с несколькими статусами одного заказа
Если выгрузка содержит историю, один заказ может появиться как созданный, подтверждённый и оплаченный. Это последовательность состояний, а не три продажи. Для отчёта зафиксируйте последнее известное состояние к дате среза, сохранив исходную историю отдельно. Время создания берите из создания заказа, время оплаты из подтверждённого платежа. Позднее изменение статуса не переносит дату первой заявки. Возврат тоже требует собственного правила: иначе вчерашняя оплата останется в выручке, хотя деньги уже вернули покупателю.
4. Разделите подтверждённый заказ и подтверждённую атрибуцию
Используйте два отдельных признака. status описывает бизнес-состояние заказа. measurement_status описывает качество измерения: tracked — событие видно в выгрузке аналитики;matched — источник сопоставлен по сохранённым идентификаторам или UTM; unknown — привязка не установлена. Подтверждённая заявка CRM может иметь любой из этих статусов измерения.
matched не означает, что конверсия уже появилась в Метрике или повлияла на автостратегию. В evidence_source укажите, почему сделали привязку: запись формы с UTM, журнал заказов с yclid, выгрузка Метрики. Разная модель атрибуции тоже даёт разные результаты. Сохранённая метка последнего перехода не описывает всю историю клиента.
Сопоставляйте источник на уровне заказа. Нельзя распределить все неопределённые заявки между кампаниями пропорционально расходу и назвать это восстановленной аналитикой. Если нужна оценка для планирования, сделайте отдельный сценарий с явными допущениями, рядом с наблюдаемыми данными.
В справке Метрики о Директе перечислены причины расхождения кликов и визитов: например, посетитель может закрыть страницу раньше загрузки счётчика. Клик не равен визиту. Серверный запрос тоже не равен человеку: в логах есть роботы, повторы и загрузка отдельных ресурсов. Правила сохранения меток разобраны в гайде по UTM.
5. Пересчитайте CPL и ROAS с понятным знаменателем
Учебный пример, все числа ниже вымышлены. Кампания потратила 12 000 ₽. CRM подтвердила 18 уникальных заявок с привязкой к этой кампании; в Метрике видно 12 целевых событий. Ещё четыре заявки имеют неизвестный источник. Они не входят в знаменатель CPL этой кампании.
| Показатель | Расчёт | Что он описывает |
|---|---|---|
| CPL по целям Метрики | 12 000 / 12 = 1 000 ₽ | Стоимость учтённого целевого события |
| CPL по подтверждённым заявкам CRM | 12 000 / 18 ≈ 667 ₽ | Стоимость уникальной заявки с известной привязкой |
| ROAS когорты при 36 000 ₽ выручки | 36 000 / 12 000 = 3,0, или 300% | Выручка когорты к дате среза на рубль расхода |
Разница между 12 и 18 не доказывает, что ровно шесть событий потеряны из-за атаки. Проверьте смысл цели, уникальность событий, время, правила атрибуции и задержку обработки. Если подтверждены заявки, но неизвестен расход, CPL пока не считается. Если заявки неизвестны, деление на ноль не превращает отчёт в точную оценку убытка.
ROAS 300% не означает прибыль 300%: себестоимость и остальные затраты в этой формуле отсутствуют. Оставьте в отчёте и прежний показатель, и пересчитанный, рядом укажите основание изменения. Дополнительные формулы есть в разборе CPL и ROAS.
Те же числа: какие заказы можно включить в результат
Продолжим учебный пример. Допустим, каждой из 18 подтверждённых заявок соответствует один уникальный заказ в реестре. Из них шесть оплачены, а их подтверждённая выручка равна 36 000 ₽. Тогда CPL остаётся примерно 667 ₽, а стоимость оплаченного заказа равна 12 000 / 6 = 2 000 ₽. Двенадцать остальных заказов нельзя назвать оплатами. Эти показатели отвечают на разные вопросы, даже когда берутся из одного файла.
Теперь предположим, что среди четырёх заявок с неизвестным источником есть оплаты на 8 000 ₽. Бизнес вправе показать их в общей выручке соответствующей когорты, если принадлежность к ней подтверждена. Но приписать эти деньги выбранной кампании оснований нет. Деление 12 000 ₽ на все 22 заявки даст около 545 ₽; это число нельзя подписать «CPL кампании». Аналогично 44 000 / 12 000 не доказывает её ROAS. В отчёте оставьте 18 привязанных заявок, шесть известных оплат и отдельную группу неопределённого источника.
6. Передавайте офлайн-конверсии только после проверки
Передача офлайн-конверсий дополняет данные о существующем визите. Она не создаёт задним числом все отсутствующие посещения. Поофициальной инструкции Метрики для CSV нужны идентификатор привязки,Target и DateTime в Unix-секундах. Наш файл сверки требует отдельного преобразования в этот формат.
Проверьте цель, точное время события, идентификаторы и применимые правила повторной передачи. Период дополнения визитов ограничен 21 днём; условия связаны со временем визита и обработки данных, поэтому сверяйте их по справке до загрузки. Наличие yclid в CRM не гарантирует, что Метрика найдёт подходящий визит.
После обработки проверьте отчёт «Офлайн-конверсии»: статус загрузки и привязка к визиту — разные результаты. По справке только привязанные конверсии участвуют в оптимизации Директа и отображаются в соответствующих отчётах. Непривязанные записи разберите по причине, без повторной массовой загрузки наугад.
Закройте сверку версией отчёта: период, дата среза, подтверждённые суммы, неизвестные источники, незавершённые проверки и ответственный за них. Схему постоянного независимого реестра можно взять из материалаоб аналитике без Метрики.
7. Вопросы о восстановлении аналитики
Можно ли восстановить все визиты Метрики по CRM?
Нет. CRM подтверждает сохранённые заявки и заказы. Она не содержит всех визитов, поведения посетителей и событий браузера. Восстановить бизнес-результат по реестру заказов можно, автоматически превратить его в утраченную статистику посещений нельзя.
Как учесть заказ, который оплатили после сбоя?
Сохраните отдельно время создания заказа и время оплаты. В отчёте по заявкам периода заказ относится к дате создания, в отчёте по денежным поступлениям — к дате оплаты. Доход когорты заявок можно обновлять позднее, с указанием даты среза.
Что делать с повторными уведомлениями и дублями?
Проверьте постоянный order_id или идентификатор заявки. Несколько уведомлений об одном заказе не создают новые заказы. Разные реальные заказы одного клиента не объединяйте только по телефону или email. Сохраните правило дедупликации в инструкции к отчёту.
Почему число кликов Директа отличается от визитов Метрики?
Клик по рекламе и визит, зафиксированный счётчиком, измеряют разные события. Например, человек может закрыть страницу до загрузки счётчика. Сверять нужно одинаковые периоды и кампании; разницу нельзя целиком объявлять потерей из-за инцидента.
Можно ли исправить CPL после восстановления Метрики?
Да, пересчитать показатель по уточнённым данным можно. Назовите источник заявок, правило атрибуции и дату пересчёта. CPL по подтверждённым заявкам CRM и CPL по целям Метрики могут различаться. При неизвестном числе заявок показатель следует оставить неизвестным.
Нужна помощь со сверкой? Через форму связи или Telegram @dipustovalov опишите системы, период и расхождение. Для первичного разбора подойдёт обезличенный пример с сохранённой структурой; клиентские данные не нужно публиковать вместе с отчётом.