Меня зовут Максим, я веб-разработчик. Каждый второй клиент, который приходит ко мне с задачей «переделать сайт», не может ответить на простой вопрос: сколько реальных посетителей у вашего сайта в месяц? Цифры из Яндекс Метрики звучат уверенно, но когда мы сравниваем их с серверными логами — оказывается, что Метрика «видит» только 65–80% реального трафика. Остальное — потеряно из-за блокировщиков рекламы, браузерных ограничений и осторожных пользователей, которые отклоняют cookie-баннер. В 2026 году полагаться только на классическую cookie-аналитику — значит управлять бизнесом с закрытым глазом. Расскажу, какие альтернативы существуют и как я их применяю.
Почему cookie-аналитика теряет данные
Разберём по порядку все причины, из-за которых классическая аналитика врёт.
Блокировщики рекламы. AdBlock, uBlock Origin, встроенные фильтры Яндекс Браузера и Opera. Они блокируют не только рекламу, но и скрипты аналитики — Яндекс Метрику, Google Analytics, пиксели соцсетей. По моим замерам на российских сайтах, от 18% до 35% десктопного трафика блокирует аналитические скрипты.
Браузерные ограничения. Safari удаляет сторонние cookie через 7 дней, а при определённых условиях — через 24 часа. Firefox блокирует межсайтовое отслеживание по умолчанию. Chrome обещал убрать third-party cookies, потом откатил решение, но продолжает ужесточать ограничения.
Для бизнеса это значит: посетитель пришёл на сайт по рекламе в понедельник, вернулся и купил в следующую среду — а в аналитике это два разных человека. Рекламный канал не получает конверсию, атрибуция врёт, бюджет перераспределяется неправильно.
Cookie-баннеры. После ужесточения 152-ФЗ и роста осведомлённости пользователей всё больше людей отклоняют cookie. Если посетитель нажал «Отклонить» — аналитика не работает (если вы реализовали баннер правильно). По моим данным, от 8% до 15% посетителей отклоняют cookie.
Мобильные приложения и WebView. Переходы из Telegram, ВКонтакте, email-приложений часто открывают страницу во встроенном браузере, который может ограничивать cookie и JavaScript.
Суммарно: в среднем вы теряете 20–40% данных. Для сайта с 50 000 визитов это 10 000–20 000 «невидимых» посетителей в месяц.
Методы аналитики без cookie
Серверная аналитика (server-side tracking)
Подробно об этом я писал в отдельной статье, но коротко: данные собираются на вашем сервере, а не в браузере. Запросы идут на ваш домен (не блокируются), идентификация — через серверные cookie первого уровня (first-party) или серверные сессии.
Серверная аналитика не решает проблему на 100% (если посетитель отклонил все cookie, вы всё равно не можете его идентифицировать между сессиями), но решает на 80–90%: блокировщики не влияют, браузерные ограничения — минимальны.
Fingerprinting (отпечаток браузера)
Идентификация посетителя по совокупности технических параметров: разрешение экрана, установленные шрифты, часовой пояс, версия браузера, язык системы, характеристики видеокарты (через Canvas API). Комбинация этих параметров уникальна для 90–95% устройств.
Звучит привлекательно, но есть серьёзные ограничения:
- Юридически спорно. В контексте 152-ФЗ fingerprinting может считаться сбором персональных данных без согласия. Роскомнадзор пока не дал чёткой позиции, но тренд — в сторону ограничений.
- Этически сомнительно. Пользователь отказался от cookie, а вы его всё равно отслеживаете? Это не то, что укрепляет доверие к бренду.
- Технически нестабильно. Браузеры активно борются с fingerprinting: Safari рандомизирует Canvas API, Firefox добавляет шум к параметрам.
Мой подход: я не использую fingerprinting для идентификации конкретных пользователей, но применяю его элементы для статистической агрегации — определение типа устройства, оценка размера аудитории, дедупликация.
Когортная аналитика
Вместо отслеживания каждого посетителя индивидуально — работа с группами (когортами). Например: «все посетители, пришедшие из контекстной рекламы в марте» — одна когорта. Вы не знаете, кто конкретно из них купил, но знаете, что из 5 000 посетителей когорты 150 совершили покупку. Конверсия когорты — 3%.
Это менее точно, чем индивидуальное отслеживание, но полностью совместимо с любыми ограничениями на cookie. Google продвигает похожий подход (Topics API, Attribution Reporting API), Яндекс тоже движется в этом направлении.
Серверные логи
Самый «примитивный» и одновременно самый надёжный источник данных. Каждый HTTP-запрос к серверу записывается в лог: IP-адрес, URL, реферер, User-Agent, время. Никакие блокировщики не могут заблокировать серверный лог — потому что без HTTP-запроса страница просто не загрузится.
Ограничения: в логах нет данных о поведении на странице (клики, скроллинг, заполнение форм). И IP-адрес — ненадёжный идентификатор (за одним IP может быть офис из 100 человек).
Но для базовых метрик — количество визитов, популярные страницы, источники трафика, географическая структура — серверные логи работают отлично. Я использую GoAccess для быстрого анализа логов или загружаю их в ClickHouse для кастомных запросов.
Privacy-first аналитика
Существует класс аналитических инструментов, которые изначально построены без cookie:
Plausible. Лёгкий open-source инструмент, скрипт весит менее 1 КБ, не использует cookie, не собирает персональные данные. Показывает: визиты, страницы, источники, устройства, страны. Для базовых нужд — вполне достаточно.
Umami. Аналог Plausible, тоже open-source, можно развернуть на своём сервере. Бесплатный, данные хранятся у вас.
Fathom. Платный, но с хорошей репутацией и строгим подходом к приватности.
Общий принцип: эти инструменты не идентифицируют посетителей между сессиями. Они считают «уникальных посетителей» по хешу IP + User-Agent (без хранения самих данных), что достаточно для 80% аналитических задач.
Моя стратегия: комбинированный подход
На проектах я использую не один метод, а комбинацию — каждый закрывает свои слепые зоны.
Уровень 1: Серверные логи. Базовая правда: сколько запросов, какие страницы, откуда трафик. Не теряет ни одного посетителя.
Уровень 2: Серверная аналитика. Отслеживание конверсий и событий на стороне сервера. First-party cookie для идентификации между сессиями (только для тех, кто согласился).
Уровень 3: Яндекс Метрика. Для тех посетителей, у которых работает JS и нет блокировщиков — полный набор данных: карта кликов, Вебвизор, глубокая поведенческая аналитика.
Уровень 4: CRM-данные. Финальная точка истины: сколько заявок реально пришло, сколько из них конвертировались в клиентов, какой LTV. Этих данных блокировщики не съедят никогда.
Ключевая идея: серверные логи и CRM — это «земля», объективная реальность. Яндекс Метрика — это «карта», полезная, но неполная. Хорошая аналитика сверяет карту с землёй.
Как посчитать реальное расхождение
Простой способ оценить, сколько данных вы теряете:
- Возьмите количество уникальных IP-адресов из серверных логов за месяц
- Возьмите количество «новых посетителей» из Яндекс Метрики за тот же период
- Разница — примерный процент потерь
Для более точной оценки: сравните количество оформленных заказов в CRM с количеством достижений цели «Заказ оформлен» в Метрике. Расхождение покажет, какой процент конверсий аналитика не фиксирует.
На моих проектах типичное расхождение:
- Информационные сайты: 15–25%
- Интернет-магазины: 20–35%
- B2B-сайты (аудитория с высокой долей IT-специалистов): 30–45%
Стоимость внедрения
Базовый аудит аналитики + оценка потерь: 20–50 тысяч рублей, разовая работа.
Внедрение серверной аналитики: 80–300 тысяч рублей (зависит от сложности сайта и интеграций).
Развёртывание privacy-first аналитики (Plausible/Umami): 15–40 тысяч рублей (настройка + хостинг).
Комбинированная система (серверная + Метрика + CRM-сверка): 200–500 тысяч рублей.
Инфраструктура: 3–15 тысяч рублей в месяц.
Что делать прямо сейчас
- Сравните данные Метрики с серверными логами — оцените масштаб потерь
- Сравните конверсии в Метрике с данными CRM — проверьте расхождение
- Если потери больше 20% — рассмотрите серверную аналитику
- Подключите Microsoft Clarity или Plausible как дополнительный источник данных
- При принятии бизнес-решений — опирайтесь на CRM-данные, а не только на аналитику
Если нужна помощь с настройкой аналитики, устойчивой к блокировщикам — обращайтесь.