Введение
Когда мы открываем отчет в Google Analytics 4 или Яндекс Метрике, нам кажется, что данные просто “появились” в системе: пользователи, визиты, просмотры страниц, источники трафика, конверсии, устройства, города, браузеры, события.
Но на самом деле за этим стоит достаточно понятная техническая цепочка.
Пользователь открывает сайт. Браузер загружает страницу. Вместе со страницей загружается небольшой JavaScript-код системы аналитики: Google Analytics, Яндекс Метрики, Google Tag Manager, рекламного пикселя или другого счетчика. Этот код считывает часть технических и поведенческих данных, формирует запрос и отправляет информацию на сервер аналитической системы. После обработки данные попадают в отчеты, где аналитик, маркетолог или владелец бизнеса уже может анализировать трафик, поведение пользователей и эффективность рекламы.
Именно поэтому web-аналитика — это не магия и не “таблички в красивом интерфейсе”. Это система сбора, передачи, обработки и интерпретации данных о действиях пользователей на сайте.
В этой статье разберем простыми словами, как работает web-аналитика: что делает браузер, зачем нужен JavaScript-код, почему счетчик называют пикселем, куда передаются данные и почему иногда аналитика видит не все.
Что такое счетчик web-аналитики
Счетчик web-аналитики — это небольшой программный код, который устанавливается на сайт и собирает данные о посещениях и действиях пользователей.
Чаще всего это JavaScript-код. Он может быть установлен напрямую в HTML-код сайта, через CMS, через плагин или через Google Tag Manager.
Примеры таких счетчиков:
Google Analytics 4;
Яндекс Метрика;
Google Tag Manager;
Meta Pixel;
TikTok Pixel;
LinkedIn Insight Tag;
другие рекламные и аналитические скрипты.
В бытовом языке маркетологи часто говорят: “поставить счетчик”, “установить пиксель”, “добавить код аналитики”, “поставить тег”. В разных системах используются разные термины, но общая логика похожа: на сайт добавляется небольшой фрагмент кода, который должен загрузиться в браузере пользователя и отправить данные в нужную систему.
Почему счетчик называют пикселем
Исторически термин “пиксель” возник из старой технологии отслеживания, когда на страницу помещалось невидимое изображение размером 1×1 пиксель. Когда браузер загружал это изображение, сервер фиксировал факт загрузки и мог понять, что страница была открыта.
Сейчас большинство современных систем web-аналитики работают гораздо сложнее. Они используют JavaScript, cookies, параметры URL, события, идентификаторы пользователей и интеграции с рекламными системами. Но термин “пиксель” остался.
Поэтому, когда говорят “поставить пиксель Facebook” или “установить пиксель аналитики”, чаще всего имеют в виду не картинку 1×1, а код отслеживания, который собирает данные о пользователях и событиях.
Что происходит, когда пользователь открывает сайт
Разберем цепочку максимально просто.
Пользователь вводит адрес сайта в браузере или переходит по ссылке из рекламы, поиска, мессенджера, email-рассылки или социальной сети.
Браузер отправляет запрос к серверу, на котором расположен сайт.
Сервер возвращает браузеру HTML-страницу и связанные с ней ресурсы: CSS, JavaScript, изображения, шрифты и другие файлы.
Браузер начинает загружать и собирать страницу.
Если на странице установлен код аналитики, браузер загружает и выполняет этот код.
Код аналитики считывает доступные данные: адрес страницы, источник перехода, параметры URL, устройство, браузер, язык, примерное местоположение, технические характеристики и действия пользователя.
Затем код отправляет данные на сервер аналитической системы: например, Google Analytics или Яндекс Метрики.
Система аналитики обрабатывает полученные данные и сохраняет их в своих базах.
После этого данные становятся доступны в отчетах.
На практике весь этот процесс происходит быстро и незаметно для пользователя. Но для аналитика важно понимать: данные появляются в отчетах не “сами по себе”, а только если код аналитики загрузился, выполнился и смог отправить информацию на сервер.
Роль браузера в web-аналитике
Браузер — это не просто программа, в которой пользователь смотрит сайт. Для web-аналитики браузер является ключевым участником сбора данных.
Именно браузер:
загружает страницу;
выполняет JavaScript-код;
хранит cookies;
передает referrer — откуда пользователь пришел;
передает user agent — информацию о браузере и устройстве;
отправляет запросы на серверы аналитических систем;
может блокировать часть скриптов или cookies;
может работать в обычном режиме, инкогнито или с расширениями вроде AdBlock.
То есть аналитика в большинстве случаев видит не “человека” напрямую, а браузер, устройство и набор технических идентификаторов. Поэтому один и тот же человек может быть распознан как несколько разных пользователей, если он зашел с телефона, ноутбука, другого браузера или очистил cookies.
Это важный момент: web-аналитика работает с цифровыми следами, а не с человеком как с паспортной сущностью.
Что делает JavaScript-код аналитики
JavaScript-код счетчика — это небольшая программа, которая выполняется в браузере пользователя.
Когда страница загружается, код аналитики может собрать данные о текущем посещении. Например:
URL страницы;
заголовок страницы;
источник перехода;
UTM-метки;
тип устройства;
браузер;
операционную систему;
язык браузера;
примерную географию;
время загрузки;
события пользователя;
клики;
скролл;
отправку формы;
переходы по ссылкам;
просмотр видео;
добавление товара в корзину;
покупку.
Не все эти данные собираются автоматически. Часть данных стандартные системы аналитики собирают сами, а часть нужно специально настроить через Google Tag Manager, код сайта, dataLayer или серверную передачу событий.
Например, обычный просмотр страницы чаще всего собирается автоматически. А вот успешная отправка формы, покупка, клик по важной кнопке, раскрытие FAQ-блока или взаимодействие с калькулятором часто требуют отдельной настройки.
Что такое cookies и Client ID
Когда пользователь впервые заходит на сайт, система аналитики пытается понять: это новый пользователь или тот, кто уже был раньше.
Для этого часто используются cookies — небольшие файлы или записи, которые сохраняются в браузере пользователя.
В случае Google Analytics один из ключевых идентификаторов — Client ID. Это технический идентификатор браузера, который помогает системе отличать одного посетителя от другого.
Упрощенно логика такая:
если у пользователя нет cookie с идентификатором, система считает его новым пользователем;
если cookie уже есть, система может считать его вернувшимся пользователем;
если пользователь очистил cookies, зашел в режиме инкогнито или использует другой браузер, система может распознать его как нового.
Поэтому количество пользователей в аналитике — это не абсолютное количество реальных людей. Это оценка на основе доступных идентификаторов.
Один человек может быть посчитан несколько раз. И наоборот, несколько человек теоретически могут использовать одно устройство и один браузер, а аналитика будет видеть их как одного пользователя.
Почему сбор данных начинается только после загрузки счетчика
Важный принцип: данные начинают собираться только после того, как код аналитики загрузился и выполнился.
Если пользователь открыл страницу и ушел до загрузки счетчика, визит может не попасть в систему аналитики.
Если код установлен слишком поздно, например внизу страницы, часть быстрых отказов может не фиксироваться.
Если на сайте ошибка JavaScript, часть событий может не отправиться.
Если пользователь использует блокировщик рекламы или приватный браузер, часть аналитических запросов может быть заблокирована.
Если не настроено согласие на cookies или пользователь отказался от трекинга, часть данных может быть ограничена.
Поэтому в конспектах и практических рекомендациях обычно советуют устанавливать код аналитики как можно раньше в загрузке страницы, часто перед закрывающим тегом <head>. Так повышается вероятность, что счетчик успеет загрузиться и зафиксировать посещение.
Почему счетчик рекомендуют ставить в
HTML-страница загружается браузером сверху вниз. Если код аналитики расположен ближе к началу документа, он с большей вероятностью выполнится раньше.
Когда код установлен в <head>, система аналитики быстрее получает возможность зафиксировать просмотр страницы. Это особенно важно для сайтов, где пользователи могут быстро закрывать страницу: например, при медленной загрузке, нерелевантном трафике, случайных кликах или технических проблемах.
Если счетчик стоит слишком низко в коде страницы, возможна ситуация: пользователь зашел, страница начала грузиться, но человек закрыл вкладку до того, как код аналитики выполнился. В этом случае реальное посещение было, но система аналитики могла его не увидеть.
На практике часто используют Google Tag Manager: контейнер GTM устанавливают на сайт, а уже внутри него размещают Google Analytics, Яндекс Метрику, рекламные пиксели и другие теги.
Куда отправляются данные
После того как код аналитики собрал данные в браузере, он отправляет их на сервер аналитической системы.
Например:
данные GA4 отправляются на серверы Google Analytics;
данные Яндекс Метрики отправляются на серверы Яндекса;
события Meta Pixel отправляются в Meta;
данные рекламных пикселей отправляются в соответствующие рекламные системы.
Дальше происходит обработка данных. Система аналитики принимает события, связывает их с пользователями, сессиями, источниками трафика, устройствами, страницами и другими параметрами. Затем данные сохраняются в базах и становятся доступны в отчетах.
Аналитик видит уже не “сырые запросы браузера”, а обработанные отчеты: пользователи, сеансы, события, конверсии, каналы, страницы, устройства, география, аудитории и другие срезы.
Почему отчеты появляются не мгновенно
Часть данных может отображаться почти сразу — например, в отчетах реального времени. Но большинство стандартных отчетов обновляется с задержкой.
Это нормально.
Система должна получить данные, обработать их, применить фильтры, связать с источниками трафика, распределить по отчетам и иногда применить ограничения приватности или моделирование.
Поэтому при проверке установки счетчика используют несколько инструментов:
отчеты в реальном времени;
DebugView в GA4;
Preview Mode в Google Tag Manager;
отладчик Яндекс Метрики;
исходный код страницы;
панель Network в DevTools;
расширения браузера для проверки тегов.
Главная задача на этапе внедрения — не просто “поставить код”, а убедиться, что данные действительно уходят в систему аналитики и корректно отображаются в отчетах.
Что именно собирает web-аналитика
Системы аналитики могут собирать разные группы данных.
Первая группа — данные о странице:
URL;
заголовок;
путь страницы;
домен;
параметры URL;
referrer;
UTM-метки.
Вторая группа — данные о пользователе как о техническом объекте:
браузер;
тип устройства;
операционная система;
разрешение экрана;
язык;
примерная география;
новый или вернувшийся пользователь.
Третья группа — данные о поведении:
просмотр страницы;
глубина скролла;
клики;
скачивание файлов;
просмотр видео;
поиск по сайту;
отправка формы;
переходы по внешним ссылкам.
Четвертая группа — бизнес-события:
заявка;
регистрация;
звонок;
клик по номеру телефона;
добавление в корзину;
начало оформления заказа;
покупка;
оплата;
повторная покупка;
отмена или возврат.
Пятая группа — рекламные данные:
источник трафика;
канал;
кампания;
группа объявлений;
креатив;
ключевое слово;
автометки вроде gclid, yclid, fbclid;
расходы, клики и показы, если настроены интеграции или импорт данных.
Важно понимать: система аналитики не всегда собирает все это автоматически. Чем сложнее бизнес-задача, тем больше требуется настройки.
Простая схема работы web-аналитики
Можно представить процесс так:
Пользователь → Браузер → Сайт → Код счетчика → Сервер аналитики → База данных → Отчеты → Выводы → Решения.
Именно последняя часть особенно важна.
Данные нужны не ради данных. Web-аналитика нужна для принятия решений:
какие каналы приводят качественный трафик;
какие страницы помогают продавать;
где пользователи теряются;
какие кнопки и формы работают;
какие рекламные кампании окупаются;
какие гипотезы стоит проверять;
что нужно улучшить на сайте.
Если аналитика собрана, но никто не делает выводы и не меняет маркетинг, продукт или сайт, то система превращается в красивый счетчик посещаемости. Настоящая web-аналитика начинается там, где данные превращаются в действия.
Почему данные в аналитике могут быть неточными
Одна из главных ошибок начинающих специалистов — ожидать от web-аналитики абсолютной точности.
На практике данные почти всегда имеют погрешность.
Причины могут быть разные:
счетчик не установлен на все страницы;
счетчик установлен дважды;
код загружается слишком поздно;
пользователь ушел до загрузки кода;
часть скриптов блокируется браузером;
пользователь очистил cookies;
визит был в режиме инкогнито;
часть данных ограничена настройками приватности;
разные системы по-разному считают сеансы и пользователей;
ошибки в UTM-метках;
неправильные настройки целей и событий;
боты и спам-трафик;
технические сбои на сайте;
редиректы;
ошибки JavaScript;
Consent Mode и ограничения согласия пользователя.
Поэтому web-аналитик не должен относиться к отчетам как к бухгалтерской ведомости с абсолютной точностью до последней единицы. Аналитика чаще работает с достаточно точными ориентирами, тенденциями, соотношениями и закономерностями.
Главный вопрос не “почему в двух системах цифры отличаются на 3%”, а “достаточно ли качественные данные, чтобы принять правильное управленческое решение”.
Почему Google Analytics и Яндекс Метрика могут показывать разные данные
Google Analytics и Яндекс Метрика могут отличаться по данным даже на одном и том же сайте.
Причины:
разные алгоритмы определения пользователя;
разные правила расчета визита или сеанса;
разные настройки тайм-аута;
разная обработка отказов;
разная фильтрация ботов;
разные ограничения приватности;
разное время обработки данных;
разные часовые пояса;
разные установленные фильтры;
одна система может быть заблокирована у части пользователей чаще, чем другая;
счетчики могут быть установлены не одинаково.
Например, один и тот же визит может быть зафиксирован в Яндекс Метрике, но не попасть в GA4, если запрос к Google был заблокирован. Или наоборот: событие могло уйти в GA4, но не отправиться в Метрику из-за ошибки в настройке.
Поэтому аналитик должен не просто смотреть цифры, а понимать механику их появления.
Google Tag Manager: зачем он нужен в этой цепочке
Google Tag Manager — это система управления тегами. Он позволяет установить на сайт один контейнер, а уже внутри него управлять разными кодами аналитики и рекламы.
Без GTM каждый новый код часто приходится добавлять через разработчика или вручную в шаблон сайта. Это дольше, рискованнее и сложнее контролировать.
С GTM можно централизованно управлять:
GA4;
Яндекс Метрикой;
Meta Pixel;
Google Ads;
событиями;
триггерами;
переменными;
dataLayer;
кастомными HTML-тегами;
проверкой через Preview Mode.
Но важно понимать: GTM сам по себе не является системой аналитики. Это контейнер и диспетчер тегов. Он помогает запускать нужные скрипты в нужный момент и передавать данные в аналитические и рекламные системы.
Почему счетчика может не быть видно в коде сайта
Иногда начинающий специалист открывает исходный код страницы, ищет “Analytics” или “Metrika” и ничего не находит. Возникает вывод: счетчик не установлен.
Но это не всегда так.
Если сайт использует Google Tag Manager, то Google Analytics и Яндекс Метрика могут быть установлены внутри контейнера GTM. В исходном коде страницы будет виден только код GTM, а сами счетчики будут загружаться уже через него.
Поэтому правильная проверка выглядит так:
проверить исходный код страницы;
найти Google Tag Manager, Analytics, Metrika;
проверить вкладку Network в DevTools;
открыть Preview Mode в GTM, если есть доступ;
посмотреть отчеты в реальном времени;
проверить DebugView в GA4;
проверить статус счетчика в Яндекс Метрике.
Если есть GTM, нужно получить доступ к контейнеру и посмотреть, какие теги там реально настроены.
Минимальный чек-лист проверки счетчика
После установки аналитики нужно проверить не только наличие кода, но и факт передачи данных.
Минимальный чек-лист:
Счетчик установлен на все нужные страницы.
На странице нет дубля одного и того же счетчика.
Код не слетает при обновлении шаблона или CMS.
В GA4 видны данные в режиме реального времени или DebugView.
В Яндекс Метрике счетчик имеет рабочий статус.
В GTM Preview Mode видно срабатывание нужных тегов.
События отправляются с правильными названиями.
UTM-метки корректно попадают в отчеты.
Внутренний трафик при необходимости фильтруется.
Доступы к GA4, Метрике и GTM есть у владельца бизнеса или ответственного аккаунта.
Последний пункт особенно важен. Аналитика — это бизнес-актив. Если счетчик создан на личную почту подрядчика, который потом пропал, компания может потерять доступ к историческим данным.
Что должен понимать начинающий web-аналитик
Начинающему web-аналитику не обязательно быть программистом. Но нужно понимать базовую техническую механику.
Минимум, который стоит знать:
как браузер загружает страницу;
что такое HTML, CSS и JavaScript на базовом уровне;
как работает код счетчика;
что такое cookies;
что такое Client ID;
почему пользователь не всегда равен человеку;
как данные отправляются на сервер аналитики;
почему данные могут не собираться;
как проверить установку счетчика;
чем прямой код отличается от установки через GTM;
почему отчеты разных систем могут отличаться.
Эти знания помогают не попадать в типичные ошибки. Например, не делать вывод “реклама не работает”, если на самом деле не сработала цель. Или не спорить с клиентом о “потерянных заявках”, если событие отправки формы было настроено на клик по кнопке, а не на успешную отправку формы.
Пример из практики
Допустим, пользователь переходит на сайт из рекламы.
Ссылка содержит UTM-метки:
utm_source=yandex
utm_medium=cpc
utm_campaign=course_promo
Браузер открывает страницу. Вместе со страницей загружается GTM. Через GTM срабатывает тег GA4 и тег Яндекс Метрики.
Счетчики фиксируют просмотр страницы, источник перехода, устройство, браузер и другие параметры.
Пользователь прокручивает страницу, смотрит блок программы курса, раскрывает FAQ, нажимает кнопку “Получить консультацию” и отправляет форму.
Если все настроено правильно, в аналитику уйдут не только данные о визите, но и события:
просмотр страницы;
скролл;
клик по кнопке;
отправка формы;
конверсия или ключевое событие.
После этого аналитик сможет увидеть, что пользователь пришел из Яндекс Директа, изучил страницу курса и оставил заявку.
Если же аналитика настроена плохо, может быть виден только просмотр страницы. Тогда в отчете будет трафик, но не будет понятно, какие действия пользователь совершил и была ли заявка.
Главное
Web-аналитика начинается не с красивых отчетов, а с корректного сбора данных.
Если код счетчика не установлен, установлен не везде, дублируется, срабатывает слишком поздно или неправильно передает события, то все последующие отчеты будут искажены.
Поэтому хороший web-аналитик сначала понимает техническую цепочку:
как пользователь открывает сайт;
как браузер загружает страницу;
как выполняется JavaScript-код;
как создаются и читаются cookies;
как формируется идентификатор пользователя;
как события отправляются на сервер аналитики;
как данные обрабатываются и появляются в отчетах.
И только после этого он переходит к анализу: источники трафика, поведение пользователей, конверсии, эффективность рекламы, гипотезы роста и управленческие решения.
Итого:
Система web-аналитики работает как связка нескольких элементов: сайт, браузер, JavaScript-код, cookies, сервер аналитики, база данных и интерфейс отчетов.
Пользователь видит обычную страницу сайта. Но в этот момент в фоне может происходить десяток технических процессов: загрузка счетчиков, определение источника перехода, создание Client ID, отправка события page_view, фиксация кликов, передача конверсий и обработка данных.
Понимание этой механики — базовый навык web-аналитика. Без него сложно правильно установить аналитику, проверить ее работу, объяснить расхождения в отчетах и принимать решения на основе данных.
Именно поэтому изучение web-аналитики стоит начинать не с интерфейса отчетов, а с вопроса: как данные вообще попадают в систему аналитики?
