80–85% сопоставленных офлайн-конверсий можно принять за хороший рабочий ориентир для интеграции CRM с Яндекс Метрикой. Но оценивать его нужно вместе с составом событий, скоростью передачи и распределением потерь. Для свежих заявок с сохранённым ClientID такой результат может оставлять заметный резерв для улучшения. Для сложной цепочки со звонками и сменой устройств достижение того же уровня потребует больше работы.
В этой статье мы предлагаем 80% как нижний рабочий ориентир, а 85% — как цель для первоначальной настройки мониторинга. Это редакционная рекомендация: в рассмотренной документации Яндекса универсального норматива «хорошего мэтчинга» нет.
Самое неприятное начинается, когда интеграция формально работает, а часть оплат и квалифицированных лидов исчезает по дороге. Маркетолог видит меньше результатов, чем есть в CRM, рекламные кампании получают неполный сигнал, а разработчик показывает успешный ответ API. Все трое описывают разные участки одной цепочки.
#Что именно означает процент мэтчинга
Офлайн-конверсия — результат, который появился вне отслеживаемого действия на сайте: квалификация обращения, подтверждение заказа, оплата, выкуп. Чтобы связать его с веб-историей, Метрике нужно найти соответствующий визит. Документация по сопоставлению офлайн-конверсий описывает эту связь через специальные идентификаторы.
В рабочем мониторинге полезно разделить три вопроса:
- Все ли нужные события из CRM выбраны и отправлены?
- Какие события приняты и прошли обработку?
- Какие из загруженных событий действительно привязались к визитам?
Процент мэтчинга загруженных событий = число привязанных событий / число загруженных событий × 100%.
Считать нужно сопоставимые события одного типа, с одним правилом отбора и после завершения обработки. Если из CRM отправляют только оплаты, в знаменатель нельзя включать все созданные сделки. Если один заказ прошёл квалификацию, оплату и выкуп, это три разных события; сравнивать их сумму с числом заказов бессмысленно.
Отдельно считайте полное покрытие: число привязанных событий / число событий CRM, которые по вашим правилам должны были попасть в передачу. Для обеих долей используйте уникальные события, чтобы повторная отправка одного результата не увеличивала знаменатель.
Возьмём условный расчёт. В CRM произошло 1 000 подходящих оплат. Интеграция отправила 900, а к визитам привязались 850. Мэтчинг отправленных событий —** 94,4%**. Полное покрытие — 85%. Если смотреть только на первую цифру, сто оплат, которые интеграция вообще не отправила, останутся за пределами расследования.
Из 1000 нужных событий отправлено 900 и привязано 850: мэтчинг и полное покрытие различаются
Поэтому сообщение «у нас мэтчинг 85%» должно сопровождаться хотя бы четырьмя уточнениями: каких событий, от какого количества, за какой период и после какой стадии обработки.
#Как оценивать 80%, 85% и более высокие значения
Для начала можно принять следующую шкалу мониторинга. Она относится к заранее определённому потоку событий с сайта и из CRM, которые вы собираетесь связывать с визитами. Это предлагаемые пороги для проверки интеграции, а не статистика рынка.
Уровень выше 85% имеет ценность, когда повышение получено за счёт восстановления реальных связей и исправления передачи. Если интеграция перестала отправлять сложные случаи, процент вырос из-за изменения знаменателя.
Для короткого, полностью контролируемого пути стоит стремиться выше 85%. Если форма сохраняет идентификатор, CRM принимает его, а квалификация приходит через несколько часов, оставшиеся 15–20% нужно объяснить конкретными причинами. Принять их за неизбежность слишком удобно.
Для общей базы CRM планка требует другой интерпретации. В ней могут быть обращения с выставок, прямые звонки и продажи клиентам, которые не посещали сайт. Доля привязок по такой базе описывает также происхождение клиентов. Выделите их в отдельную категорию и покажите её размер; при оценке технической интеграции используйте явно определённый поток, связанный с сайтом.
Смотрите и на объём. Изменение с 85 до 80 сопоставленных событий при сотне исходных событий может быть обычным колебанием состава. Если при нескольких тысячах событий исчезает целая доля оплат, это уже повод для предметного расследования. Сравнивайте одинаковые цели и периоды, учитывайте изменения форм и CRM.
#Почему общие 85% могут скрывать проблему
Сам процент не показывает, какие именно результаты потеряны.
В условном примере две группы дают по 500 реальных конверсий. В первой сопоставлены 475 — 95%. Во второй 375 — 75%. Вместе получается ровно 85%, но вторая группа теряет каждую четвёртую конверсию.
Общие 85% складываются из 95% в одной группе и 75% в другой
Если расходы каждой группы составляют 500 000 ₽, реальная стоимость конверсии одинакова: 1 000 ₽. По сопоставленным результатам она составит примерно 1 053 ₽ и 1 333 ₽. Вторая группа выглядит на 27% дороже первой только из-за разного покрытия.
Это арифметическое следствие неполных данных. Фактическое перераспределение бюджета автостратегией зависит от её настроек и остальных сигналов, но сравнение эффективности уже искажено.
Проверяйте потери отдельно по целям и этапам сделки, источникам, кампаниям, устройствам, формам и способам обращения. Если у несопоставленного события нет известной кампании, используйте сохранённые в CRM UTM-метки и данные своей системы сбора. Отсутствие связи с визитом может лишить вас как раз тех группировок, которые нужны для диагностики.
Особенно полезно сравнивать заявки с оплатами. Хорошая передача раннего события может соседствовать с плохой передачей результата сделки: после объединения дублей в CRM поле ClientID потерялось, либо оплата появилась слишком поздно.
Есть и другая ловушка: покрытие по количеству и покрытие по деньгам могут различаться. Если потеряны 15% самых крупных оплат, система видит гораздо меньше 85% выручки. Дополнительно считайте долю сопоставленной суммы среди всех подходящих оплат. Для квалификации без денежной оценки проверяйте категории качества лидов.
#Как Метрика находит визит
Для стандартной передачи офлайн-конверсий используются ClientID, UserID, yclid и PurchaseId. Хотя бы один идентификатор должен присутствовать. Поля события и формат передачи перечислены в руководстве API Метрики.
При ClientID и UserID выбирается предшествующий конверсии визит; yclid связывает её с рекламным переходом; PurchaseId — с визитом покупки. Подробности описаны в документации по сопоставлению.
Из этого следуют практические проверки. Произвольный номер сделки не становится UserID только потому, что так назван столбец. Номер заказа в CRM полезен как PurchaseId, когда он согласован с ID покупки электронной коммерции. UTM-метка помогает анализировать источник в вашей базе, но сама по себе не заменяет идентификатор привязки.
Храните длинные идентификаторы как строки. Если CSV открыли в табличном редакторе и сохранили после округления большого числа, внешне корректное значение может перестать совпадать с исходным. В диагностике сравнивайте символы целиком, включая начало и конец значения.
Собирать ClientID лучше в момент обращения: человек уже находится на сайте, и его связь с заявкой ещё можно зафиксировать. Если искать идентификатор только после оплаты через несколько недель, нужного браузера и сессии у вашей интеграции может уже не быть.
#Время передачи: почему даже правильного ID бывает мало
В стандартном механизме действует период учёта 21 день. Данные должны попасть в обработку, пока подходящий визит остаётся доступным для дополнения. Для yclid Яндекс прямо описывает интервал от рекламного визита до обработки файла. Поэтому задержка выгрузки съедает время, в котором возможна привязка. См. отслеживание конверсий по yclid.
Визит, результат сделки и обработка данных: задержка передачи может вывести визит за пределы окна
В условной временной цепочке визит произошёл 1-го числа, оплата — 18-го. Передача сразу после оплаты оставляет шанс связать события в окне учёта. Если файл обработают только 25-го, исходный визит уже слишком старый.
Это объясняет, почему ежедневный или более частый поток надёжнее выгрузки в конце месяца. Но при оплате через два месяца после единственного посещения сайта ускорение выгрузки уже не решит ограничение. Подходящим может оказаться более поздний визит, если он действительно был и известен системе.
Не переносите время оплаты к дате заявки ради красивой статистики. Тогда данные начинают описывать событие, которого в указанный момент ещё не было. Для длинного цикла используйте ранние содержательные этапы — например, квалификацию — и отдельно выстраивайте работу с прогнозом будущего результата.
Проверьте и единицы времени. Для DateTime нужен Unix timestamp в секундах. Ошибка с миллисекундами или неверное преобразование локальной даты может сделать событие будущим либо слишком старым. При формировании timestamp сначала корректно интерпретируйте часовой пояс исходной даты; готовая Unix-метка обозначает единый момент времени. Требования к полю приведены в описании передачи данных.
#Где смотреть мэтчинг и причины потерь
Основное место проверки в интерфейсе — Отчёты → Сквозная аналитика → Офлайн-конверсии. В колонке «Привязка к визиту» видно, удалось ли сопоставление; рядом доступны идентификаторы, Target, доход, валюта и ID загрузки. Несопоставленные записи сопровождаются причиной. Устройство отчёта описано в справке Яндекса.
Начните с одной завершённой загрузки и одной цели. Посчитайте уникальные привязанные и непривязанные события, затем повторите проверку за более длинный период. Свежую загрузку не стоит оценивать сразу: Яндекс указывает, что данные появляются в отчётах в течение трёх часов. См. передачу и обработку данных.
Для диагностики отчёт показывает, например, такие ситуации:
Сопоставьте ID проблемной загрузки со своим журналом отправок. Затем возьмите несколько конкретных CRM-событий и проследите их путь: запись в CRM, исходный ID, отправленная строка, результат обработки. Такой разбор быстрее указывает на место разрыва, чем общее обсуждение «Метрика теряет конверсии».
#Что ломается по дороге от CRM до Метрики
Часть проблем возникает ещё до загрузки. В форме нет поля с идентификатором; виджет отправляет заявку раньше, чем его получил; редирект потерял yclid; другой сайт принимает обращение без связи с первой сессией. Проверять нужно каждый способ обращения: основную форму, обратный звонок, мобильный вариант, внешнюю форму оплаты.
Следующий участок — CRM. Идентификатор приходит в лид, но не копируется в сделку. Дубли объединяются, и сохраняется карточка без исходного поля. Менеджер вручную создаёт заказ, который никак не связан с обращением. Отдельная интеграция передаёт оплату, имея только внутренний номер клиента.
Ошибки такого типа обнаруживаются сравнением полей на последовательных этапах. Если ID был в заявке и исчез в оплате, искать решение в настройках цели Метрики рано: связь потеряла внутренняя система.
Смена устройства создаёт другой разрыв. Человек оставил обращение с телефона, а оплатил с компьютера. Если интеграция сохранила первоначальную связь обращения с визитом, у неё остаётся полезная опора. Если она пытается склеить события только по текущему браузеру, исходного ClientID может не оказаться. При этом одинаковый контакт в разных карточках не даёт автоматического доказательства, что выбран правильный рекламный визит.
Последняя группа проблем относится к смыслу события. В одну цель попадают отправка формы и оплата; переходы CRM повторно создают одну конверсию; онлайн-покупка дублируется офлайн-загрузкой. В таких случаях число привязок может выглядеть прекрасно, а число реальных результатов — быть завышенным.
Высокое покрытие нужно проверять вместе с корректностью. На выборке сопоставленных событий убедитесь, что визит принадлежит нужному обращению, цель обозначает нужный этап, время соответствует событию и сумма совпадает с CRM. Особенно внимательно проверяйте неоднозначные связи: повторные обращения, несколько сделок клиента, общие контакты.
#На что влияют потери офлайн-конверсий
Во-первых, на оценку рекламы. Становится меньше оплат и дохода, растёт наблюдаемая стоимость результата. При неодинаковом покрытии меняется и сравнительная оценка кампаний: лучше выглядит та, у которой меньше технических потерь.
Во-вторых, на обучение. Яндекс указывает, что для оптимизации Директа используются привязанные офлайн-конверсии. Если часть полезных исходов не дошла до визитов, выбранная рекламная цель получает меньше подтверждённых результатов. Связь между привязкой и использованием событий описана в справке отчёта.
Неравномерные потери опаснее простого уменьшения количества. Если чаще теряются сложные и дорогие сделки, сигнал смещается к быстро оформляемым результатам. Это вывод из состава данных: модель видит именно то, что удалось передать и сопоставить.
В-третьих, на аудитории, построенные по достигнутым целям. Когда часть реальных покупателей не отражена в целевых событиях, сегмент оказывается неполным. При этом процент сопоставления клиентского списка в отдельном сервисе аудиторий и процент привязки офлайн-конверсий к визитам — разные показатели с разными знаменателями.
Повышение мэтчинга само по себе не задаёт точного прироста продаж. Его непосредственный результат — более полные и менее искажённые сведения, на которых принимаются рекламные решения.
#Как организовать контроль без постоянных ручных расследований
Зафиксируйте правила потока: какие события передавать, чем они отличаются от других этапов сделки и как определяется уникальное событие. Дальше контролируйте путь от CRM до привязки.
Для регулярной проверки достаточно компактного набора показателей:
- количество нужных событий в CRM, отправленных и привязанных событий;
- полное покрытие и мэтчинг загруженного потока;
- доля сопоставленной суммы оплат;
- задержка от бизнес-события до отправки и обработки;
- крупнейшие причины потерь и группы, в которых покрытие ухудшилось.
Настройте реакцию на снижение относительно обычного уровня. Если поток стабильно давал 94%, падение до 85% уже заслуживает проверки, хотя по стартовой шкале значение остаётся рабочим. Для редких событий смотрите более длинный период и сами записи, чтобы единичная ошибка не превращалась в ложную тревогу.
После изменения формы, CRM, коллтрекинга или счётчика повторяйте проверку нескольких событий целиком. Сохранённый идентификатор, корректное время и подтверждённая привязка дают гораздо больше уверенности, чем сообщение «интеграция включена».
#Если не хотите обслуживать эту цепочку вручную — используйте стриминг Sales Ninja
Сбор событий, сохранение связи с визитом, фильтры, отправка и повторные попытки быстро превращаются в отдельный проект. Его приходится поддерживать при каждом изменении форм и CRM.
В стриминге данных Sales Ninja эта цепочка собрана в одном продукте. События из CRM, коллтрекинга и сайта связываются с сессиями через ML Рематчер, проходят ваши фильтры и передаются в выбранную цель Метрики для Директа. Есть интеграции с amoCRM, Битрикс24, RetailCRM и системами обработки звонков. Если точная связь известна, используется она; для неоднозначных случаев работает рематчер.
Поток показывает готовность событий к передаче, причины отсутствия нужного идентификатора, историю отправок и очередь повторных попыток. Повторная доставка одного события тому же получателю контролируется. Это позволяет разбирать конкретные потери и поддерживать передачу без регулярных ручных CSV-выгрузок.
Внутренняя связь с сессией Sales Ninja и итоговая привязка в Метрике — два последовательных этапа. Для отправки всё ещё нужен идентификатор, который понимает получатель; результат зависит и от его окна учёта. Когда данных для связи недостаточно, событие может остаться несопоставленным. Поэтому корректный поток помогает сохранить доступные связи и увидеть проблемы, а конечный статус проверяется у получателя.
Если реальные результаты редкие или появляются с большой задержкой, дополнительно можно подключить моделируемые конверсии Sales Ninja. Они передают прогнозный сигнал для обучения рекламы раньше окончательного исхода сделки. Прогноз и фактическая оплата выполняют разные задачи; качество исходных данных важно для обоих.
80–85% — удобная отправная точка. Хорошая интеграция позволяет ответить и на следующий вопрос: где оставшиеся события, почему они потерялись и что можно исправить. Если не хотите самостоятельно поддерживать сбор идентификаторов, связывание событий и доставку, подключите стриминг Sales Ninja.
