Сквозная аналитика связывает известный источник обращения с заявкой, сделкой и оплатой. Она помогает сопоставить результат каналов с расходами. Выручка при этом не равна прибыли: для оценки окупаемости нужны согласованные затраты, маржа, возвраты и период.
Спор «SEO работает — SEO не работает» я слышал столько раз, что узнаю его по первым двум репликам. Подрядчик показывает график органического трафика вверх. Клиент отвечает, что заявок больше не стало. Оба говорят правду, и ни один не может её доказать: между визитом на сайте и деньгами в кассе не протянуто ни одной ниточки. Пока её нет, спор решает не цифра, а тон голоса.
Ниже — как собрать минимальную связку: цель после сохранения заявки, единая схема меток для внешних кампаний, источник и идентификаторы в CRM, учёт звонков при необходимости. Сначала определите доступные данные и критерии приёмки; срок зависит от форм, CRM и интеграций.
Сквозная аналитика — что это на самом деле
Речь о цепочке наблюдений: источник визита, действие на сайте, заявка, сделка и оплата. У этой цепочки бывают разрывы — блокировщики, разные устройства, звонки, потерянные идентификаторы. Их отмечают как неизвестные данные, а не распределяют по каналам наугад.
| Звено | Где живёт | Чем рвётся |
|---|---|---|
| Откуда пришёл человек | Метрика, метка в адресе страницы | Метку съел редирект, переход из мессенджера, прямой заход |
| Что он сделал на сайте | Цель в Метрике | Цель считает клик вместо отправки, форма вообще без цели |
| Во что превратилась заявка | CRM или хотя бы таблица | Сделку не завели, дубли, звонок прошёл мимо системы |
| Сколько денег принесла сделка | CRM, касса, бухгалтерия | Оплата частями, возвраты, сделка тянется месяцами |
Веб-аналитика и CRM считают разные события. Общие идентификаторы помогают связать их, но один посетитель может сделать несколько заявок, а у одной сделки бывает несколько контактов. До отчёта согласуйте, что считается уникальной заявкой, квалифицированным обращением и продажей.
Отсюда мысль, полезная до всяких покупок: сервис цепочку не создаёт, он её показывает. Нет звеньев — вы платите за интерфейс, в котором те же пробелы выглядят убедительнее.
Почему без неё спор о результате не решается
Возьмите два канала, которые за месяц дали поровну заявок. Один приводит людей по запросам вида «сколько стоит» — они спрашивают цену и покупают. Второй по запросам «своими руками» — эти скачивают инструкцию и уходят навсегда. В отчёте по конверсиям каналы неотличимы. В кассе разница видна сразу, только касса не знает, кого благодарить.
Дальше — одно из трёх. Бюджет режут наугад, обычно тому каналу, у кого не нашлось защитника в переговорной. Меняют подрядчика, и следующий начинает с нуля. Или платят за оба год за годом. Каждый исход дороже, чем настройка измерения.
Есть и обратная сторона, про которую подрядчики говорят реже. Реклама разогревает бренд: человек увидел объявление, через неделю набрал название компании в поиске и пришёл из органики. Формально заявку засчитает SEO. Честно — заслуга общая. Без связки такой разговор не состоится вообще, а с ней он хотя бы идёт про данные, а не про самолюбие.
Перед изменением бюджета проверьте, что сравниваете одинаковые стадии воронки и достаточно зрелые сделки. При длинном цикле покупки сегодняшние оплаты относятся к обращениям прошлых месяцев. Изменение бюджета стоит оценивать по этой истории, а не только по конверсиям последней недели.
Минимальная сборка: четыре элемента
Начать можно с функций Метрики, сайта и CRM. Стоимость внедрения определяется текущими интеграциями; даже бесплатный счётчик требует работы по настройке и проверке. Коллтрекинг оценивают отдельно, когда важны телефонные обращения.
| Элемент | Что даёт | Чем оплачивается |
|---|---|---|
| Цели в Метрике | Разделяют попытку и подтверждённое действие | Настройка и проверка каждой логики отправки |
| Единая схема UTM | Различает внешние кампании | Согласованный словарь и проверка ссылок |
| Поле «источник» в форме и в CRM | Сохраняет доступные данные перехода | Разработка, интеграция и проверка |
| Коллтрекинг | Привязывает звонок к каналу | Помесячная плата за номера |
Цели в Метрике: считаем результат, а не намерение
Для учёта заявки целью выбирают подтверждённое действие. Клик по кнопке показывает намерение: человек мог не пройти валидацию или получить ошибку сервера. Поэтому цели клика и успешного сохранения должны иметь разные названия и смысл в отчёте.
Порядок, в котором я выбираю тип цели:
- Событие, которое сайт отправляет после успешного ответа сервера. Самый честный вариант; просить у разработчика надо именно его.
- Посещение страницы «спасибо». Годится, если такая страница есть и попасть на неё иначе нельзя.
- Штатный тип «отправка формы». Полезен как дополнительный сигнал, но его нужно проверить на ошибках валидации и сервера. Автоцель сама по себе не подтверждает запись в CRM.
Дальше — правила, которые экономят месяцы разбирательств:
- Разделяйте разные бизнес-действия. Для одинаковой заявки с нескольких страниц допустима общая цель с безопасным идентификатором формы и путём страницы; не передавайте имя, телефон и текст обращения.
- Имена по единой схеме, латиницей: form_calc, form_callback, phone_click. Через полгода целей будет три десятка, и строка «Цель 4 (новая)» не скажет вам ничего.
- Микроцели вроде скролла и двух минут на странице держите отдельно от заявок. Смешаете — конверсия раздуется, и отчёт начнёт врать в приятную сторону.
- Переход в мессенджер — это переход, а не заявка. Отдельная цель, отдельная строка в отчёте.
Проверьте успешную отправку, ошибку сервера, незаполненные поля и повторный клик. В контролируемом тесте успешная заявка должна сохраниться один раз, а ошибка не должна достигать цели успеха. Клиентское событие может потеряться из-за блокировщика или закрытия вкладки; реестр сохранённых заявок остаётся первичным источником.
UTM-метки: одна схема на всю рекламу
UTM-метки — параметры внешней ссылки, которые помогают различать источники и кампании. Ниже пять распространённых полей. Их значения согласовывают заранее; требования к распознаванию источника зависят от конкретной системы и канала.
| Параметр | Что в нём | Пример |
|---|---|---|
| utm_source | площадка | yandex, vk, telegram |
| utm_medium | тип трафика | cpc, email, social, banner |
| utm_campaign | кампания | remont-avgust |
| utm_content | что именно кликнули | banner-1, text-2 |
| utm_term | ключевая фраза | remont-kvartir |
Для своей схемы обычно заполняют source, medium и campaign, чтобы различать площадку, канал и кампанию. Это рабочее правило, а не одинаковое техническое требование всех сервисов: Метрика описывает обязательные поля по источникам. Content и term добавляйте, когда они нужны для анализа.
- Латиница, нижний регистр, вместо пробелов — дефис или подчёркивание. Yandex и yandex счётчик считает разными значениями, и в отчёте будет две строки вместо одной.
- Один словарь значений на всю компанию: какие source разрешены, какие medium, как называть кампании. Без словаря схема расползается за квартал.
- Не используйте UTM для измерения внутренних кнопок: для них подходят события. Метрика берёт метку из первого просмотра визита; внутренний переход с UTM не обязательно создаёт новый визит. Размеченная ссылка, открытая как новый вход, способна исказить источник.
- Органическую выдачу метить нельзя и не нужно — источник поиска счётчик определяет сам.
- Смотреть результат: Отчёты → Источники → Метки UTM. Пустой отчёт при живой рекламе — сигнал, а не особенность.
На стыке людей: один пишет source=yandex, другой — yandex_direct, третий меняет medium. Сырые значения будут разными. Их можно нормализовать в отдельном анализе по сохранённому правилу, но это не исправляет автоматически исторические отчёты кабинета. Храните словарь и журнал изменений.
Поле «источник» в форме и в CRM
Метка живёт в браузере и до CRM сама не доедет. Её кладут в форму: скрытое поле, которое скрипт заполняет при отправке, а сервер передаёт дальше вместе с именем и телефоном.
- Первый известный источник — сохранённое наблюдение в пределах доступной истории. Оно может не совпадать с самым первым знакомством человека с компанией.
- Последний источник — откуда он пришёл в тот раз, когда оставил заявку.
- ClientID Метрики, когда он доступен, и отдельные ID заявки и сделки. Это разные сущности: идентификатор браузера нельзя считать удостоверением личности клиента.
- Адрес страницы, с которой отправили форму. Помогает понять, какая страница продаёт.
Метод getClientID возвращает идентификатор посетителя в Метрике. Он может быть недоступен при блокировке счётчика; разные браузеры и устройства дают разрывы. Для передачи офлайн-конверсий нужны поддерживаемые идентификаторы, даты и правила загрузки. Наличие ClientID в CRM само по себе не создаёт полную сквозную аналитику.
Поле «откуда вы о нас узнали» полезно как отдельный ответ клиента. Не заменяйте им измеренный источник и не смешивайте эти поля: человек может назвать рекомендацию, хотя текущий визит пришёл из поиска.
Автоматическую передачу проверяют по тестовой заявке: время, страница, доступный источник, ID и сумма в нужном поле. Если часть данных отсутствует, сохраняйте это состояние явно. Не блокируйте приём обращения только из-за отсутствия ClientID.
Коллтрекинг: только там, где звонков много
Звонок — самое дырявое звено цепочки. Человек посмотрел сайт, набрал номер, и с этого момента он для аналитики исчез. Лечится двумя способами.
Статический коллтрекинг использует разные номера для каналов. Динамический связывает подменный номер с визитом по правилам сервиса; точность зависит от размера пула, времени закрепления и корректной подмены. Оба варианта нужно проверять на реальных сценариях, включая повторные и пропущенные звонки.
Начните с числа и ценности телефонных обращений. Если звонки редки, может хватить отдельного учёта; если они значимы, сравните цену коллтрекинга с задачей измерения. Один номер только для сайта отделяет его от других размещений лишь при соблюдении этого правила, но не разделяет каналы внутри сайта.
Что собирается за неделю, а что строится месяцами
Первый этап — настроить события, схему меток и передачу доступного источника в CRM, затем проверить всю цепочку. На простом сайте это может занять короткий цикл; сложные интеграции, несколько доменов и нестандартные формы требуют отдельной оценки.
Месяцами строится всё остальное, и тут обычно наступает разочарование:
- Дисциплина. Менеджер, который заводит сделку через два дня по памяти, ломает цепочку надёжнее любого редиректа. Настройка это не чинит — чинит регламент и привычка.
- Статусы сделок. Пока «в работе» означает и «завтра оплатит», и «пропал полгода назад», выручку по каналам не посчитать.
- Сумма сделки. Она должна попадать в карточку, а не в голову руководителя. Частичные оплаты, скидки, возвраты — всё это надо однажды описать словами.
- Цикл сделки. Если от заявки до денег проходит четыре месяца, первая честная картина появится не раньше, чем закроется первая когорта. Не через неделю после настройки, как хочется.
- Сезонность. Сравнивать надо одинаковые календарные периоды, а для этого нужна история хотя бы в год.
Новая цель не восстановит события, которые счётчик не собирал. Часть истории иногда можно сверить по сохранённым CRM, логам, оплатам и выгрузкам, но отсутствующие идентификаторы и переходы придумывать нельзя. Поэтому до старта работ фиксируют, с какой даты и с какой полнотой доступны показатели.
Где начинается граница платного сервиса
Минимальная версия упирается в потолок, и признаки узнаваемые. Каналов стало больше трёх-четырёх, сайтов и лендингов несколько, звонки составляют заметную долю обращений. Путь клиента длинный, с несколькими касаниями, и вопрос «кому засчитать заявку» перестал быть праздным. Расходы по кабинетам сводятся руками, и на это уходит день в месяц.
Внешний сервис может объединять расходы, визиты и сделки, хранить историю и применять разные модели атрибуции. Состав зависит от продукта и интеграции. В Метрике тоже доступны модели атрибуции: они по-разному распределяют наблюдаемые конверсии и не доказывают причинный вклад канала.
Чего платный сервис не делает — так это не чинит ваши цели и метки. Он перенесёт в дорогой интерфейс всё, что было сломано, и добавит сломанному убедительности. Порядок правильный ровно один: сначала данные, потом сервис. Сомневаетесь, на каком вы этапе, — посмотрите направление «Аналитика и отчётность».
Типичные поломки
Дальше — неисправности из каждой второй сборки. Все тихие: цифры есть, выглядят правдоподобно и означают не то, что вы думаете.
Метки, которые теряются при редиректе
Редирект умеет отбрасывать хвост адреса вместе с меткой. Чаще всего виновато правило переписывания, которое собирает новый адрес и забывает про параметры. Отдельная беда — цепочка переходов подряд: с http на https, потом с www на без www, потом на адрес со слешем в конце. Достаточно, чтобы на одном шаге параметры не перенесли.
Откройте тестовую размеченную ссылку и проверьте цепочку редиректов, первый просмотр счётчика и сохранённый источник в CRM. Наличие метки в адресной строке — только один шаг. При потере UTM источник может определиться по рефереру или остаться неизвестным; не весь такой трафик автоматически становится прямым. Параметры кампании размещают перед фрагментом после решётки.
Отдельно проверьте возврат с платёжного шлюза и переходы между доменами: они могут менять наблюдаемый источник в зависимости от настроек и модели. Сохраняйте данные до передачи на оплату и сверяйте их после возврата.
Цели, которые считают каждый клик
Цель, повешенная на клик по кнопке, считает попытки, а не заявки. Не прошла проверка, не заполнено поле, отвалился сервер — цель всё равно сработала. Разница между попытками и заявками в живой форме бывает заметной, и вся она уходит подрядчику в плюс.
Второй вид того же — двойной учёт. Настроили и цель на клик, и цель на страницу «спасибо», а в отчёте суммируете обе: одна заявка превращается в две. Сюда же попадает страница благодарности, которую проиндексировал поиск: на неё начинают заходить напрямую, и цель отмечает конверсии, за которыми нет ни одного обращения.
Сопоставьте достижения цели и записи заявок за один период и часовой пояс, исключив тесты и согласованные дубли. Расхождения разберите по причинам: повторные события, потери счётчика, задержка загрузки, разные определения заявки. Универсального допустимого коэффициента нет.
Звонки, которые не привязаны ни к чему
Если один номер указан на сайте, в справочниках и письмах, по самому номеру нельзя определить канал звонка. Дополнительные сведения CRM и ответ клиента могут помочь, но их полноту отмечают отдельно от измеренного источника.
Рядом живут поломки помельче, но такие же живучие. Номер, выложенный картинкой: его нельзя ни кликнуть, ни подменить. Личный мобильный руководителя из переписки — обращение уходит мимо системы целиком. Пропущенные звонки, которые нигде не учитываются, хотя это тоже обращения.
Как проверить, что связка работает
Проверку начните с доступных кабинетов и тестового сценария. Для поиска разрыва между формой, сервером и CRM может понадобиться разработчик; длительность зависит от интеграций.
- Оставьте тестовую заявку через каждую форму на сайте. Дошла ли она до CRM? Виден ли в ней источник и адрес страницы?
- Перейдите по рекламной ссылке с меткой и убедитесь, что хвост остался в адресной строке после всех редиректов.
- Сверьте цели и сохранённые заявки за один период, разберите тесты, дубли, задержки и потери аналитики.
- Позвоните на номер с сайта и найдите этот звонок в системе. Указан ли канал?
- Откройте любую закрытую сделку месячной давности и назовите канал, который её привёл.
Пятый пункт проверяет доступность подтверждений. Если источник неизвестен, честный результат — «не определён» с причиной. Это полезнее, чем вручную назначить канал ради заполненной таблицы.
Если расхождения нашлись, а причины неясны, соберите сценарий, примеры записей и настройки отчётов. Состав отдельной проверки описан в аудите веб-аналитики.
Короткий чек-лист
Каждый минус — место, где отчёт о каналах врёт, даже если выглядит убедительно.
- Цели считают завершённые действия, а не клики по кнопкам
- Разные бизнес-действия разделены, для общей цели заявки различимы форма и страница
- Каждая цель проверена живой тестовой заявкой
- Схема UTM записана одним документом и известна всем, кто ставит ссылки
- Метка доезжает до сайта через все редиректы
- Внутренние ссылки сайта метками не размечены
- В форме есть скрытое поле с источником и идентификатором посетителя
- Источник приезжает в сделку автоматически, без участия менеджера
- Сумма сделки попадает в карточку, а не остаётся в голове руководителя
- Звонки либо разделены по каналам, либо честно посчитаны отдельной строкой
- Определения, период и часовой пояс сверены; причины расхождений Метрики и CRM описаны
- По сделке видны доступные данные источника, модель атрибуции и пробелы измерения
Начните измерение до оценки продвижения: согласуйте события, источники и доступ к данным. Тогда разговор о результате будет опираться на сохранённые заявки и оплаты с известными ограничениями, а не только на график посещаемости.