Почему данные в web-аналитике никогда не бывают идеально точными
Введение
Одна из типичных ошибок начинающих маркетологов, владельцев бизнеса и даже некоторых аналитиков — ожидать от web-аналитики абсолютной точности.
Они открывают Google Analytics 4, Яндекс Метрику, рекламный кабинет, CRM и видят разные цифры.
В GA4 — 1 240 пользователей.
В Яндекс Метрике — 1 390 посетителей.
В рекламном кабинете — 1 520 кликов.
В CRM — 73 заявки.
В отчете менеджера — 68 обращений.
И возникает вопрос: где правда?
Правильный ответ: правда не в одной конкретной цифре. Правда — в понимании того, как эти цифры были собраны, обработаны и интерпретированы.
Web-аналитика не является бухгалтерией. Она не фиксирует реальность с абсолютной точностью до каждого человека, клика и действия. Она работает с цифровыми следами пользователей: браузерами, cookies, устройствами, событиями, источниками трафика, URL-параметрами и настройками счетчиков.
Именно поэтому данные в web-аналитике всегда нужно воспринимать как достаточно точную модель поведения пользователей, но не как идеальную копию реальности.
Web-аналитика измеряет не человека, а его цифровой след
Главный принцип, который нужно понять: система web-аналитики в большинстве случаев видит не реального человека, а браузер, устройство и набор технических идентификаторов.
Когда пользователь заходит на сайт, в браузере может быть создан cookie-файл с уникальным идентификатором. Например, в Google Analytics используется логика Client ID. Благодаря этому система пытается понять, новый это пользователь или вернувшийся.
Но этот идентификатор не равен человеку.
Один и тот же человек может:
зайти с телефона;
потом открыть сайт с ноутбука;
зайти через другой браузер;
очистить cookies;
использовать режим инкогнито;
перейти по ссылке из приложения;
отказаться от cookies;
использовать блокировщик рекламы.
Во всех этих случаях аналитическая система может распознать его по-разному. Иногда как одного пользователя, иногда как нескольких разных пользователей.
Поэтому показатель “пользователи” в web-аналитике — это не перепись населения. Это техническая оценка количества уникальных браузеров, устройств или идентификаторов в рамках логики конкретной системы.
Данные начинают собираться не с момента визита, а с момента выполнения кода
Посещение сайта само по себе еще не гарантирует, что оно попадет в аналитику.
Чтобы данные были собраны, должен выполниться код счетчика: Google Analytics, Яндекс Метрики, Google Tag Manager или другого аналитического инструмента.
Цепочка выглядит так:
Пользователь открыл сайт.
Браузер начал загружать страницу.
Загрузились HTML, CSS, JavaScript, изображения, шрифты и другие ресурсы.
Загрузился код счетчика.
Код счетчика выполнился.
Данные отправились (и не потерялись, привет от РКН) на сервер аналитической системы.
Система обработала данные и показала их в отчете.
Если на любом этапе произошла проблема, данные могут не попасть в отчет.
Например:
пользователь закрыл страницу слишком быстро;
код счетчика не успел загрузиться;
на сайте была JavaScript-ошибка;
счетчик был установлен не на всех страницах;
браузер заблокировал запрос;
пользователь не дал согласие на cookies;
код был случайно удален после обновления шаблона сайта;
GTM-контейнер не был опубликован;
тег сработал не на той странице;
триггер был настроен неправильно.
Поэтому первая причина неточности данных — техническая. Аналитика видит только то, что смогла корректно зафиксировать.
Быстрые отказы могут не попасть в систему
Допустим, пользователь кликнул по рекламе, сайт начал грузиться, но страница открывалась слишком долго. Через две секунды пользователь закрыл вкладку.
В рекламном кабинете клик будет засчитан.
А в системе web-аналитики визит может не появиться, если счетчик не успел загрузиться и отправить данные.
Из-за этого количество кликов в рекламной системе почти никогда не равно количеству сеансов в аналитике.
Это не обязательно ошибка. Это следствие разной природы измерения.
Рекламная система фиксирует клик по объявлению.
Web-аналитика фиксирует загруженную страницу и выполненный код счетчика.
CRM фиксирует заявку или сделку.
Это разные события на разных этапах пути пользователя.
Блокировщики рекламы и приватные браузеры искажают картину
Часть пользователей использует AdBlock, uBlock Origin, Brave, Firefox с усиленной защитой приватности, Safari с ограничениями трекинга и другие инструменты, которые могут блокировать аналитические скрипты, рекламные пиксели или cookies.
Для пользователя сайт может работать нормально. Но часть запросов к аналитическим системам может не отправиться.
В результате web-аналитика может недосчитать:
пользователей;
сеансы;
источники трафика;
события;
конверсии;
аудитории ремаркетинга.
Особенно это заметно в тематиках, где аудитория технически продвинутая: IT, digital, маркетинг, разработка, финансы, криптовалюты, B2B SaaS. Такие пользователи чаще используют приватные браузеры и блокировщики.
Поэтому аналитик должен понимать: отсутствие данных в отчете не всегда означает отсутствие реального действия пользователя.
Cookies можно удалить, заблокировать или не принять
Cookies — один из ключевых механизмов идентификации пользователей в web-аналитике. Но cookies не являются вечными и гарантированными.
Пользователь может:
очистить cookies вручную;
запретить cookies в браузере;
использовать режим инкогнито;
не дать согласие на cookies в баннере согласия;
зайти с другого устройства;
зайти из приложения, где cookies работают иначе;
вернуться через длительное время, когда идентификатор уже недоступен.
В режиме инкогнито cookies обычно создаются только на текущую сессию и удаляются после закрытия окна. Если человек зайдет на сайт снова в новом окне инкогнито, аналитика может увидеть его как нового пользователя.
Из-за этого данные по новым и вернувшимся пользователям всегда имеют ограничение. Это полезная метрика, но не абсолютная истина.
Один человек может быть несколькими пользователями
Представим простой пример.
Человек увидел рекламу курса веб-аналитики в Instagram на телефоне. Перешел на сайт, посмотрел страницу, закрыл.
Вечером он открыл ноутбук, набрал название курса в Google и снова зашел на сайт.
На следующий день он перешел по ссылке из Telegram и оставил заявку.
Для реального бизнеса это один человек.
Но для аналитики это может выглядеть как:
пользователь №1 из Instagram на мобильном устройстве;
пользователь №2 из Google Organic на ноутбуке;
пользователь №3 из Telegram, если идентификаторы не связались.
Если не настроен User ID, сквозная аналитика, корректная атрибуция и единая CRM-связка, система может не собрать этот путь в единую историю.
Поэтому аналитик должен быть осторожен с выводами вроде “Instagram не работает”, “SEO привело заявку”, “Telegram закрыл продажу”. Возможно, каждый канал сыграл свою роль.
Разные системы считают одну и ту же реальность по-разному
Google Analytics 4 и Яндекс Метрика могут показывать разные данные не потому, что одна система “правильная”, а другая “неправильная”. Они используют разные модели данных, определения и алгоритмы.
Например, GA4 делает акцент на событиях, вовлеченности и engaged sessions. Показатель отказов в GA4 связан с обратной логикой вовлеченных сеансов: сессия не считается вовлеченной, если не длилась достаточно долго, не содержала key event и не включала достаточного количества просмотров страниц или экранов.
В Яндекс Метрике исторически ближе логика визитов, длительности визита и поведенческих метрик. Отказ в Метрике обычно трактуется иначе: например, как визит с просмотром одной страницы и короткой длительностью.
Поэтому один и тот же визит может быть отказом в одной системе и не быть отказом в другой.
То же самое касается:
пользователей;
сеансов / визитов;
времени на сайте;
источников трафика;
отказов;
конверсий;
атрибуции;
повторных посещений;
ботофильтрации;
данных в реальном времени.
Сравнивать GA4 и Яндекс Метрику “цифра в цифру” бессмысленно. Гораздо важнее понимать логику каждой системы и использовать их совместно для более полной картины.
Рекламный кабинет, аналитика и CRM измеряют разные этапы
Еще одна частая ситуация: рекламный кабинет показывает одно количество конверсий, GA4 — другое, Яндекс Метрика — третье, CRM — четвертое.
Это нормально, если системы настроены по-разному.
Рекламный кабинет может считать конверсию по клику или просмотру рекламы в своем окне атрибуции.
GA4 может учитывать key event на сайте и распределять ценность по своей модели атрибуции.
Яндекс Метрика может фиксировать достижение цели в рамках визита.
CRM может учитывать только реальные заявки, которые дошли до базы и не были тестовыми.
Менеджер продаж может считать только квалифицированные лиды.
Бухгалтерия может считать только оплаченные заказы.
Все эти цифры могут быть разными, потому что они отвечают на разные вопросы.
Рекламный кабинет отвечает: “Сколько действий система связала с рекламой?”
Web-аналитика отвечает: “Что пользователи делали на сайте?”
CRM отвечает: “Сколько обращений попало в процесс продаж?”
Бизнес отвечает: “Сколько денег мы заработали?”
Недопонимание начинается тогда, когда эти уровни смешивают и сравнивают напрямую.
Клик по кнопке — это не заявка
Очень распространенная ошибка настройки: считать конверсией клик по кнопке “Отправить”.
Но клик по кнопке не всегда означает успешную отправку формы.
Пользователь мог:
не заполнить обязательное поле;
ввести неправильный телефон;
получить ошибку валидации;
нажать кнопку несколько раз;
столкнуться с технической ошибкой;
закрыть страницу до отправки;
попасть в антиспам;
отправить тестовую заявку.
Если аналитика настроена на клик по кнопке, система может показать 100 “конверсий”, а в CRM будет только 63 реальные заявки.
Поэтому правильнее отслеживать не просто клик, а успешное событие: форма прошла валидацию, заявка создана, данные ушли в CRM, пользователь увидел сообщение об успешной отправке.
Для бизнеса важен не сам клик и невалидная конверсия. Важен факт обращения, продажи или другого результата.
Дублирование счетчиков завышает данные
Иногда счетчик установлен дважды: напрямую в код сайта и через Google Tag Manager. Или один и тот же тег срабатывает несколько раз из-за неправильного триггера.
В результате данные могут задваиваться.
Например:
один просмотр страницы превращается в два page_view;
одна покупка отправляется дважды;
один клик фиксируется несколькими событиями;
одна заявка попадает в отчет как две конверсии.
Особенно опасно дублирование e-commerce-событий. Если событие purchase отправляется повторно при обновлении страницы “Спасибо за заказ”, выручка в аналитике может быть завышена.
Поэтому после настройки аналитики важно проверять не только “есть ли данные”, но и “не слишком ли много данных”.
Установленный неправильно счетчик занижает данные
Обратная ситуация — счетчик стоит не на всех страницах.
Например:
на главной странице счетчик есть;
на посадочной странице старого шаблона — нет;
на странице оплаты — нет;
в личном кабинете — нет;
на поддомене — другой счетчик;
в мобильной версии — старая версия кода;
на странице благодарности — код удален после обновления.
В этом случае пользовательский путь разрывается. Аналитика может видеть начало визита, но не видеть конверсию. Или видеть конверсию, но не понимать, откуда пришел пользователь.
Поэтому при аудите web-аналитики нужно проверять не только главную страницу, а все важные типы страниц: лендинги, формы, корзину, оплату, страницу благодарности, поддомены, языковые версии, мобильные шаблоны.
Cross-domain tracking: когда пользователь “теряется” между доменами
Многие современные сайты используют несколько доменов или поддоменов.
Например:
основной сайт;
блог;
LMS-платформа;
форма регистрации;
платежная система;
личный кабинет;
отдельный лендинг;
домен партнера.
Если переходы между доменами настроены неправильно, система аналитики может разорвать путь пользователя.
Человек пришел из рекламы на основной сайт, перешел на платформу оплаты и вернулся на страницу благодарности. Но аналитика может решить, что это новый пользователь, новая сессия и новый источник трафика.
В отчетах появляются странные referral-источники: платежные системы, собственные поддомены, сервисы форм, LMS и другие технические домены.
Итог: реклама недополучает ценность, а технический домен начинает выглядеть как источник продаж.
Для таких случаев нужна корректная настройка cross-domain measurement и проверка, что идентификаторы пользователя не теряются при переходах между доменами.
UTM-хаос ломает источники трафика
Даже если счетчики установлены правильно, данные могут быть испорчены неправильной разметкой ссылок.
Например, один и тот же источник может быть записан так:
facebook;
Facebook;
fb;
meta;
Meta Ads;
facebook_ads;
instagram;
ig.
Для человека это примерно одно и то же. Для системы аналитики — разные значения.
В результате трафик размазывается по отчетам. Аналитик видит десятки вариантов одного источника и не может быстро понять, какой канал действительно работает.
То же самое происходит с utm_medium:
cpc;
paid;
paid_social;
target;
social_paid;
ads.
Без единой библиотеки UTM-меток отчетность быстро превращается в хаос.
Принцип простой: если данные на входе хаотичные, то и выводы на выходе будут нерелевантными. Важный принцип Дата аналитиков: Garbage In — Garbage Out.
Боты и внутренний трафик портят статистику
Не все посещения сайта — это реальные потенциальные клиенты.
На сайт могут заходить:
сотрудники компании;
разработчики;
подрядчики;
SEO-специалисты;
парсеры;
боты поисковых систем;
спам-боты;
сервисы мониторинга;
конкуренты;
случайные пользователи;
автоматические скрипты.
Если внутренний и технический трафик не фильтровать, он может искажать данные.
Особенно это заметно на сайтах с небольшим трафиком. Если на сайт в день заходит 80 реальных пользователей, а команда проекта за день сделала 40 тестовых визитов, поведенческие метрики и конверсии могут сильно исказиться.
Разработчики тестируют формы, маркетолог проверяет рекламу, владелец бизнеса открывает сайт 20 раз в день, подрядчик проверяет посадочные страницы — и все это попадает в аналитику.
Поэтому для повышения качества данных нужно фильтровать внутренний трафик, тестовые действия и технические события.
Малые объемы данных создают статистический шум
Даже при идеально настроенной аналитике данные могут быть неустойчивыми, если их мало.
Например, у вас две рекламные кампании.
Кампания А получила 20 кликов и 2 заявки.
Кампания Б получила 20 кликов и 0 заявок.
Можно ли сделать вывод, что кампания А лучше? Пока нет.
На малом объеме данных один случайный пользователь может сильно изменить картину. Сегодня один человек оставил заявку — конверсия 10%. Завтра никто не оставил — конверсия 0%. Послезавтра пришли два хороших лида — снова “рост”.
Такие колебания не всегда говорят о реальных изменениях качества рекламы или сайта. Часто это просто статистический шум.
Поэтому в web-аналитике важно смотреть не только на цифру, но и на объем данных, период анализа, стабильность динамики и контекст.
Разные периоды дают разные выводы
Сайт может вести себя по-разному в разные дни недели, часы суток и сезоны.
Например:
в B2B больше заявок в рабочие дни;
в e-commerce активность может расти вечером;
в образовании спрос может усиливаться перед стартом набора;
в туризме есть сезонность;
в услугах могут быть всплески после рекламы, вебинара или рассылки;
в дорогих продуктах клиент может принимать решение несколько недель.
Если оценивать эффективность только за один день, можно сделать ложный вывод.
Например, реклама может выглядеть плохой в понедельник утром и хорошей в четверг вечером. Но это не значит, что в понедельник нужно все отключить. Возможно, нужно учитывать цикл принятия решения и недельную динамику.
Поэтому данные становятся полезнее, когда мы анализируем их в правильном временном контексте.
Данные могут расходиться из-за атрибуции
Атрибуция — это логика распределения ценности конверсии между каналами.
Пользователь редко покупает или оставляет заявку с первого касания. Он может:
увидеть рекламу;
потом найти бренд в поиске;
зайти на сайт из органики;
посмотреть отзывы;
вернуться из email-рассылки;
перейти из мессенджера;
увидеть ремаркетинг;
только потом оставить заявку.
Какому каналу отдать конверсию?
Последнему?
Первому?
Всем равномерно?
Тому, который статистически сильнее повлиял на путь?
Разные системы могут использовать разные модели и окна атрибуции. Поэтому рекламный кабинет может приписать конверсию себе, GA4 — распределить иначе, а CRM вообще видеть только финальный источник из формы.
Это не ошибка. Это разные способы ответить на вопрос: “какой канал повлиял на результат?”
Время обработки данных тоже влияет на расхождения
Не все отчеты обновляются мгновенно.
В режиме реального времени можно увидеть часть событий быстро. Но стандартные отчеты могут обновляться с задержкой. Отдельные данные могут появляться через несколько часов или на следующий день.
Кроме того, системы могут:
дополнительно обрабатывать данные;
применять фильтры;
моделировать часть данных;
обновлять атрибуцию;
дедуплицировать события;
исключать ботов;
применять privacy thresholding;
пересчитывать отдельные показатели.
Поэтому не стоит делать окончательные выводы сразу после запуска кампании или настройки события. Сначала нужно проверить техническую передачу данных, а затем дать системе время на обработку.
Идеальная точность не нужна для большинства бизнес-решений
Важная мысль: в web-аналитике не всегда нужна абсолютная точность.
Для большинства маркетинговых и продуктовых решений важнее не точность до единицы, а надежное понимание направления.
Например:
какой канал приводит более качественный трафик;
какая посадочная страница конвертирует лучше;
где пользователи теряются в воронке;
какие формы не отправляются;
какие рекламные кампании явно не окупаются;
какие товары чаще добавляют в корзину, но не покупают;
какие страницы дают высокий интерес, но слабую конверсию;
какие сегменты аудитории приносят больше заявок.
Если данные достаточно качественные, чтобы принять правильное решение, они уже полезны.
Задача аналитика — не добиться мистической точности 100%. Задача — построить систему данных, которой можно доверять на уровне управленческих решений.
Что такое “достаточно точные данные”
Достаточно точные данные — это данные, которые:
собираются стабильно;
не имеют очевидных дублей;
не теряют ключевые конверсии;
корректно определяют основные источники трафика;
совпадают с CRM в допустимом диапазоне;
отражают реальные тренды;
позволяют сравнивать периоды;
помогают находить проблемы и точки роста;
не противоречат бизнес-логике.
Например, если GA4 показывает 102 заявки, Яндекс Метрика — 108, а CRM — 96, это может быть нормальным расхождением, если известно, что часть заявок тестовые, часть не дошла до CRM, а системы по-разному считают события.
Но если GA4 показывает 300 заявок, Метрика — 40, а CRM — 12, это уже повод для аудита. Скорее всего, событие настроено неправильно, дублируется или срабатывает не на реальную отправку формы.
Как повысить качество данных в web-аналитике
Абсолютной точности не будет, но качество данных можно значительно улучшить.
Первое — проверить установку счетчиков. Они должны быть на всех нужных страницах и не должны дублироваться.
Второе — использовать Google Tag Manager или другую управляемую систему тегов, чтобы централизованно контролировать срабатывание кодов.
Третье — описать карту событий (структура отслеживания, event's tracking plan): какие действия считаются микроконверсиями, какие — макроконверсиями, какие события нужны для рекламы, какие — для анализа UX.
Четвертое — отслеживать не просто клики, а реальные успешные действия: отправку формы, создание заявки, покупку, оплату, подтверждение заказа.
Пятое — унифицировать UTM-разметку (см. нейминг и консистентность именования) и создать библиотеку UTM-меток.
Шестое — фильтровать внутренний, тестовый и технический трафик.
Седьмое — настроить cross-domain tracking, если пользователь переходит между доменами, поддоменами, платежными системами или LMS.
Восьмое — регулярно сверять аналитику с CRM, CMS, рекламными кабинетами и фактическими бизнес-данными.
Девятое — документировать настройки (те самые артефакты): какие теги стоят, какие события отправляются, какие цели считаются ключевыми, какие фильтры применяются.
Десятое — после каждого релиза сайта проверять, не сломалась ли аналитика.
Как правильно относиться к расхождениям
Расхождения в данных — это не всегда проблема. Часто это нормальная часть работы аналитика.
Проблема не в том, что цифры отличаются. Проблема в том, что команда не понимает, почему они отличаются.
Умный и понимающий аналитик не говорит: “GA4 врет” или “Метрика неправильная”. Он задает вопросы:
что именно сравниваем;
за какой период;
в какой часовой зоне;
какие фильтры применены;
одинаково ли настроены события;
что считается конверсией;
какое окно атрибуции используется;
нет ли дублей;
не потерялись ли данные на поддоменах;
сравниваем ли мы клики, сеансы, визиты, пользователей, заявки или продажи.
После этого расхождения перестают быть хаосом и становятся допустимой нормой при текущих условиях функционирования третьесторонних систем и сервисов совместно с бизнесом.
Пример: почему в рекламе 100 кликов, а в аналитике 72 сеанса
Представим, что в рекламном кабинете Яндекс Директа или Google Ads вы видите 100 кликов.
В GA4 при этом видно только 72 сеанса из этого источника.
Это может происходить по нескольким причинам:
часть пользователей закрыла страницу до загрузки счетчика;
часть переходов была заблокирована браузером или расширениями;
часть пользователей не приняла cookies;
часть кликов была случайной;
часть трафика пришла с задержкой или была обработана иначе;
UTM-метки были повреждены;
переходы попали в другой источник;
часть визитов была отфильтрована;
страница загружалась слишком медленно;
на части страниц счетчик не сработал.
Это не повод сразу обвинять рекламную систему или аналитику. Это повод проверить всю цепочку: от клика по объявлению до загрузки страницы, срабатывания счетчика и фиксации события. Однако! Проблематично эмулировать проверку-эксперимент за того парня (пользователя, который кликнул на рекламное объявление, но так и не загрузился в систему аналитики), потому, что мы не знаем кто это и откуда и какой у него был весь путь пользователя. Мы можем только предполагать и протестировать наши предположения в той технической среде, которая нам доступна. То же самое относится и к гео-локалям - где очень влияют те самые санкции и блокировки.
Пример: почему заявок в аналитике больше, чем в CRM
Другой пример: аналитика показывает 120 заявок, а CRM — 84.
Возможные причины:
событие настроено на клик по кнопке, а не на успешную отправку;
пользователь нажимал кнопку несколько раз;
форма не прошла валидацию;
были тестовые заявки;
событие дублируется;
форма отправляется, но не все заявки доходят до CRM;
часть заявок отсекается антиспамом;
разные часовые зоны;
разный период сравнения;
в CRM считаются только квалифицированные лиды.
Вывод: нельзя оценивать качество настройки аналитики только по наличию события. Нужно понимать, какое именно действие фиксируется.
Главная роль web-аналитика
Web-аналитик нужен не для того, чтобы слепо верить отчетам. И не для того, чтобы спорить, в какой системе цифра “правильнее”.
Его задача — понимать происхождение данных.
Хороший web-аналитик умеет объяснить:
как данные собираются;
где они могут потеряться;
где могут задвоиться;
почему системы расходятся;
какие данные можно использовать для решений;
какие требуют осторожности;
какие настройки нужно исправить;
какую погрешность можно считать приемлемой.
Именно это отличает аналитика от человека, который просто открывает отчеты.
Итого:
Данные в web-аналитике никогда не бывают идеально точными, потому что между реальным действием человека и цифрой в отчете находится длинная техническая цепочка: браузер, cookies, JavaScript-код, счетчики, GTM, серверы аналитических систем, фильтры, модели атрибуции, настройки событий, CRM и бизнес-процессы.
На каждом этапе возможны потери, дубли, ограничения и расхождения.
Но это не делает web-аналитику бесполезной. Наоборот, понимание ограничений делает аналитику профессиональной.
Задача бизнеса — не найти “идеальную цифру”. Задача — построить такую систему сбора и анализа данных, которая помогает принимать более правильные решения: куда вкладывать рекламный бюджет, какие страницы улучшать, какие гипотезы тестировать, какие каналы масштабировать и где находятся реальные точки роста.
Хорошая web-аналитика — это не абсолютная точность.
Хорошая web-аналитика — это достаточная достоверность для принятия решений.
