Содержание
Сайт запустили. В отчёте уже есть визиты, клики и отправки формы. Менеджер помнит два разговора, один запрос точно не дошёл, а итог последнего никто не записал. Дашборд заполнен. Ответа на вопрос «что исправлять?» в нём пока нет.
После запуска достаточно измерять не всё подряд, а три разных факта: сделал ли человек действие на сайте, получила ли команда обращение и чем оно закончилось. У каждого факта должен быть владелец и решение, которое меняется после проверки.
Клик по кнопке не равен заявке, заявка не равна разговору, а разговор не равен выручке. Когда эти вещи складывают в один красивый график, цифр становится больше, ясности меньше. Разведём их по местам и соберём минимальный рабочий маршрут.
Соберите три решения вместо одного дашборда
После запуска сайта часто появляется знакомое желание: поставить счётчики, собрать отчёт и наконец узнать «как оно работает». Через месяц в нём уже есть просмотры, клики и графики. Вопрос только один: какое решение владелец примет, если завтра показатель изменится?
Полезная метрика начинается с глагола. Проверить, читают ли страницу предложения. Убедиться, что форма доставляет обращение. Понять, получает ли клиент ответ. Разобрать причины, по которым разговоры не доходят до проекта. Если решение не названо, цифра остаётся декоративной. Почти как спидометр на самокате, который стоит в коридоре.
Цели Метрики описывают интересующие владельца действия посетителя: просмотр, клик, переход, отправку формы или оплату. Это подтверждает документация Яндекс Метрики. Цель говорит о событии, а не о том, было ли действие полезно бизнесу.
Первый слой живёт на сайте: человек увидел страницу, нажал кнопку, начал или отправил форму. Второй живёт в процессе: обращение получено, у него есть владелец, дан первый предметный ответ, понятен статус. Третий живёт в бизнесе: работа открыта, выиграна, проиграна или ещё не закончена.
Каждый слой отвечает на свой вопрос, но один не заменяет другой. Сайт может честно зафиксировать отправку, пока письмо не дошло. Менеджер может ответить, но клиент выберет другого исполнителя. Сделка может состояться после нескольких касаний, и нельзя без доказательства приписать её одному визиту.
Практический вывод: сначала разделите три факта и решение по каждому. Только затем выбирайте событие, отчёт или интеграцию.
Событие сайта подтверждает действие, не качество лида
Для первой проверки хватит нескольких наблюдаемых действий: открыли ли нужную страницу, нажали ли на способ связи, начали ли форму, отправили ли её. У каждого события должна быть понятная роль. Например, отправка формы помогает проверить технический маршрут, а не ответить на вопрос о качестве будущего проекта.
В статистике сайта можно отдельно отметить отправку формы или запрос информации. Это полезно для единого учёта, но не для оценки качества лида. Отправка формы и последующие статусы – разные вещи: система не знает, стала ли заявка подходящей или завершилась сделкой.
Не передавайте в события текст заявки, email, телефон или другие персональные идентификаторы. Google прямо запрещает отправлять PII через события, параметры и URL; локальные правила обработки данных при этом всё равно нужно проверять отдельно.
Небольшой вывод: сайт отвечает за правду о действиях в интерфейсе. Он не знает, почему человек передумал и насколько полезен разговор.
Обработка обращения требует владельца статуса
После кнопки начинается территория команды. Самый небольшой рабочий набор здесь: факт получения, кто отвечает, когда дан первый предметный ответ и как определяют квалифицированное обращение. Эти статусы можно вести в CRM, таблице или другом общем журнале. Формат не важнее дисциплины.
Слово «квалифицирован» должно означать одно и то же для всех. Иначе это не показатель, а настроение в конце дня. Статистику можно настроить под этапы работы, но она не придумает бизнесу определение, критерий или ответственного.
Практический вывод: статус работает только тогда, когда у него есть короткое определение, момент фиксации и человек, который его обновляет.
Итог сделки нельзя честно угадать по клику
Третий слой нужен для управленческого вывода: выиграно, проиграно или ещё открыто. Если есть причина отказа, её полезно записать обычным языком. Не для наказания канала, а чтобы отличить неподходящую задачу от отсутствия ответа, цены, срока или доказательства.
CRM-данные можно связывать с визитами Метрики, чтобы сравнивать заявки, статусы и реальные продажи. Документация Метрики описывает такую возможность, но не обещает готовую бесшовную интеграцию, безошибочное сопоставление или точную атрибуцию.
Иногда правильный статус будет «неизвестно». Например, клиент вернулся позже по рекомендации или обсуждал проект в нескольких каналах. Лучше оставить это как границу данных, чем дорисовать сайту чужую заслугу.
Что важно для результата: коммерческий итог должен быть зафиксирован там, где он реально известен, а не вычислен задним числом из посещаемости.
Соберите журнал на четырнадцать дней
На четырнадцать дней заведите одну анонимизированную строку на обращение. Запишите источник или страницу, целевое действие, факт получения, время первого предметного ответа, статус квалификации и итог либо «открыто». Не переносите туда контакты и содержание заявки.
В конце периода не спешите считать универсальную конверсию. Сначала найдите первый пропавший факт. Не видно действия на сайте? Нет подтверждения доставки? Никто не обновляет статус? Итог не возвращается в журнал? Исправьте один самый ранний разрыв и повторите проверку.
Две недели не доказывают окупаемость, сезонность или причинность. Зато такой журнал показывает, где процесс перестаёт быть наблюдаемым. Это уже достаточная причина для одного точного улучшения.
Результат проверки: у каждого обращения появляется цепочка фактов, а у первого пустого звена появляется владелец исправления.
Начните с минимума, по которому готовы действовать
После запуска сайта не нужен отчёт на все случаи жизни. Нужен короткий набор фактов, который помогает увидеть: человек сделал действие, команда его обработала, результат известен или честно остаётся открытым.
Когда этих трёх слоёв пока нет, не стоит покупать сложную сквозную аналитику ради ощущения контроля. Сначала договоритесь о статусах и владельцах, проверьте один маршрут и убедитесь, что данные не содержат лишнего. Усложнение имеет смысл после появления устойчивого процесса, а не вместо него.
Главный вывод: хорошая аналитика не объясняет всё. Она вовремя показывает факт, после которого команда знает, что проверить и кто это сделает.
Пять вопросов после настройки первого журнала
Сколько целей нужно поставить в Метрике?
Столько, сколько действий действительно меняют решение владельца. Лучше несколько проверяемых целей с понятной ролью, чем длинный список кликов без дальнейшего действия.
Можно ли вести статусы не в CRM?
Да. На старте подойдёт общая таблица, если у неё есть доступный владельцу процесс, ответственные и единые значения статусов. CRM становится нужна, когда таблица уже не выдерживает работу команды.
Отправка формы считается заявкой?
Это факт отправки на сайте. Чтобы назвать её заявкой в рабочем смысле, нужно отдельно подтвердить получение, отсутствие технической ошибки и выбранное бизнесом правило статуса.
Надо ли передавать в аналитику телефон и текст обращения?
Нет. В аналитические события не должны попадать персональные идентификаторы и содержание заявки. Для операционной работы используйте систему, где такие данные обрабатываются по отдельным правилам.
Когда можно судить о результате сайта?
Когда есть достаточный для вашей модели период и число завершённых маршрутов. Две недели полезны для поиска технического разрыва, но обычно недостаточны для вывода об окупаемости или причине продаж.
Что можно проверить самостоятельно
Источники описывают возможности целей, CRM-связки и событий. Они не доказывают окупаемость, причинность или точную атрибуцию конкретной продажи.
- Какие действия посетителя можно учитывать Какие действия посетителя можно считать целью и почему событие нужно выбирать от решения владельца. Открыть источник ↗
- Как связать историю визита и результат сделки Как связываются данные о клиентах и заказах с визитами и какие возможности даёт такой контур. Открыть источник ↗
- Как различать отправку формы и этапы работы с заявкой Последовательность событий от создания обращения до квалификации и закрытия в аналитике. Открыть источник ↗
- Какие личные данные нельзя передавать в статистику Ограничения на передачу персональных идентификаторов через события, параметры и URL. Открыть источник ↗
- Лендинг запустили, а заявок нет: что проверить до покупки нового трафикаПрактическая проверка лендинга без заявок: источник трафика, обещание первого экрана, целевое действие, доставка обращения и ответ сотрудника.Прочитать разбор ↗
