Бывает ситуация, в которой всё сделано правильно, а отчёты показывают катастрофу. Профили чистые, адреса нормальные, сценарий проработан: бот заходит, читает, переходит в другой раздел, возвращается, открывает контакты. По логу сценария — образцовый визит. В счётчике — один просмотр, ноль секунд, отказ. И так по всей партии.
Причина в устройстве сайта. На одностраничных приложениях переход между разделами происходит без перезагрузки: адрес в строке меняется программно, содержимое подменяется на лету, а страница как документ остаётся той же самой. Счётчик, который по умолчанию считает просмотр в момент загрузки документа, такой переход не видит. Дальше разберём, где именно рвётся цепочка измерений, какие показатели при этом искажаются, что надо править в разметке и настройках, и как проверить, что починка сработала.
Почему счётчик не видит переходов
Классическая схема измерения построена на простом допущении: один просмотр страницы равен одной загрузке документа. Код счётчика срабатывает при загрузке, отправляет обращение к серверу сбора данных, фиксирует адрес и заголовок. Пользователь кликает по ссылке, браузер грузит новый документ — код срабатывает снова. Так набирается глубина просмотра и так отсчитывается время между просмотрами.
Что происходит на одностраничном приложении
Здесь навигация устроена иначе. Клик по ссылке перехватывается кодом приложения, новый документ не запрашивается, а нужный кусок содержимого подгружается фоновым запросом и вставляется в текущую страницу. Адрес в строке при этом меняется программным вызовом, который переписывает запись в истории браузера. С точки зрения браузера документ не перезагружался — значит и событие загрузки не наступало.
Итог: код счётчика отработал один раз, при первом входе. Все последующие переходы для него не существуют. Человек может обойти десять разделов, но в отчёте останется один просмотр.
Почему это ломает сразу три показателя
- Глубина просмотра. Всегда единица, независимо от реального поведения. Визит с десятью переходами и визит с мгновенным уходом выглядят одинаково.
- Время на сайте. В классической модели длительность визита считается по разнице между первым и последним зафиксированным событием. Если событие было одно, разницы нет, и время получается нулевым или сильно заниженным.
- Отказ. Визит с единственным просмотром и нулевым временем попадает под определение отказа автоматически. Отсюда аномально высокая доля отказов на технически исправном сайте.
На одностраничном сайте плохие поведенческие показатели чаще означают неправильное измерение, а не плохое поведение. Прежде чем чинить трафик, убедитесь, что счётчик вообще способен зафиксировать то, что происходит.
Таблица: как искажаются показатели
| Показатель | Что происходит на самом деле | Что видит счётчик без настройки |
|---|---|---|
| Просмотры за визит | шесть разделов | один |
| Время на сайте | несколько минут | около нуля |
| Отказ | нет, человек изучал сайт | да, засчитан |
| Популярные страницы | распределены по разделам | вся масса на точке входа |
| Путь по сайту | осмысленная последовательность | пустой |
| Достижение цели на внутренней странице | произошло | не зафиксировано |
Как это выглядит со стороны работы с поведением
Для проекта, где идёт работа с поведенческими факторами, ситуация вдвойне обидная. Вы платите за качественные сессии с продуманным сценарием, бот честно отрабатывает маршрут, а сигнал до системы не доходит в нужном объёме.
Сигнал обедняется, а не исчезает
Важное уточнение: сессия не пропадает целиком. Факт визита зафиксирован, источник перехода известен, время присутствия отчасти определяется по вспомогательным событиям. Но богатая часть сигнала — маршрут по разделам, глубина, распределение внимания — теряется. Получается визит, который формально был, но выглядит поверхностным. Ровно тот тип сигнала, который вы стараетесь не создавать, о чём шла речь в материале про отказы и глубину просмотра.
Вебвизор записывает не всё
Инструмент записи сессий на одностраничных приложениях тоже ведёт себя своеобразно: запись может обрываться на смене раздела или склеивать разное содержимое в одну запись. Это мешает и вам — проверить, как отрабатывает сценарий, становится труднее. Про то, как запись сессий вообще используется для выявления неестественного поведения, подробно говорилось в разборе записи визитов как детектора.
Диагностика уходит не туда
Увидев высокую долю отказов, владелец начинает подозревать качество трафика и идёт менять исполнителя или инструмент. Деньги тратятся на то, что и так работало. Отличить одно от другого помогает простая проверка: если показатели одинаково плохие и у трафика от работы с поведением, и у обычной живой аудитории из поиска, и у прямых заходов — дело не в трафике, а в измерении. Дополнительно стоит посмотреть на оценку качества трафика так, как описано в материале про сегмент роботности: при технической проблеме измерения он обычно ничего аномального не показывает.
Что именно править
Отправлять просмотр вручную при смене адреса
Базовое решение — вызывать отправку просмотра в коде приложения каждый раз, когда меняется адрес. Большинство счётчиков предоставляет для этого отдельный метод, принимающий новый адрес и, при необходимости, адрес предыдущей страницы. Подключать его надо к тому месту приложения, где происходит смена маршрута, а не к произвольному событию.
Передавать корректный адрес источника
Частая недоработка: просмотр отправляется, но без указания предыдущего адреса. В результате в отчётах по путям пользователя переходы выглядят разорванными, а построение маршрута не работает. Передавать предыдущий адрес нужно всегда.
Обновлять заголовок страницы
На одностраничных приложениях заголовок документа часто остаётся неизменным при смене раздела. Тогда в отчётах все разделы называются одинаково, и разобрать, что смотрели, невозможно. Заголовок надо менять синхронно с адресом — это заодно полезно и для индексирования.
Не привязываться к событию изменения хеша
Старый приём — ловить изменение части адреса после решётки. Современные приложения меняют адрес через программный вызов, и такое событие при этом не возникает. Нужно подключаться к маршрутизатору приложения или отслеживать подмену методов работы с историей, а не полагаться на устаревший механизм.
Следить за дублями
Обратная крайность: вызов отправки просмотра срабатывает несколько раз на один переход — из-за повторной отрисовки компонента, срабатывания нескольких подписок или двойного вызова при запуске. Это надувает глубину просмотра искусственными цифрами. Дубли так же вредны, как пропуски, потому что создают неестественный профиль поведения: несколько просмотров одной страницы подряд с интервалом в доли секунды.
Проверить работу целей
Цели, настроенные на адрес страницы, на одностраничном приложении часто не срабатывают, потому что загрузки не было. Их надо переводить на события, которые приложение отправляет явно при нужном действии.
Таблица: типовая поломка и её починка
| Симптом | Причина | Что делать |
|---|---|---|
| Глубина всегда единица | просмотр отправляется только при загрузке | вызывать отправку при смене маршрута |
| Время визита около нуля | одно событие, нечего вычитать | добавить просмотры и события активности |
| Все разделы с одним названием | заголовок документа не меняется | обновлять заголовок вместе с адресом |
| Пути пользователя пустые | не передаётся предыдущий адрес | передавать адрес источника при отправке |
| Глубина неправдоподобно большая | дублирующиеся вызовы отправки | устранить повторные подписки и вызовы |
| Цели не срабатывают | цель привязана к загрузке адреса | перевести цель на событие приложения |
Что должен уметь сценарий бота на таком сайте
Даже после починки счётчика остаётся вторая половина задачи: сценарий должен взаимодействовать с сайтом так, чтобы приложение реально отработало навигацию.
Клик по элементу, а не переход по адресу
Если сценарий просто открывает новый адрес напрямую, приложение загрузится заново с нуля. Формально просмотр зафиксируется, но это будет выглядеть как отдельный вход, а не как переход внутри визита. Правильный путь — кликать по элементам навигации так, как это делает человек, чтобы сработал маршрутизатор.
Ожидание отрисовки
Содержимое подгружается асинхронно. Если сценарий кликает по следующему пункту меню сразу, не дожидаясь появления содержимого, получается серия мгновенных переходов — картина, ничем не похожая на человеческую. Между переходами нужна пауза на чтение, согласованная с реальным временем отрисовки.
Прокрутка и микродвижения
Загруженный без перезагрузки раздел не сбрасывает позицию прокрутки автоматически, если приложение этого не делает. Сценарий должен учитывать это и вести себя естественно: прокрутка вниз, возврат, паузы. Общие требования к правдоподобию движений разбирались в статье про эмуляцию мыши и прокрутки.
Порядок проверки за один вечер
- Откройте сайт и включите отчёт реального времени в счётчике. Пройдите по трём разделам кликами и посмотрите, появляются ли новые просмотры.
- Если не появляются — проблема подтверждена, дальше идёт настройка. Если появляются — переходите к проверке дублей.
- Проверьте, меняется ли заголовок документа при смене раздела. Если нет, исправьте это вместе с отправкой просмотра.
- Убедитесь, что при отправке передаётся предыдущий адрес, и посмотрите отчёт по путям пользователя: он должен перестать быть пустым.
- Пройдите один и тот же раздел дважды и проверьте, не появляется ли по два просмотра на переход.
- Проверьте срабатывание целей: выполните целевое действие на внутреннем разделе и убедитесь, что оно зафиксировано.
- Посмотрите запись сессии: она должна охватывать весь маршрут, а не обрываться на первом переходе.
- Сравните долю отказов до и после правок за сопоставимые периоды по одному и тому же источнику трафика.
- Только после этого возобновляйте работу с поведением в прежнем объёме и заново оценивайте её эффект.
Разбор кейса: сервис, который «не умел» держать посетителя
Онлайн-сервис с личным кабинетом и витриной тарифов был построен как одностраничное приложение. Владелец жаловался на стабильно высокую долю отказов и нулевую глубину: по отчётам выходило, что почти никто не смотрит больше одной страницы. Под это была заказана работа с поведенческими факторами — предполагалось, что нужно «показать поисковой системе» вовлечённость. Результата не было несколько месяцев, бюджет продолжал расходоваться.
При разборе первым делом сравнили показатели по разным источникам. Выяснилось, что картина одинаково плохая везде: и у переходов из поиска, и у прямых заходов, и у рекламы, и у сессий от работы с поведением. Это сразу указало на измерение, а не на трафик — у живой рекламной аудитории показатели такими быть не могли. Проверка в отчёте реального времени подтвердила: при переходах по разделам новые просмотры не появлялись вовсе, заголовок документа не менялся, отчёт по путям был пуст.
Правки заняли немного времени: отправку просмотра подключили к маршрутизатору приложения, добавили передачу предыдущего адреса, синхронизировали заголовок, перевели цели с адресов на события, устранили двойной вызов при первом запуске. Показатели сразу пришли в норму для всех источников без исключения — потому что поведение и раньше было нормальным, просто его не фиксировали. После этого работу с поведением перезапустили с корректным расчётом объёма по логике из материала про безопасный суточный лимит, и она наконец начала давать измеримый эффект. Главный урок: несколько месяцев бюджета ушли на компенсацию проблемы, которая была технической и решалась правкой в коде.
Частые ошибки
- Лечить измерение трафиком. Плохие показатели из-за неправильной настройки счётчика невозможно исправить объёмом сессий — сигнал всё равно не будет фиксироваться.
- Ловить устаревшее событие изменения адреса. Современные приложения меняют адрес программно, и старый механизм на это не реагирует.
- Забывать про предыдущий адрес. Без него просмотры фиксируются, но маршрут пользователя в отчётах не собирается.
- Допускать двойные вызовы. Несколько просмотров одной страницы подряд с интервалом в доли секунды выглядят неестественно и портят картину не меньше, чем пропуски.
- Переходить по прямым адресам в сценарии. Это перезагружает приложение и превращает внутренний переход в отдельный вход, разрывая визит.
Частые вопросы
Влияет ли неправильное измерение на позиции само по себе? Напрямую утверждать это нельзя, и точных механизмов снаружи никто не знает. Но практический смысл прост: сигнал, который не зафиксирован, не может быть учтён. Если ваша аудитория ведёт себя хорошо, а система этого не видит, вы теряете преимущество, которое уже заработали.
Как быстро показатели придут в норму после правок? Сами отчёты начинают выглядеть корректно немедленно, с первых же визитов. Накопление достаточной статистики для сравнения периодов занимает больше времени, а изменения в выдаче, если они будут, проявляются с обычной задержкой. Ждать мгновенного эффекта на позициях не стоит.
Стоит ли переделывать сайт с одностраничной архитектуры? Обычно нет. Проблема решается настройкой измерения, а переписывание приложения — несопоставимо дороже и рискованнее. Переделка оправдана, только если есть другие серьёзные причины, например тяжёлые проблемы с индексированием.
Что делать, если доступа к коду приложения нет? Частично помогает подключение через диспетчер тегов с отслеживанием подмены методов работы с историей браузера. Это менее аккуратное решение, чем правка в маршрутизаторе, и требует внимательной проверки на дубли, но в ситуации без доступа к исходникам вполне рабочее.
Вывод
Одностраничная архитектура ломает не поведение пользователей, а его измерение. Переход между разделами происходит без перезагрузки документа, событие загрузки не наступает, и счётчик, настроенный по умолчанию, фиксирует ровно один просмотр за весь визит. Отсюда вечная единица в глубине, почти нулевое время и высокая доля отказов на сайте, где люди на самом деле всё смотрят. Для работы с поведенческими факторами это означает, что значительная часть сигнала теряется по дороге: сессии отрабатывают маршрут, а в статистику попадает поверхностный визит. Диагностика при этом простая — если показатели одинаково плохи по всем источникам сразу, дело в измерении, а не в трафике. Починка сводится к нескольким предсказуемым шагам: отправлять просмотр при смене маршрута, передавать предыдущий адрес, синхронизировать заголовок документа, перевести цели на события, убрать дубли и научить сценарий кликать по элементам навигации вместо прямых переходов по адресам. Пока это не сделано, любые вложения в объём трафика будут финансировать сбор данных, которые никуда не попадают.
Больше о поведенческом продвижении и других услугах — на главной странице ProfSEO24.
Закажите накрутку ПФ в ProfSEO24
Выводим сайты в ТОП-1 Яндекса за счёт поведенческих факторов на базе ИИ — без риска фильтров. Более 300 сайтов в ТОП-1, первые сдвиги по позициям за 3 дня. Рассчитаем стоимость под вашу нишу и регион.
Заказать накрутку ПФ Написать в TelegramКомментарии
Егор Вишневский
Год платили за поведение, чтобы «исправить отказы». Оказалось, счётчик просто не видел переходов. Читаю и тихо злюсь на себя.
Admin
История типовая, и защититься от неё можно одной проверкой. Прежде чем трактовать плохие показатели как поведенческую проблему, разложите их по источникам. Если отказы одинаково высоки и в поиске, и в прямых заходах, и в рекламе — это техника. Живая рекламная аудитория, за которую вы платите за клик, не может вести себя так же плохо, как весь остальной трафик.
spa_dev
Подключение к маршрутизатору, а не к событию изменения хеша — важное уточнение. Половина инструкций в сети до сих пор описывает устаревший способ.
Татьяна Лукьянова
Про заголовок документа вообще не думала. У нас все разделы в отчёте назывались одинаково, и я считала это особенностью счётчика.
Кирилл Горбунов
А дубли реально опаснее пропусков? Мне казалось, лишний просмотр — это скорее плюс для глубины.
Admin
Кирилл, не опаснее, но и не безобиднее. Дубли дают не просто завышенную глубину, а характерную картину: два-три просмотра одного и того же адреса подряд с интервалом в доли секунды. Живой человек так не умеет, он физически не успевает. То есть вы получаете и неверную цифру, и неестественный рисунок поведения одновременно. Проверяется элементарно: пройдите по разделу в отчёте реального времени и посчитайте события.
react_router
Двойной вызов при первом запуске — классика. Один просмотр отправляет сам счётчик при загрузке, второй прилетает от подписки на маршрут.
Нина Астахова
Сценарий должен кликать по элементам меню, а не открывать адрес напрямую — это же меняет всю постановку задачи подрядчику.
Валерий Подгорный
Доступа к исходникам нет, сайт делала сторонняя студия и пропала. Через диспетчер тегов это лечится нормально или костыль?
Admin
Валерий, это рабочее решение, хотя и менее аккуратное. Суть в том, чтобы перехватить методы работы с историей браузера и на каждое изменение адреса отправлять просмотр с передачей предыдущего адреса. Обязательно проверьте две вещи: не задваиваются ли события на первом заходе и корректно ли отрабатывает кнопка «назад», потому что она идёт через отдельное событие. С заголовком документа будет сложнее — если приложение его не меняет, снаружи вы сможете подставить только то, что есть в адресе.
front_ninja
Отдельная боль — позиция прокрутки не сбрасывается при смене раздела. Человек кликает в меню и оказывается в середине нового текста.
Алевтина Крюкова
Проверка по источникам как способ отличить технику от трафика — простая и сильная идея. Записала в регламент первым пунктом.
Денис Жуков
Цели, привязанные к адресу страницы, у нас не срабатывали вообще. Перевели на события — заявки наконец стали видны в отчётах.
Admin
Денис, так и надо. И сразу совет на будущее: не привязывайте цель к клику по кнопке отправки, привязывайте к успешному ответу сервера. Иначе цель будет засчитываться даже тогда, когда форма упала с ошибкой валидации или сервер не принял данные. На одностраничных приложениях это встречается постоянно, потому что отправка идёт фоновым запросом и визуально ничего не меняется.
vue_master
Вопрос про запись сессий: у нас она обрывается на первом же переходе. Это тоже лечится настройкой или так и будет?
Admin
Чаще всего лечится тем же самым. Запись привязана к просмотру, и если просмотр один, вся дальнейшая активность либо не попадает в неё, либо склеивается в кашу. После того как вы начнёте корректно отправлять просмотры при смене маршрута, записи обычно становятся читаемыми. Отдельно проверьте, не подменяется ли содержимое так, что инструмент теряет узлы разметки, — на тяжёлых интерфейсах с виртуализацией списков это встречается, и там уже помогает только упрощение разметки.
Софья Бирюкова
«Сигнал, который не зафиксирован, не может быть учтён» — вроде очевидно, а годами работают вслепую и удивляются.
Антон Пересветов
Приятно, что не советуют переписывать сайт. Обычно в таких статьях финал один: «ваша архитектура плохая, делайте заново».
hydrate_fail
В ProfSEO24 начали разбор моего проекта именно с проверки счётчика, а не с предложения услуг. Половина проблем закрылась правкой в коде, и мне честно сказали, что часть бюджета тут не нужна. Такое запоминается.