Как исправить падение живого трафика на сайте

Как исправить резкое падение статистики живого трафика на сайте

Резкое падение статистики живого трафика в 10:00 выглядит драматично, а в 10:05 уже вызывает недоумение. Первая задача — не паниковать, а проверить данные. Если счётчик в реальном времени показывает «3», а панель аналитики — «31», это уже подсказка: проблема может быть в отчётности, а не в посетителях, и именно поэтому так важно понимать, как проверить падение статистики в аналитике.

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

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

1. Убедитесь, что падение реальное, а не сбой в отчёте

Посмотрите на счётчик в реальном времени, основную панель аналитики и любой дополнительный трекер в одну и ту же минуту. Если падение началось в 14:20, запишите это. Не «днём». Время начала важно, потому что неудачный деплой, обновление согласия или изменение правила CDN обычно имеют рядом временную метку.

Проверьте, проявляется ли проблема везде или только в одном месте. Виджет live-статистики в шапке может перестать обновляться, а серверные логи при этом продолжат показывать запросы. Это проблема отчётности, а не обвал трафика. Один быстрый перезапуск браузера может сэкономить час.

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

2. Сравните падение с обычным паттерном трафика

Трафик не бывает ровным, даже на сильных сайтах. Сравнивайте с тем же часом предыдущих недель, а не только с предыдущим днём, потому что на некоторых сайтах спад всегда бывает в 03:00 или пик — в 09:30. Вторник в полдень — не то же самое, что суббота в полдень. Это кажется очевидным. Но о таком всё равно забывают.

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

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

3. Проверьте изменения в трекинге, сделанные прямо перед падением

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

Не игнорируйте мелкие изменения. Новый cookie-баннер может откладывать трекинг до нажатия «Принять». Обновление плагина может перенести скрипт аналитики ниже скрипта, который сначала ломается. Контейнер GTM может опубликоваться корректно, но срабатывать по неправильному триггеру. Маленькая ошибка. Большая головная боль.

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

4. Проверьте, что код аналитики загружается на ключевых страницах

Сначала откройте главную страницу, затем 2–3 страницы с высоким трафиком. Проверьте десктопную и мобильную версии. Убедитесь, что скрипт аналитики срабатывает при загрузке страницы и делает это только один раз. Если главная работает, а страницы товаров — нет, проблема может быть ограничена одним шаблоном или типом страницы.

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

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

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

5. Исключите проблемы с доступностью или производительностью сайта

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

Проверьте скорость загрузки, пустые экраны и ответы 4xx или 5xx. Если правило CDN блокирует один из файлов скрипта, страница может загрузиться без аналитики. Если файрвол или bot-layer блокирует определённых пользователей, вы сами можете видеть сайт, но терять реальных посетителей. Это важнее заголовка с цифрой.

Здесь помогают серверные логи. Так же как проверки доступности и отчёты CDN об ошибках. Если главная страница у вас загружается за 2 секунды, а у пользователей из другого региона — за 12, падение live-трафика может отражать отказ от просмотра, а не сбой трекинга. Медленные сайты быстро теряют визиты. Очень быстро.

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

6. Проверьте, не потеряли ли источники трафика возможность приводить визиты

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

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

Проверьте, действительно ли ушла новая email-рассылка, SMS-рассылка или запланированный пост. Если трафик завязан на отправку сообщений, одна неудачная кампания может создать впечатление резкого падения. Командам, которые используют настройку email-, SMS- и push-рассылок, стоит подтвердить доставку, клики и путь до посадочной страницы, прежде чем искать баг на сайте.

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

7. Проверьте фильтрацию ботов и настройки приватности, которые скрывают визиты

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

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

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

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

8. Определите, что исправлять первым, и как подтвердить восстановление

Сначала исправляйте ту проблему, которая с наибольшей вероятностью влияет на подсчёт в реальном времени. Если тег изменили за 30 минут до падения, чините тег до правки правил CDN или ссылок кампании. Если в одном регионе сайт недоступен, сначала восстановите доступность, а уже потом меняйте настройки аналитики. Одна приоритетная задача за раз. Таково правило.

После исправления следите одновременно за следующим окном отчётности и панелью live-статистики. Не останавливайтесь на одном обновлённом экране. Наблюдайте 10–20 минут, если поток трафика достаточно стабильный, чтобы показать закономерность. Если live-счётчик растёт, а панель запаздывает, проблема может быть в задержке, а не в потере данных.

Проверяйте на 3 уровнях: реальный визит, событие трекинга и обновление панели. Если все 3 появились, у вас есть подтверждение восстановления. Если только 2 — продолжайте искать. Исправления, которое «кажется правильным», недостаточно.

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

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

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