Как отслеживать заявки из блога

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

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

Почему заявки из блога часто теряются

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

Причина простая: пользовательский путь редко выглядит как «прочитал статью → сразу отправил форму в этой же статье». Чаще человек:

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

Если сайт не сохраняет контекст, такая заявка будет выглядеть как обычное обращение с сайта. Владелец увидит заявку, но не увидит, что статья участвовала в принятии решения.

Без дополнительной настройки обычно видно:

• просмотры статей;
• источники трафика;
• переходы между страницами;
• общую отправку формы;
• количество заявок по сайту.

Но часто не видно:

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

Из-за этого блог начинают оценивать по косвенным признакам: трафику, времени на странице, позициям, количеству опубликованных материалов. Эти метрики полезны, но они не отвечают на главный бизнес-вопрос: участвует ли блог в появлении заявок и каких именно.

Если на сайте уже есть трафик, но непонятно, почему обращения не фиксируются или не доходят до бизнеса, сначала стоит проверить всю воронку. Об этом подробнее — в статье «Почему сайт не приносит заявки».

Что считать заявкой из блога

Перед настройкой аналитики нужно договориться о правилах атрибуции. Иначе разные люди в команде будут понимать «заявку из блога» по-разному.

Есть несколько разных сценариев.

Прямая заявка из статьи

Пользователь читает материал и отправляет форму прямо внутри статьи: например, форму «обсудить задачу», «задать вопрос», «получить консультацию по сайту».

В этом случае всё относительно понятно: форма находится в статье, значит заявка напрямую связана с блогом. Но даже здесь нужно передавать не только контакт, а и контекст: URL статьи, название материала, ID формы, источник blog, идентификатор CTA.

Заявка после клика из статьи

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

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

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

Заявка после входа через блог

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

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

Блог как вспомогательный этап

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

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

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

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

Какие вопросы нужно решить до настройки

Перед разработкой или доработкой аналитики полезно зафиксировать несколько правил.

Ответьте на вопросы:

1. Считаем ли заявку блоговой, если форма отправлена прямо в статье?
2. Считаем ли заявку блоговой, если пользователь перешёл из статьи на страницу услуги и отправил форму там?
3. Нужно ли сохранять первую страницу входа на сайт?
4. Нужно ли сохранять последнюю статью перед заявкой?
5. Нужно ли видеть конкретную статью или достаточно признака source=blog?
6. Нужно ли разделять рубрики и темы блога?
7. Где эти данные должны быть видны: в Метрике, CRM, почтовом уведомлении, админке сайта?
8. Кто будет смотреть эти данные и какие решения принимать на их основе?

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

Какие CTA нужны в статьях

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

В статье могут использоваться разные типы CTA:

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

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

Примеры формулировок:

• «Обсудить, как фиксировать заявки с сайта»
• «Разобрать аналитику заявок на вашем сайте»
• «Поставить задачу на доработку форм и целей»
• «Проверить, теряются ли заявки из блога»
• «Обсудить структуру заявки и передачу данных»

Хороший CTA для статьи отвечает нескольким критериям:

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

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

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

Какие данные должна передавать форма

Форма заявки часто воспринимается как набор видимых полей: имя, телефон, email, комментарий. Для отслеживания блога этого недостаточно.

Форма должна передавать две группы данных.

Первая группа — пользовательские данные:

• имя;
• телефон или email;
• комментарий;
• выбранная услуга или тема, если такое поле есть.

Вторая группа — служебные данные:

• URL текущей страницы;
• название статьи;
• source=blog;
• entrypoint;
• ID формы;
• ID или название CTA;
• страница фактической отправки;
• рубрика или тема статьи, если это используется в аналитике.

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

Для этой статьи логика могла бы выглядеть так:

• source=blog
• entrypoint=blog_article_kak-otslezhivat-zayavki-iz-bloga

source=blog показывает, что заявка связана с блоговым сценарием. entrypoint=blog_article_kak-otslezhivat-zayavki-iz-bloga показывает конкретную статью, из которой начался или был зафиксирован путь.

Это не рекламная UTM-метка. UTM обычно описывает внешний источник трафика: рекламную кампанию, канал, объявление. entrypoint — внутренний параметр сайта. Он помогает понять, из какого контента пользователь вошёл в сценарий заявки.

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

Минимальный набор, который стоит передавать вместе с заявкой:

1. Контакт пользователя.
2. Комментарий или выбранную тему.
3. URL страницы, где была отправлена форма.
4. Источник внутри сайта: blog.
5. Entry point: конкретная статья.
6. ID формы.
7. ID CTA или блока.
8. Время отправки.
9. Технический статус успешной отправки.

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

Какие цели и события нужны в аналитике

Для блога нужно разделять три разных уровня действий:

• просмотр статьи;
• клик по CTA;
• отправку заявки.

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

Типичная ошибка — считать все клики по кнопкам одной целью. Тогда в отчётах смешиваются:

• клики по ссылкам на другие статьи;
• клики по кнопкам услуг;
• открытия формы;
• попытки отправки;
• реальные успешные заявки.

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

Пример логики событий для блога:

• blog_article_view — просмотр статьи;
• blog_cta_click — клик по CTA в статье;
• blog_form_open — открытие формы, если она раскрывается отдельно;
• blog_form_submit — успешная отправка формы из статьи;
• lead_submit с параметром source=blog — общая заявка, связанная с блогом.

Это не универсальный стандарт названий. Главное — чтобы система была понятной и устойчивой. Через несколько месяцев по названию события должно быть ясно, что оно означает и где срабатывает.

Для событий полезно передавать параметры:

• URL статьи;
• title статьи;
• тип CTA;
• позицию CTA;
• form_id;
• submit_url;
• entrypoint;
• source.

Тогда можно смотреть не только «сколько было заявок», но и какие материалы, блоки и сценарии чаще приводят к действиям.

Проверки для целей:

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

Если цели уже настроены, но по ним невозможно отделить блог от остальных разделов, настройку стоит пересмотреть. Базовую логику целей для сайта можно сверить со статьёй «Какие цели Метрики нужны сайту».

Что такое entrypoint и зачем он нужен

Entrypoint — это точка входа пользователя в сценарий. В контексте блога это обычно статья, с которой начался интерес или из которой пользователь перешёл к заявке.

Без entrypoint аналитика часто приписывает заявку последней странице. Например:

Пользователь → статья блога → CTA → страница услуги → форма → заявка

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

Для каждого этапа можно сохранять свой контекст:

• статья: URL и title;
• CTA: id и position;
• страница назначения: destination URL;
• форма: form_id;
• заявка: source и entrypoint.

Полезно различать несколько понятий:

• первая страница входа на сайт;
• первая статья блога в сессии;
• последняя статья перед заявкой;
• страница фактической отправки формы;
• внутренний источник заявки: blog, service, catalog, homepage.

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

Как не смешивать блог с рекламой и другими источниками

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

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

Разделять нужно минимум две вещи:

• внешний источник трафика;
• внутренний путь по сайту.

Внешний источник отвечает на вопрос: откуда пришёл пользователь на сайт. Внутренний путь отвечает на вопрос: что он сделал на сайте перед заявкой.

Например, пользователь мог прийти из рекламы, затем прочитать статью и оставить заявку. Внешний источник — реклама. Внутреннее касание — блог.

Или пользователь мог прийти из поиска прямо на статью, потом перейти на услугу. Внешний источник — органический поиск. Внутренний entrypoint — статья блога.

Если не разделять эти уровни, возникают ошибки:

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

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

Что должно быть видно в заявке

Отчёт в аналитике полезен, но заявку обрабатывает человек. Если менеджер или владелец видит только «Имя + телефон + комментарий», часть контекста теряется.

В уведомлении или карточке заявки желательно видеть:

• с какой страницы отправлена форма;
• какая статья была entrypoint;
• какой CTA использовал пользователь;
• какая форма сработала;
• какой внутренний источник указан;
• какой внешний источник трафика известен, если он передаётся;
• комментарий пользователя.

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

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

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

Типичные ошибки при отслеживании заявок из блога

Оценивать блог только по просмотрам

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

Это не делает статью бесполезной. Она может работать на узнаваемость, доверие, объяснение сложной темы. Но для оценки заявок нужны отдельные события и формы.

Ставить одинаковые CTA во всех статьях

Если в каждой статье одна и та же кнопка без идентификатора, аналитика не покажет, какой материал и какой блок сработали.

Лучше, чтобы CTA имели понятные различия: по статье, теме, расположению и назначению.

Считать клик по кнопке заявкой

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

Не передавать служебные поля

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

Хранить данные только в аналитике

Аналитика показывает отчёты, но обработка заявки происходит в почте, CRM или админке. Если туда не попадает source, entrypoint и URL статьи, данные будут неполными.

Не проверять весь путь

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

Проверять нужно не отдельный счётчик, а всю цепочку.

Как проверить, что отслеживание работает

После настройки стоит пройти путь пользователя вручную. Не на уровне «форма отправляется», а с проверкой всех данных.

Базовый чек-лист:

1. Открыть статью блога.
2. Нажать CTA внутри статьи.
3. Проверить, что клик зафиксирован как отдельное событие.
4. Открыть или перейти к форме.
5. Отправить тестовую заявку.
6. Убедиться, что цель сработала после успешной отправки.
7. Проверить, что ошибочная отправка не считается заявкой.
8. Открыть письмо, CRM или админку, куда пришла заявка.
9. Проверить наличие URL статьи.
10. Проверить source=blog.
11. Проверить entrypoint.
12. Проверить ID формы.
13. Проверить ID или название CTA.
14. Убедиться, что заявка не смешалась с формами главной, услуг или каталога.

Проверять нужно разные сценарии:

• форма прямо внутри статьи;
• CTA из статьи на страницу услуги;
• переход из статьи в контакты;
• заявка после просмотра нескольких страниц;
• возврат к форме после ошибки заполнения.

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

Какие решения можно принимать по этим данным

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

По данным можно понять:

• какие статьи приводят к прямым обращениям;
• какие статьи чаще переводят пользователей в коммерческие разделы;
• какие CTA получают клики, но не доводят до формы;
• какие темы вызывают интерес, но не дают заявок;
• где форма теряет пользователей;
• какие материалы стоит обновить, дополнить или связать с услугами;
• какие статьи лучше использовать как вспомогательные, а не продающие.

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

Минимальная схема для сайта

Для нормального отслеживания заявок из блога сайту нужна простая, но связанная схема:

• в статьях есть понятные CTA;
• каждый CTA имеет идентификатор;
• формы передают скрытые служебные поля;
• в заявке сохраняется source=blog;
• для статьи передаётся entrypoint;
• события разделяют просмотр, клик, открытие формы и отправку;
• цель срабатывает только после успешной отправки;
• данные доходят в место обработки заявки;
• отчёты позволяют отделить блог от главной, услуг, каталога и рекламы.

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

Безопасный следующий шаг

Если блог уже есть, начинать стоит не с переделки всех статей, а с аудита текущего пути заявки.

Проверьте:

• есть ли CTA в статьях;
• можно ли отличить один CTA от другого;
• есть ли формы внутри блога;
• какие цели срабатывают в аналитике;
• что именно приходит в заявку;
• сохраняется ли URL статьи;
• передаётся ли source=blog;
• есть ли entrypoint;
• можно ли отделить заявки из блога от остальных обращений.

После этого проще поставить задачу на доработку: какие поля добавить в формы, какие события настроить, какие CTA переименовать, какие сценарии проверить.

Главная цель — не доказать, что блог «точно приносит заявки», а создать систему, в которой его вклад можно увидеть без догадок. Тогда решения по контенту, структуре сайта, формам и аналитике будут опираться не только на просмотры, а на реальные действия пользователей.