-
Цель
Какое действие клиента важно бизнесу
-
Работы
Что нужно создать или изменить
-
Ресурсы
Бюджет, участие команды и ограничения
-
Контроль
Как проверить выполненное и выбрать следующий шаг
Если Метрика не принимает офлайн-конверсии, сначала проверьте сам CSV: названия колонок, идентификаторы, цель и время события. Если файл принят, но продаж в отчёте нет, ищите проблему сопоставления с визитом. Это два разных этапа: исправление разделителя не вернёт потерянный ClientID.
Проверить CSV офлайн-конверсий можно без доступа к счётчику. Файл остаётся в браузере; проверка находит ошибки формата, но не проверяет существование целей и посетителей в вашем аккаунте.
Какие данные подготовить
В строке нужны идентификатор посетителя или покупки, Target и DateTime. Метрика поддерживает ClientID, UserID, yclid и PurchaseId; конкретный способ должен соответствовать вашей настройке передачи. Price и Currency добавляют денежные показатели. Сохраняйте файл в UTF-8 и используйте регистр заголовков из документации.
| Поле | Откуда берётся | Что проверить |
|---|---|---|
| ClientID | Счётчик при обращении на сайте | Сохранился ли исходный идентификатор в CRM |
| Target | Согласованный идентификатор цели | Не название стадии сделки вместо цели |
| DateTime | Время нужного бизнес-события | Unix-время в секундах, не миллисекундах |
| Price, Currency | Учёт оплаты | Сумма без символа ₽ и корректный код валюты |
Пять ошибок, которые стоит найти до загрузки
- Идентификатор превратился в число. Табличный редактор может записать длинный ClientID в научной нотации или округлить его. Возвращение формата «Текст» после потери цифр не восстановит значение: нужна повторная выгрузка из источника.
- Время умножено на 1000. JavaScript часто отдаёт миллисекунды, а CSV требует секунды. Проверьте не только длину числа, но и дату, в которую оно преобразуется.
- Target не совпадает с настройкой. «Оплачено», название цели в интерфейсе и её идентификатор могут различаться. Зафиксируйте карту стадий и целей отдельно от выгрузки.
- Строки повторяются. Одна оплата попала в ежедневную и накопительную выгрузки. Храните журнал передачи по бизнес-событию и его версии; не считайте повтор успехом.
- Сумма относится не к тому событию. В цель оплаты передали стоимость всей сделки при частичном платеже. Выберите правило заранее и одинаково применяйте его во всех отчётах.
Файл принят, но конверсии не появились
Проверьте отчёт обработки и конкретный идентификатор. Для привязки важен допустимый интервал от визита до обработки данных; в документации Метрики указан 21 день. Возраст события в CSV сам по себе не доказывает возможность сопоставления: локальная проверка не знает дату последнего визита пользователя.
Проверьте счётчик, из которого получен ClientID, и счётчик загрузки. Затем восстановите цепочку одной сделки: визит → отправка формы → запись идентификатора → оплата → строка CSV → результат обработки. Не отправляйте вымышленные идентификаторы в рабочую Метрику ради теста.
Как принять работу интегратора
Согласуйте небольшой тестовый набор: обычная оплата, частичная, повторная отправка, возврат и сделка без идентификатора. Для каждого случая укажите ожидаемый результат. В журнале нужны ID события, время попытки и ответ сервиса, а не полный набор персональных данных клиента. Отдельно определите, кто исправляет несопоставленные записи и как запускается безопасный повтор.
В схеме связи Метрики и Битрикс24 важно сохранить источник обращения до оплаты. Для подготовки карты событий используйте учебный CSV и проверку формата, затем подтвердите результат в самой Метрике.
Частые вопросы
Можно ли передать телефон вместо ClientID?
Не подставляйте телефон в колонку ClientID. Это разные идентификаторы. Выбирайте поддерживаемый способ передачи и формат из документации, а не переименовывайте произвольное поле CRM.
Почему проверка не исправляет файл автоматически?
Она не знает правильную цель, валюту и потерянные цифры. Отчёт показывает строку и причину, а исправление делают в источнике. Иначе следующая выгрузка принесёт ту же ошибку.
Как устроить очередь передачи
Не стройте выгрузку по принципу «все сделки на стадии оплачено каждый день». Одна сделка может находиться на стадии месяц, иметь несколько платежей или вернуться назад. Выделите отдельную запись бизнес-события: например, подтверждение конкретного платежа. Сохраните её внутренний ключ, дату события, выбранную цель и версию данных. Так можно объяснить, почему в файл попала именно эта строка.
Разведите состояния «подготовлено», «отправлено», «принято сервисом» и «сопоставлено». При сетевом тайм-ауте нельзя автоматически заключить, что сервис ничего не получил. Сначала проверьте доступный статус операции, затем действуйте по правилам повторной передачи выбранного API. Если транспорт не даёт однозначного ответа, оставьте запись для разбора, а не создавайте новый бизнес-ключ при каждой попытке.
Для ответственного сотрудника полезен короткий реестр: дата, число подготовленных событий, принятых записей и ошибок по причинам. Нужен переход к исходной записи внутри защищённой системы, но не полный телефон клиента в ежедневном письме. Отдельно показывайте события без идентификатора: они не должны бесследно исчезать из отчёта об оплатах, даже если их нельзя связать с визитом.
Пример разбора расхождения CRM и Метрики
Учебная ситуация: CRM показывает десять оплат, CSV содержит восемь строк, а Метрика связала с визитами шесть. Это не одна ошибка «не сходятся цифры». Две оплаты могли не пройти правило отбора в файл, ещё две — не сопоставиться после загрузки. Сравнение общих итогов не укажет место потери.
Сначала сопоставьте внутренние ID оплат и строки выгрузки. Затем разберите ответы принимающей системы для этих строк. После этого проверьте настройки отчёта: даты, цель, атрибуцию и фильтры. Исправление выбора периода не восстанавливает пропущенную строку, а повторная загрузка уже принятой записи не исправляет неверный фильтр отчёта.
До запуска согласуйте обработку возвратов и исправлений суммы. Не отправляйте отрицательную цену просто потому, что так удобно в учётной таблице: формат и механизм корректировок надо проверять для выбранного способа передачи. Храните исходное событие и его исправление раздельно, чтобы не потерять историю. После изменения интеграции повторяйте эти сценарии, а не только одну успешную продажу.
Документация и проверка форматов
Документация проверена 18 октября 2026 года.
