21 августа 2026 г. · Maksim Shchegolev

Атрибуция источников заявок: от первого клика до выручки

Атрибуция источников заявок работает, когда владение назначено по полям между 2 системами: Lead Hub хранит доказательства приёма, CRM владеет стадиями воронки и закрытой выручкой, а отчёт склеивает их по устойчивому ключу человека. Она перестаёт работать в тот момент, когда одну систему просят быть истиной для поля, которым владеет другая.

Хотите проверить это на своём сайте? Запустите бесплатную проверку видимости в ИИ, она занимает десять секунд и не требует почты.

Атрибуция входящих заявок держится на двух устойчивых фактах и одном надёжном соединении. Первый факт это исходный источник, который создал контакт. Второй это последний источник перед текущей конверсией. Соединение это исход сделки в CRM, привязанный через стабильный идентификатор. Lead Hub (узел приёма, общий для всех каналов) нормализует события приёма. CRM остаётся главной по этапам и выручке. Всё остальное уже интерпретация.

Одним предложением

Атрибуция источников заявок работает, когда владение назначено по полям: Lead Hub хранит доказательства приёма заявки, CRM владеет этапами воронки и закрытой выручкой, а отчёт соединяет их по устойчивому ключу человека и не притворяется, что визит в аналитике и живой покупатель это один и тот же объект.

Почему не сходятся заявки в CRM и аналитике?

Потому что системы измеряют разные объекты в разные моменты, и каждая права внутри своего определения. Веб аналитика считает события и посетителей. Событие формы может сработать дважды, может сработать и не дойти до сервера, может принадлежать человеку, который уже есть в базе. CRM считает людей, компании и сделки. Сделка бывает заведена руками, слита с дублем, открыта заново или связана с пятью контактами одной компании.

Равные числа не цель. Цель это задокументированное расхождение, которое любой может повторить.

Документация GA4 по источникам трафика разделяет измерения на уровне пользователя и на уровне сеанса. Различие полезно для анализа поведения и бесполезно для решения о том, кому засчитать сделку, потому что в аналитике нет понятия слитого дубля и дисквалифицированной заявки. В российских проектах то же самое верно для Яндекс Метрики: она хранит источник визита, но не знает, что два визита это один человек с двух устройств и одна сделка.

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

Размер каждой причины меряйте у себя, а не берите чужой ориентир.

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

Какая модель события сохраняет источник заявки?

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

Lead Hub пишет эту запись один раз. В CRM уходит нормализованное подмножество полей, доступное только для чтения. Веб аналитика продолжает жить своей жизнью и не становится системой учёта заслуг. Как ведут себя поля владельца и этапа на стороне CRM, показывают справки международных систем: назначение владельца записи и автоматизация воронки заявок. В amoCRM и Битрикс24 логика та же: заявка приходит извне, поля источника заполняются автоматически, менеджер их не редактирует.

Исходный источник, последний источник и правила их обновления

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

Для чего нужно каждое поле

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

Как поля выглядят в отчётах

Выгружайте все три колонки вместе с определениями. Колонка с названием «источник» без определения это самый быстрый способ получить два отдела с двумя разными правдами.

Что считается сменой последнего источника

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

Окно неактивности это ваше бизнес решение, а не отраслевой стандарт. Тридцать дней обычно берут за старт для короткого цикла, девяносто для длинного. Запишите число в словарь отчётности, версионируйте его и фиксируйте дату изменения. Тихо поменяли окно, и все графики динамики выше этой даты стали несопоставимыми.

Влияющие касания без потери неизменности

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

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

Разбор одного клиента по шагам

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

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

Словарь источников, стандарт UTM и метки кластеров

Качество атрибуции это почти целиком дисциплина словаря. Свободный текст убивает её за квартал.

Источник (обязательно, закрытый список): органика, платный поиск, платная соцсеть, органическая соцсеть, рассылка, рекомендация, партнёр, мероприятие, неизвестный источник.

Канал (обязательно, закрытый список): форма на сайте, чат на сайте, WhatsApp, Telegram, телефон, мероприятие, загрузка файла.

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

Три правила удерживают этот порядок. Запретите свободный ввод названий кампаний в рекламном кабинете и собирайте все ссылки одним генератором. Сделайте поле источника в amoCRM или Битрикс24 доступным только для чтения, права на правку выше уровня менеджера. Неизвестные значения отправляйте в очередь на разбор, а не записывайте молча.

Программатик и сравнительные кластеры добавляют ещё одно измерение, метку страницы. Она меняет вопрос о контенте с «сколько трафика собрала страница» на «сколько квалифицированных заявок она дала». Устройство самих страниц описано в гайде по программатик SEO, измерение видимости в ответах нейросетей в гайде по AEO и GEO, а этот гайд отвечает только за разметку, которая делает и то, и другое измеримым.

Как связать анонимный визит с конкретным человеком?

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

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

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

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

Что делать с заявками без источника?

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

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

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

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

Операторская заметка. Команда, которая писала ответы клиентов прямо в поле источника CRM, через полгода обнаружила, что значение «Яндекс» покрывает и платный поиск, и органику, и защитить рекламный бюджет цифрами оказалось нечем. Разделение восстанавливали руками по идентификаторам клика за один квартал, а всё остальное так и осталось неизвестным.

Как фиксировать источник в чатах, звонках, на выставках и у партнёров?

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

Чат наследует страницу, на которой его открыли, а не ту, где закончился диалог. Если человека квалифицировал бот, отмечайте это отдельным признаком, чтобы воронка бота и воронка менеджера сравнивались корректно. Сама логика квалификации описана в гайде по AI квалификации заявок.

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

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

Как связать источник заявки с выручкой?

Для соединения с выручкой нужны стабильные ключи и явная гранулярность. Источник на уровне человека нельзя без правила присоединить к каждой сделке: у одного человека бывает несколько сделок, а в одной сделке участвуют несколько контактов.

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

Зафиксируйте основание когорты и пишите его на каждом графике. Сделки, сгруппированные по месяцу появления человека, отвечают на вопрос о спросе. Сделки по месяцу закрытия отвечают на вопрос о деньгах. Смешение этих двух оснований в одном отчёте это самый частый способ «уронить» хороший канал на бумаге. Сумма сделки остаётся за CRM, даже если её копия лежит в Lead Hub. Как это меняет экономику вашей работы с заявками, во что обошлось внедрение и когда оно отобьётся, разбирает отдельный гайд про окупаемость автоматизации заявок, а здесь мы останавливаемся на том, чтобы связка источника с выручкой была воспроизводимой.

Какая система на какой вопрос отвечает?

Споры об атрибуции почти всегда это переодетые споры о границах систем.

Аналитика объясняет, что происходило до заявки, с детализацией, которой у Lead Hub нет. Lead Hub объясняет, что было правдой в момент приёма, с постоянством, которого аналитика не даёт. Сама граница систем разобрана в гайде о Lead Hub и CRM, выбор ответственного за заявку в плейбуке по распределению заявок, а отчётность по времени ответа в гайде о скорости ответа на заявку.

Как управлять правками источника и соблюдать закон?

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

Механизм правок нужен обязательно, потому что системы приёма ломаются не по вине клиента. Сделайте правки редкими, доступными по правам и обратимыми. Администратор выбирает код причины и прикладывает доказательство, прежнее значение сохраняется в журнале событий. Менеджер подаёт заявку на пересмотр, но поле не редактирует.

Ведите объём правок по причинам как ежемесячный тренд. Всплеск по одной причине это задача разработке, а не вывод о поведении клиентов. «Продавец говорит, что это рекомендация» кодом причины не является. Премия за приведённую сделку считается по исходному источнику из Lead Hub плюс задокументированная процедура спора. Опубликуйте эту процедуру рядом с определениями полей и объясняйте её при вводе новых сотрудников в работу, об этом есть гайд по адаптации менеджеров по продажам.

Юридическая часть состоит из четырёх пунктов, и все они должны быть записаны. Фиксируйте состояние согласия прямо в событии приёма, потому что от него зависят правила выгрузки и хранения. Задайте срок хранения сырых событий и реально удаляйте их по истечении срока, а не держите журнал вечно по умолчанию. Обеспечьте удаление данных человека сразу в Lead Hub, CRM и аналитическом хранилище, для этого person_key и должен разрешаться во всех трёх системах. Предупреждайте о записи диалога и автоматической обработке там, где этого требует закон о персональных данных. Когда самоотчёт клиента классифицирует модель, полезной опорой для описания и контроля такой системы служит рамочный документ NIST по управлению рисками ИИ.

Что отдаём руководителю и что отдаём аналитикам?

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

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

Аналитикам уходит схема с фиксированной периодичностью: person_key, first_touch_timestamp, first_touch_source, first_touch_channel, first_touch_url, last_touch_source, influence_touch_count, qualified_timestamp, won_timestamp, revenue_amount, consent_state. Поля Lead Hub несут измерения источника, поля CRM несут исходы и остаются главными по сумме, а состояние согласия определяет, что вообще можно выгружать.

Связывает эти два документа одно правило: если число со страницы для руководителя нельзя пересчитать из этой схемы, ему на странице не место.

Как проводить ежемесячную сверку и выборочный аудит?

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

Сначала выборка. Возьмите фиксированное число недавно закрытых сделок, тридцать это рабочий стартовый размер, и по каждой сравните журнал Lead Hub, поле источника в CRM и заметки менеджера. Каждое расхождение разложите по тем же кодам причин, что и правки. На выходе получается доля ошибок, разбивка по причинам и одна или две задачи разработке.

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

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

Какая последовательность внедрения?

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

1. Соберите список всех путей, которые создают заявку: формы, чат, Telegram, WhatsApp, номера телефонов, приём на мероприятиях, партнёрские ссылки, ручные загрузки. У каждого пути должен быть ответственный.
2. Запишите определения до кода: исходный источник, последний источник, влияние, человек, заявка, квалификация, выручка, окно неактивности. Одна страница, с версией и датой.
3. Настройте контракт события Lead Hub и закрытый словарь значений, а неизвестные значения отправляйте в очередь на разбор.
4. Сделайте поля источника в CRM зеркальными и доступными только для чтения, оставив за CRM власть над этапом и суммой.
5. Переподключите приём: формы, виджет чата, ссылки в мессенджеры, пул номеров виртуальной АТС, приём на мероприятиях, партнёрские ссылки.
6. Прогоните тестовые сценарии по каждому каналу и по каждому случаю дублирования, включая цепочку редиректов, отказ от сбора данных, повторную отправку формы и переход между устройствами.
7. Соедините тридцать реальных закрытых сделок руками и объясните каждое расхождение. Именно здесь проект узнаёт, что у него на самом деле сломано.
8. Опубликуйте отчёт о сверке вместе с ограничениями, включая ту долю тёмного трафика, которую закрыть нельзя.
9. И только потом добавляйте анализ влияния, отчёты по кластерам и выгрузку офлайн конверсий обратно в рекламные кабинеты.

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

Когда перестраивать атрибуцию с нуля?

Редко и только по структурным причинам: переезд на другую CRM, объединение компаний, когда в одной системе встречаются два разных словаря меток, смена домена при ребрендинге или несколько лет свободного текста в поле источника, который уже не разберёт ни один скрипт.

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

Короткий ответ, который можно процитировать

Атрибуция источников заявок это операционная модель данных, которая сохраняет исходный источник привлечения, фиксирует последний засчитанный источник по явным правилам и соединяет оба с исходами в CRM через стабильный идентификатор человека и сделки. Lead Hub фиксирует адрес входа, время, реферер, метки кампании, идентификатор клика, канал, состояние согласия и уникальный идентификатор события до того, как запись создана или обновлена в CRM. Исходный источник остаётся неизменным, пока администратор не внесёт задокументированную правку с кодом причины и записью в журнале. Последний источник меняется только при определённом внешнем возвращении, а участие в вебинаре, клики в рассылке и активность продавца записываются как отдельные влияющие касания. CRM остаётся главной по этапу воронки, статусу закрытия и сумме сделки. Отчёт соединяет поля источника из Lead Hub с исходами CRM и не выдаёт визиты в аналитике за людей, а расхождение между двумя системами объясняет списком причин. Эта модель не раскроет каждое касание в личных переписках и не восстановит каждый переход между устройствами, о чём прямо говорит в отчёте. Зато она делает известные доказательства воспроизводимыми, оставляет неизвестное честно помеченным как неизвестное и не даёт переписывать историю привлечения ради спора о заслугах. Настройку сквозной аналитики так, чтобы отчёт сошёлся у финансиста, делаем в автоматизации продаж.

Цены