Почему отчёты Метрики и GA4 различаются

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

Возьмём отдельный вымышленный файл platform-comparison.csv. Для периода W1 в нём указаны 180 открытий и 28 продолжений у metrica_sample, 170 и 26 у ga4_sample. Это придуманные агрегаты, не результаты настоящей одновременной установки. Они не заменяют основную таблицу W1/W2 и не складываются с ней.

Какой показатель сравнивается

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

В учебном сравнении мы специально считаем одинаковые имена событий. Разница открытий составляет 10, примерно 5,56% относительно выбранного основания 180. Если основанием сделать 170, получится другой процент. Поэтому рядом с относительным расхождением сохраняйте оба числа и направление сравнения. Формулировка «разница пять процентов» без основания неполна.

Отношение продолжений к открытиям у первой строки равно примерно 15,56%, у второй — 15,29%. Близость отношений не доказывает одинаковую полноту данных. Две системы способны пропускать разные группы, которые случайно дают похожий результат. И наоборот, разные отношения не определяют причину без дополнительного анализа состава событий.

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

Период и границы суток

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

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

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

Параметры и группировка

Наши события имеют article_id, но в обычном отчёте может использоваться полный URL. Метки кампании разобьют один документ на разные строки, если выбранная группировка их учитывает. Заголовки могут объединить две разные статьи с похожими названиями. Поэтому проверяемый реестр ID нужен не только на этапе отправки, но и при чтении отчёта.

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

Условия сегмента тоже должны относиться к одинаковой сущности. Сегмент «визиты, где было событие» и фильтр «только сами события» способны дать разные наборы строк. Метрика прямо описывает различие при работе с параметрами. Для GA4 изучите область действия выбранного измерения и совместимость с метрикой отчёта. Сегментация Метрики, совместимость данных GA4.

Предположим, посетитель открыл Markdown, перешёл в XML и скачал исходник. Один сегмент может включить весь такой визит, другой — только строку скачивания. Оба результата соответствуют своим условиям. Ошибка возникает, когда редактор сравнивает их как одинаковые подсчёты действия, не сохранив правило отбора.

Доставка и обработка

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

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

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

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

Диагностическая таблица

Составьте заметку из пяти строк: определения, период, набор документов, фильтры, доставка. Для каждой укажите источник и состояние: совпадает, различается либо неизвестно. Это помогает выбрать следующее действие. Если периоды отличаются, исправьте отбор; если локальный вызов отсутствует только у XML, исследуйте его оболочку.

Ожидаемый полезный результат — объяснённое расхождение или узкая непроверенная гипотеза. Например, «сравнивались пользователи и события, после согласования метрики нужен новый экспорт». Другой вариант: «оба локальных вызова есть, причины различия обработанных данных пока неизвестны». Второе утверждение тоже лучше, чем произвольный вывод о неверной платформе.

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