Почему цифры в аналитических системах расходятся

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

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

Рабочая задача аналитика — не заставить все отчёты стать одинаковыми, а восстановить причину различия и решить, влияет ли она на вывод.

Сначала определите, какие именно две цифры вы сравниваете

Фраза:

В Search Console 1 200 переходов, а в аналитике только 980.

уже содержит возможную проблему: в одной системе может быть click, а в другой — session.

Это разные сущности.

Один пользователь может:

кликнуть результат поиска;
не дождаться загрузки страницы;
перейти через redirect;
заблокировать аналитический JavaScript;
вернуться на сайт ещё раз внутри той же сессии;
создать несколько событий после одного клика.

Поэтому первый вопрос:

Название метрики совпадает или совпадает её фактическое определение?

Одинаковое название не гарантирует одинаковое определение

Особенно это заметно с лидами и конверсиями.

Для рекламной системы «конверсия» может означать сработавшее conversion action.

Для системы веб-аналитики — событие, помеченное как ключевое.

Для CRM — созданную карточку лида.

Для отдела продаж — только квалифицированный лид.

Для финансового отчёта — оплаченную сделку.

Если эти пять чисел поставить в одну строку без определения, получится не reconciliation, а сравнение разных стадий воронки.

Поэтому перед поиском технической ошибки зафиксируйте:

метрика в системе A:
что считается событием:

метрика в системе B:
что считается событием:

должны ли эти события быть 1:1?

Проверьте единицу подсчёта

Одна система может считать:

события;
пользователей;
сессии;
клики;
заказы;
уникальные лиды;
строки в базе.

Это влияет даже на очень простые отчёты.

Например, один пользователь отправил форму два раза.

В зависимости от системы вы можете получить:

2 события
1 пользователь
1 сессия
2 формы
1 лид после дедупликации

Ни одно число не обязано быть ошибочным.

Search Console и веб-аналитика измеряют разные участки цепочки

Google прямо указывает, что данные Search Console могут отличаться от Google Analytics и других инструментов.

Среди причин:

разный набор URL;
дополнительная обработка данных;
удаление дублей и роботного трафика;
JavaScript-зависимый сбор в веб-аналитике;
privacy-фильтрация;
задержки публикации;
разные часовые пояса.

Поэтому:

клики Search Console ≠ organic sessions веб-аналитики

Это не формула пересчёта, а предупреждение: метрики относятся к разным точкам пользовательского пути.

Нарисуйте путь события от источника до отчёта

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

реальное действие пользователя
↓
событие на сайте / в приложении
↓
трекер
↓
отправка данных
↓
приём системой
↓
обработка
↓
фильтры
↓
атрибуция
↓
агрегация
↓
отчёт / API / BI

Расхождение может появиться на любом этапе.

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

Сравнивайте одинаковый scope

Даже внутри одной экосистемы можно случайно сравнить разный охват.

Например:

в одной системе весь домен, в другой только поддомен;
в одной — web + app, в другой только web;
в одном отчёте все страны, в другом только основной рынок;
в CRM все формы, в BI только коммерческие;
в одном отчёте тестовый трафик исключён, в другом остался.

Поэтому перед reconciliation запишите scope обеих сторон:

домен / приложение
регион
устройство
канал
страницы
типы событий
тестовый трафик
внутренний трафик

Если scope различается, сравнение нужно сначала привести к общей области.

Проверьте периоды до любых технических гипотез

Очень много «расхождений» начинается с дат.

Например:

одна система показывает 1–31 июля;
вторая — последние 30 дней;
CRM обновилась только до 30 июля;
BI загрузил данные на момент 08:00;
рекламная система позднее доатрибутировала конверсии.

Формально заголовки отчётов могут выглядеть одинаково, а фактическое временное окно будет различаться.

Проверка сопоставимости временных окон отдельно разобрана в статье о сравнении периодов в аналитике.

Часовой пояс особенно заметен на суточных отчётах

Google указывает, что Search Console традиционно маркирует дневные данные по времени Калифорнии, тогда как Google Analytics может использовать локальный часовой пояс property.

Событие, произошедшее около границы суток, способно попасть:

в понедельник в системе A;
во вторник в системе B.

На месячном отчёте эффект может быть небольшим.

На дневном — заметным.

Перед сравнением проверьте:

timezone property;
timezone рекламного аккаунта;
timezone CRM;
UTC в выгрузках;
как BI преобразует timestamp.

Свежие данные могут находиться на разных стадиях обработки

Одна система обновляет отчёт быстрее другой.

Google Search Console указывает, что между сбором и появлением обычных данных может быть лаг. В GA4 свежие события также продолжают обрабатываться и агрегироваться, поэтому значения в UI и API могут немного меняться при повторном запросе через короткое время.

Для reconciliation полезно ввести правило:

Не сравнивать «почти реальное время» одной системы с уже финализированным отчётом другой.

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

Поздние события могут переписать прошлый день

Некоторые события поступают не сразу.

Например:

устройство было офлайн;
CRM передала сделку позже;
Measurement Protocol отправил событие с задержкой;
система получила офлайн-конверсию после закрытия дня.

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

Поэтому вчерашнее значение и значение за вчера, открытое через три дня, могут отличаться.

Для повторяемого отчёта важно фиксировать не только event date, но и дату получения отчёта.

Фильтры могут создавать расхождение внутри одной системы

Перед поиском сложной причины проверьте очевидное:

comparison;
segment;
channel group;
source / medium;
country;
device;
hostname;
event name;
page path;
internal traffic;
developer traffic.

Отчёт без видимого фильтра и Explore с сегментом — уже разные выборки.

То же относится к BI: фильтр может быть зашит в модель, вычисляемое поле или SQL-запрос и не отображаться рядом с графиком.

Scope метрики может меняться при добавлении dimension

GA4 отдельно предупреждает, что добавление dimensions в отчёт может изменить число событий, используемых в расчёте: остаются только события, у которых есть данные для запрошенного dimension.

Поэтому:

общий total

и:

сумма строк после добавления dimension

не всегда обязаны совпадать.

Перед ручным суммированием строк нужно понимать, на каком scope работает dimension и какие события после группировки выпадают.

High cardinality может скрыть часть детализации в строке «(other)»

В GA4 dimensions с большим числом уникальных значений могут превысить лимиты агрегированной таблицы.

Тогда менее частые значения группируются в строку (other).

Google относит к high-cardinality, например, dimensions вроде Page path или Item ID, если уникальных значений очень много.

В результате:

total может оставаться корректным;
детализация по строкам теряется;
повторное суммирование отдельных dimensions становится неточным.

Это особенно важно при сравнении GA4 UI с более детальной выгрузкой в BigQuery.

Sampling меняет точность отчёта

В некоторых режимах GA4 большие или сложные запросы могут строиться на выборке данных.

Google показывает факт sampling в Data quality indicator и указывает долю данных, использованную для результата.

Если один отчёт unsampled, а другой построен на выборке, различие может возникнуть даже при одинаковых фильтрах.

Перед сравнением полезно проверить индикатор качества данных, а не только значения в таблице.

Thresholding — это не пропавший трекинг

GA4 может скрывать часть данных из отчёта или Exploration, если срабатывают privacy thresholds.

Это делается, чтобы нельзя было вывести чувствительную информацию о малом числе пользователей.

Особенно пороговые ограничения могут проявляться при:

узком диапазоне дат;
малой аудитории;
демографических dimensions;
некоторых данных о поисковых запросах.

То есть:

данные не отображаются

и:

события не были собраны

— разные ситуации.

Privacy-фильтрация есть и в Search Console

Search Console не показывает все редкие запросы в таблицах, чтобы защищать приватность пользователей.

Google также ограничивает количество строк, доступных в интерфейсе.

Поэтому:

сумма строк Queries

может быть меньше:

общего числа clicks или impressions на графике.

Если аналитик вручную пересчитывает total по видимым строкам, он создаёт расхождение сам.

Modeling может отличать агрегированный отчёт от сырых событий

Современные аналитические платформы не всегда показывают только буквальную сумму сохранённых event rows.

В GA4 часть reporting surfaces может включать дополнительные механизмы, связанные с:

Google Signals;
reporting identity;
Consent Mode;
моделированием;
атрибуцией;
оценкой уникальных пользователей.

В официальном материале Google о расхождениях между GA4 UI и BigQuery прямо отмечается, что различия между стандартными отчётами и export ожидаемы: не все дополнительные механизмы reporting layer представлены в сырых экспортных данных одинаковым образом.

Поэтому BigQuery и UI нужно сравнивать только после воспроизведения логики нужной метрики.

«Сырые данные» не означают «готовый правильный total»

Есть распространённая ошибка:

В BigQuery лежат raw events, значит достаточно сделать COUNT(*).

Но business metric может требовать:

дедупликации;
sessionization;
определения active user;
выбора идентификатора пользователя;
фильтрации технических событий;
обработки delayed events;
правильного scope dimension;
учёта timezone.

То есть сырьё детальнее агрегированного отчёта, но аналитическую логику всё равно нужно восстановить.

Атрибуция отвечает на другой вопрос, чем факт события

Представим одну покупку.

Факт покупки может быть один.

Но разные системы могут по-разному отвечать на вопрос:

Какому каналу отдать заслугу за эту покупку?

На результат влияют:

attribution model;
lookback window;
дата клика;
дата конверсии;
cross-device identity;
наличие view-through interactions;
правила прямого трафика;
импорт офлайн-событий.

Поэтому расхождение attributed conversions не обязательно означает расхождение в самом числе реальных покупок.

Сначала разделите:
что произошло vs кому система приписала результат

Дата конверсии и дата взаимодействия могут давать разные временные ряды

Пользователь кликнул рекламу 28 июля и купил 3 августа.

Одна модель отчётности может связать результат с датой взаимодействия.

Другая — показывать событие по фактической дате покупки.

Тогда:

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

Поэтому reconciliation лучше начинать с достаточно широкого окна, а уже затем разбирать расхождение по дням.

CRM почти всегда содержит дополнительную бизнес-логику

CRM может удалять или объединять то, что веб-аналитика считает отдельными событиями.

Например:

повторная форма объединена с существующим лидом;
спам удалён;
тестовый лид исключён;
контакт переведён в другой статус;
несколько заявок объединены в одну сделку;
сделка создана вручную менеджером;
источник переопределён после разговора с клиентом.

Поэтому «формы на сайте» и «лиды CRM» редко имеют гарантированное отношение 1:1 без специально согласованной модели.

BI может добавлять ещё один слой преобразований

BI-отчёт обычно не является прямым окном в исходную систему.

Между ними могут находиться:

ETL;
SQL-трансформации;
справочники;
дедупликация;
join нескольких источников;
currency conversion;
business rules;
вычисляемые поля.

Если BI показывает другое число, нужно проверить lineage:

источник
↓
выгрузка
↓
преобразование
↓
модель
↓
визуализация

Без этой цепочки «сверить BI с кабинетом» часто невозможно.

Не начинайте с процента расхождения

Фраза:

Системы расходятся на 8%.

сама по себе мало помогает.

Нужно понять структуру этих 8%.

Расхождение может быть:

стабильным каждый день;
только на мобильных;
только после 18:00;
только по одному каналу;
только после изменения трекинга;
только на свежих данных;
только в отдельных строках при совпадающем total.

Структура расхождения обычно информативнее его среднего размера.

Разложите discrepancy по измерениям

Если общий total отличается, сравните последовательно:

день;
устройство;
страна;
канал;
landing page;
event type;
conversion type.

Если разница локализуется, круг причин резко сужается.

Например:

Desktop совпадает, mobile нет.

Тогда общая проблема attribution уже менее вероятна, а вот клиентский tracking, consent или mobile redirect становятся более содержательными направлениями проверки.

Ищите момент, когда системы начали расходиться

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

Если отчёты совпадали до конкретной даты, а затем разошлись, нужен changepoint.

Проверьте, что произошло рядом:

смена счётчика;
изменение GTM;
новая consent platform;
редиректы;
обновление CRM-интеграции;
смена attribution settings;
изменение timezone;
новая логика BI;
изменение названия события.

Временная локализация часто полезнее просмотра десятков настроек без приоритета.

Проверьте один конкретный кейс end-to-end

Когда aggregate reconciliation не даёт ответа, возьмите одно известное событие.

Например:

Тестовая заявка, отправленная 20 августа в 13:05.

Проверьте последовательно:

сработало ли событие в браузере;
ушло ли оно в endpoint;
появилось ли в debug / realtime;
попало ли в стандартный отчёт;
создалась ли запись в CRM;
передалась ли она в BI;
сохранился ли идентификатор для сопоставления.

Один trace не доказывает полноту всей системы, но хорошо показывает, на каком участке события начинают исчезать или преобразовываться.

Идентификаторы сокращают число догадок

Если бизнесу нужна точная reconciliation на уровне лидов или заказов, полезно передавать стабильный идентификатор.

Например:

order_id;
transaction_id;
lead_id;
application_id.

Тогда можно сравнивать не только totals:

система A: ID 101, 102, 103
система B: ID 101, 103

и сразу увидеть, какое конкретное событие потеряно.

Без ID аналитик часто пытается объяснить разницу только агрегатами.

Дедупликация должна иметь явное правило

Система может получить два одинаковых события.

Что считать результатом?

два события;
одно событие по transaction_id;
один лид в пределах суток;
один лид на email;
одну сделку на клиента.

Если две системы используют разные правила дедупликации, totals не совпадут даже при идеальной доставке событий.

Поэтому правило уникальности — часть определения метрики.

Не исправляйте нормальное методологическое расхождение коэффициентом

Иногда команда замечает:

Система B всегда показывает примерно на 6% меньше.

и вводит коэффициент 1,06.

Это опасно, если причина не установлена.

Разница может зависеть от:

устройства;
канала;
privacy consent;
времени суток;
изменения состава трафика.

Средний коэффициент прошлого месяца способен только скрыть новое отклонение.

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

Не каждое расхождение нужно устранять

После проверки возможны три результата.

1. Ошибка

Например, событие отправляется дважды.

Такое расхождение нужно исправлять.

2. Методологическое различие

Например, click и session или разные attribution models.

Его нужно документировать, а не «чинить».

3. Несопоставимые отчёты

Например, агрегированный modeled report против сырого набора событий без воспроизведения reporting logic.

Такие значения иногда правильнее не сравнивать напрямую.

У каждой бизнес-задачи может быть свой рабочий источник

Не существует универсального правила:

Всегда верьте CRM.

или:

Всегда верьте веб-аналитике.

Источник зависит от вопроса.

Вопрос	Логичный рабочий источник
Сколько кликов сайт получил из Google Search?	Search Console
Что пользователь делал после загрузки сайта?	Система веб-аналитики
Сколько лидов дошло до квалификации?	CRM при согласованной логике статусов
Сколько заказов оплачено?	Транзакционная или финансовая система
Какому каналу отчёт приписывает результат?	Конкретная attribution model в выбранной системе

Смысл не в том, чтобы назначить одну систему «истиной», а в том, чтобы использовать источник, который действительно фиксирует нужный объект.

Соберите reconciliation-карту

Бизнес-вопрос:

Система A:
Метрика A:
Определение A:
Единица A:
Scope A:
Timezone A:
Attribution A:
Filters A:
Data freshness A:

Система B:
Метрика B:
Определение B:
Единица B:
Scope B:
Timezone B:
Attribution B:
Filters B:
Data freshness B:

Период:

Абсолютная разница:
Относительная разница:

Где локализуется discrepancy:

Есть ли ID для сопоставления:

Класс причины:
[ ] ошибка сбора
[ ] разное определение
[ ] разный scope
[ ] timezone
[ ] attribution
[ ] processing delay
[ ] privacy / threshold
[ ] sampling
[ ] modeling
[ ] deduplication
[ ] BI transformation
[ ] другое

Решение:
[ ] исправить
[ ] документировать
[ ] не сравнивать напрямую

Такая карта быстрее приводит к ответу, чем попытка одновременно проверить все настройки всех систем.

Порядок поиска причины

Назовите две сравниваемые метрики.
Проверьте их определения.
Проверьте единицу подсчёта.
Сравните scope.
Выставьте одинаковый период.
Сверьте timezone.
Проверьте filters и segments.
Сверьте attribution rules.
Проверьте data freshness.
Посмотрите privacy, sampling, thresholding и cardinality.
Разложите discrepancy по dimensions.
Найдите дату начала расхождения.
Проверьте одно событие end-to-end.
Сопоставьте ID, если они есть.
Классифицируйте расхождение как ошибку, методологическую разницу или несопоставимость.

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

Что наблюдаем	Что проверить первым
Search Console clicks больше organic sessions	Определение click/session, JavaScript, redirects, privacy, timezone
CRM лидов меньше, чем отправок формы	Дедупликацию, спам-фильтры, повторные обращения, ошибки интеграции
UI GA4 и BigQuery отличаются	Reporting logic, delayed events, identity, modeling, scope, timezone
Сумма строк меньше total	Privacy, row limits, thresholding, high cardinality, scope dimension
Сегодняшние данные расходятся, старые совпадают	Data freshness и processing delay
Расхождение появилось с конкретной даты	Изменения трекинга, consent, CRM, ETL, attribution settings
Только mobile расходится	Mobile tracking, redirects, consent, app/web scope
Только один канал расходится	Attribution и channel classification
Дневные данные расходятся, месячные близки	Timezone и дата attribution
Одинаковый total, разные строки	Dimensions, cardinality, grouping и classification rules

Итог: reconciliation начинается с определений, а не с «правильной цифры»

Рабочая цепочка выглядит так:

расхождение
↓
одинаков ли объект
↓
одинаково ли определена метрика
↓
scope
↓
период и timezone
↓
collection
↓
filters
↓
attribution
↓
processing / modeling
↓
privacy / limits
↓
воспроизводимая причина
↓
исправить / документировать / не сравнивать напрямую

Главная ошибка — считать любое несовпадение доказательством плохого трекинга.

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

Хорошая reconciliation не заставляет все цифры совпасть. Она делает понятным, почему они различаются и какую цифру использовать для конкретного решения.

Источники

Источники проверены 18 августа 2026 года.