Как проверить расхождение отчётов из-за часового пояса

Два дневных отчёта могут показать одинаковое число лидов и при этом включать разные заявки. Это случается, когда рекламный кабинет, аналитика и CRM проводят границу суток в разных часовых поясах. Проверка занимает три шага: сохранить точное время события, привести его к одной зоне и только затем сравнить ID.

Сначала найдите один лид, а не разницу в процентах

Возьмите три–пять заявок рядом с полуночью. Для каждой нужны устойчивый lead_id или order_id и исходное время с часовым поясом, например 2026-10-05T22:30:00Z. Строка 05.10.2026 22:30 недостаточна: без зоны неизвестно, означает она UTC, время сервера или местное время сотрудника.

Выгрузите для тех же ID:

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

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

Где проверить границу суток

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

В GA4 поле timeZone задаёт часовой пояс отчётности и границу дня. Google отдельно предупреждает: изменение действует на будущие данные и не пересчитывает прошлые периоды. В экспорте BigQuery поле event_date относится к зарегистрированному часовому поясу ресурса, а event_timestamp хранит точный момент в микросекундах UTC — это удобная опора для повторного расчёта.

У счётчика Яндекс Метрики API возвращает time_zone_name и текущий time_zone_offset: они описаны как параметры расчёта статистики. Для CRM проверьте отдельно, что хранится в базе и что показывает интерфейс. Некоторые системы сохраняют UTC, а на экране переводят время в зону пользователя.

Учебный пример: итоги равны, состав разный

Представим, что рекламный аккаунт работает в America/Los_Angeles, а GA4 и рабочий отчёт — в Europe/Minsk. Три лида пришли в моменты, указанные в UTC.

За 5 октября оба отчёта покажут по два лида. В американской зоне это L-102 и L-103, в Минске — L-101 и L-102. Итоги сходятся, но одна запись в каждой системе относится к соседнему дню. Решение по кампании, каналу или менеджеру на основе одной даты будет опираться на разные наборы данных.

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

Как воспроизвести проверку

Создайте CSV с колонками id и event_utc, затем преобразуйте время стандартной библиотекой Python. Названия зон берутся из базы IANA и учитывают сезонные переходы там, где они применяются.

import csv
from datetime import datetime
from zoneinfo import ZoneInfo

zones = {
    "ads_date": ZoneInfo("America/Los_Angeles"),
    "business_date": ZoneInfo("Europe/Minsk"),
}

with open("events.csv", encoding="utf-8", newline="") as source:
    rows = csv.DictReader(source)
    for row in rows:
        moment = datetime.fromisoformat(row["event_utc"].replace("Z", "+00:00"))
        result = {"id": row["id"], "event_utc": moment.isoformat()}
        for column, zone in zones.items():
            result[column] = moment.astimezone(zone).date().isoformat()
        print(result)

Для примера файл выглядит так:

id,event_utc
L-101,2026-10-05T02:30:00Z
L-102,2026-10-05T20:30:00Z
L-103,2026-10-05T22:30:00Z

Ожидаемый результат — даты из таблицы выше. Если ваша выгрузка не содержит UTC или смещение вида +03:00, сначала уточните контракт данных у владельца системы. Простое прибавление трёх часов к неизвестной строке может закрепить исходную ошибку.

Что должно остаться в рабочей таблице

Не перезаписывайте исходные значения. Добавьте новые колонки:

Такой набор позволяет пересобрать день по одному правилу и одновременно объяснить, почему интерфейс показывает другую дату. Он особенно полезен на границе месяца: лид 31 октября в одной системе может стать лидом 1 ноября в другой.

Как отличить часовой пояс от другой причины

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

Если ID отсутствует в одной системе, проверяйте доставку события, работу формы и связь идентификаторов. Совпавший момент при отнесении рекламной конверсии к дате более раннего клика указывает на правило атрибуции. Если расхождение меняется на час в разные сезоны, проверьте, храните ли вы название зоны IANA; фиксированное смещение UTC−8 не описывает переход на летнее время в регионах, где он есть.

После нормализации времени продолжите сверку по инструкции «Почему GA4, рекламный кабинет и CRM показывают разные результаты»: там разобраны определения конверсии, даты клика и события, атрибуция и идентификаторы. Когда одинаковый период и состав лидов подтверждены, пересчитайте CPL на той же базе.

Критерий готовности

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

Источники

• Источник 1
• Источник 2
• Источник 3
• Источник 4
• Источник 5

Материал подготовлен редакцией WiseLab с помощью AI. Источники и фактические утверждения проверены при подготовке.