Тестовая страница для проверки доскролла в Яндекс.Метрике

Введение

Эта страница нужна для чистого теста. Здесь нет стороннего лэйаута новостника, нет сложного sticky-интерфейса, нет баннерной сетки, которая поздно перестраивает документ. Поэтому по ней удобно сравнивать три вещи: фактический скролл браузера, debug-скриншоты по шагам и то, как Яндекс.Метрика отражает глубину просмотра.

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

В реальных проектах особенно мешает сочетание нескольких факторов сразу. Один сайт сначала дорисовывает шапку и hero-блок, потом подтягивает рекламу, потом только формирует итоговую высоту основного документа. Автоматический браузер может успеть начать движение раньше, чем страница зафиксирует стабильную структуру. Визуально это выглядит как почти незаметный сдвиг, хотя `scrollBy` уже был вызван. Именно для таких сравнений и полезна отдельная тестовая площадка, где фоновые перестройки сведены к минимуму.

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

Первый длинный блок

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

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

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

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

Средняя часть

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

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

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

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

Визуальные карточки

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

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

Дополнительный длинный участок

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

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

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

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

Почти конец страницы

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

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

Вблизи конца страницы особенно заметны два класса проблем. Первый — сценарий просто не живёт достаточно долго, чтобы физически добраться до этой зоны. Второй — он добирается, но делает это слишком рвано или в слишком нестабильной фазе загрузки, из-за чего аналитика видит только часть движения. Именно поэтому полезно сопоставлять эту секцию с debug-скриншотами, временем жизни сессии и фактическими логами scroll-метрик.

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