Яндекс Метрика: какие источники приводят заявки, которые доходят до продажи

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

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

Результат работы — воспроизводимая ведомость качества источников: состав заявок, доля сопоставления, квалификация, подтверждённая продажа и решение с ответственным. Официальные страницы проверены 10 октября 2026 года. Частный счётчик Метрики и CRM клиента не открывались; обе таблицы ниже учебные, не скриншоты. Методика ведомости — редакционная рекомендация, а не встроенный отчёт AffiliateCore и не обещание готовой интеграции.

1. Определите, какое решение должен поддержать отчёт

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

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

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

2. Подготовьте доступ и проверьте пригодность данных

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

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

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

Для подготовки условий собственного предложения можно создать профиль рекламодателя AffiliateCore. Регистрация не подключает Метрику и не подтверждает допуск продукта, источника или географии; подготовленное предложение проходит предусмотренное рассмотрение и модерацию.

3. Разделите цель, заявку и продажу

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

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

Учебная таблица 1. Словарь ведомости; это не интерфейс Метрики.

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

4. Зафиксируйте настройки отчёта Метрики

Откройте нужный счётчик и отчёт «Источники заказов из CRM» в разделе «Сквозная аналитика», если передача настроена. Его условия и определения приведены в документации отчёта. Если раздел не даёт ожидаемых данных, проверьте доступ, счётчик и состояние передачи; пустота не доказывает отсутствие продаж.

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

Особенно важно заново проверить атрибуцию: с 20 мая 2026 года часть прежних моделей отключена. Ориентируйтесь на актуальные модели, а не старый скриншот. Запишите точное название выбранного варианта. При изменении модели сравнивайте два расчёта как разные представления одного набора, не как внезапное изменение качества источника.

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

5. Сверьте состав, прежде чем считать проценты

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

Сначала посчитайте всю совокупность CRM, затем тесты, дубли и оставшиеся обращения. После этого разделите допустимые строки на сопоставленные и несопоставленные. Получите равенство: исходные строки минус документированные исключения равны заявкам в анализе; заявки в анализе равны сопоставленным плюс несопоставленным. Проверяйте равенство отдельно по продукту и периоду, чтобы ошибки разных групп не компенсировали друг друга.

Не соединяйте две таблицы только по дню и сумме. Совпадение этих значений не доказывает, что речь об одной заявке. При нескольких заказах на обращение заранее задайте правило: для доли продаж учитываем не более одного успешного результата на заявку. Анализ количества заказов и выручки при этом остаётся отдельной задачей. Ошибка соединения «многие ко многим» способна удвоить сделки без появления единого нового покупателя.

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

6. Дайте каждой заявке одинаковое время

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

В нашем учебном примере берём обращения, созданные 1–7 сентября 2026 года, и оцениваем каждое ровно через 14 суток после создания. Выгрузку делаем после завершения всех этих окон и обновления данных. Для этого нужна история событий: последняя текущая карточка на 21 сентября сама по себе не восстановит состояние на четырнадцатые сутки каждой заявки. Без истории обозначьте ограничение и не называйте результат строго сопоставимой когортой.

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

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

7. Посчитайте учебную когорту и проверьте арифметику

Далее приведены вымышленные данные, не результаты AffiliateCore, Яндекса или конкретного канала. A и B — две группы с независимо сохранённой в CRM принадлежностью источнику; среди сопоставленных строк её согласовали с выбранным представлением аналитики. Это необходимое условие, чтобы знать размер группы даже при потере связи с Метрикой. Если такой принадлежности нет, несопоставленные строки остаются общей неизвестной группой.

Учебная таблица 2. Результаты на четырнадцатые сутки; единица — уникальная заявка.

Квалификация, оплата и отмена в этой таблице относятся только к сопоставленным заявкам. Отмена — подмножество ранее оплаченных, все события укладываются в выбранное окно. Действующие продажи равны 27 − 3 = 24 для A и 18 − 0 = 18 для B. Этапы пересекаются; складывать строки таблицы нельзя.

Доля сопоставления составляет 108 / 120 = 90% и 90 / 100 = 90%. Квалифицированы 54 / 108 = 50% и 63 / 90 = 70% сопоставленных заявок. Доля действующих продаж среди сопоставленных — 24 / 108 ≈ 22,2% и 18 / 90 = 20%. У B выше квалификация, но это ещё не превосходство по конечному результату; у A выше наблюдаемая доля продаж, но различие само по себе не доказывает устойчивого преимущества.

Проверим третью вымышленную группу C без расширения таблицы: 80 заявок, связь есть у 40, квалифицированы 28, оплата была у 12, две отменены. Получаем 10 действующих продаж, 50% сопоставления, 70% квалификации и 25% продаж среди сопоставленных. Последнее число выглядит лучшим, однако половина обращений не представлена в этой доле. Нельзя объявить C победителем или распространить её 25% на неизвестную половину.

Для наглядной проверки границ временно считаем исходы несопоставленных неизвестными. У A общая доля продаж могла бы находиться от 24 / 120 = 20% до (24 + 12) / 120 = 30%; у C — от 10 / 80 = 12,5% до (10 + 40) / 80 = 62,5%. Это арифметические крайние сценарии при максимум одной продаже на заявку, не доверительные интервалы и не прогноз. Если CRM уже знает исходы несопоставленных, используйте их для общего результата CRM; ограничение касается распределения по проверенному источнику Метрики.

8. Примите решение с учётом неполных данных

Начинайте с качества измерения. При низком или неравномерном сопоставлении сначала выясните причину: различается ли форма, способ поступления обращения, версия интеграции или заполнение источника. Не вводите универсальный порог вроде «90% всегда достаточно». Важны масштаб пропуска и его связь с результатом: даже небольшой систематический пробел может изменить вывод.

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

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

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

9. Исправьте частые ошибки до передачи отчёта

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

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

Поведенческие записи и тепловые карты помогают искать трудности на странице; это отдельная инструкция по Microsoft Clarity. Техническая передача офлайн-конверсий также требует отдельной задачи. В этом материале нет кода загрузки, настройки рекламных аудиторий или утверждения о встроенной передаче CRM из AffiliateCore.

10. Завершите работу проверяемой ведомостью

Перед передачей решения проверьте следующий список:

• Продукт, Россия как рынок, допустимость канала и права доступа проверены отдельно.
• Заявка, квалификация и действующая продажа определены; тесты и дубли объяснены.
• Источники CRM и Метрики согласованы либо различие явно отмечено.
• Часовой пояс, даты создания, история статусов и срок наблюдения сохранены.
• Исходные строки сходятся с исключениями и итоговой совокупностью.
• Несопоставленные и ожидающие решения заявки видны рядом с процентами.
• Модель атрибуции записана фактически, а не взята из старой инструкции.
• Числа, округление, ограничения, ответственный и дата следующей проверки указаны.

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

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