Часовые пояса в отчёте: куда пропала продажа
Как сверить продажу на границе суток: UTC, часовой пояс отчёта, время создания и оплаты, дата загрузки и одинаковые интервалы сравнения.
Продажа в 00:30 по Москве произошла в 21:30 UTC предыдущего дня. Если CRM и отчёт используют разные пояса, обе системы могут правильно показывать одну операцию в разных сутках. Искать пропавшую продажу стоит с исходного времени.
В маркетинговой аналитике это особенно заметно при ежедневных сверках. Я бы сначала сравнивал конкретный ID, а уже потом суммы за день. Иначе небольшое смещение границ легко принять за сбой интеграции и начать менять работающую передачу данных.
У операции несколько времён
Запишите, что обозначает каждая колонка: время визита, отправки формы, создания записи, оплаты, подтверждения менеджером или загрузки в аналитику. Даже в одном часовом поясе эти моменты не обязаны совпадать. Заголовок «дата продажи» без определения скрывает решение, от которого зависит весь отчёт.
| Момент | UTC | Москва | Что изменилось |
|---|---|---|---|
| Создание заявки | 17 октября, 21:20 | 18 октября, 00:20 | Другая календарная дата |
| Оплата | 17 октября, 21:30 | 18 октября, 00:30 | Тот же ID, позже создание |
| Загрузка в отчёт | 18 октября, 06:00 | 18 октября, 09:00 | Время обработки, не момент покупки |
Настройку отчёта нужно прочитать
Справка GA4 объясняет, что события относятся к дню в выбранном часовом поясе ресурса. Изменение настройки действует вперёд и может создать заметный сдвиг в данных. Поэтому менять пояс ради совпадения одной выгрузки — плохой первый шаг.
Проверьте пояс рекламного кабинета, ресурса аналитики и CRM отдельно. У выгрузки может быть собственный формат времени. Строка без смещения вроде «2026-10-18 00:30» не даёт понять момент однозначно. Попросите сохранять исходный timestamp и указание пояса, а преобразование выполнять в отдельном вычисляемом поле.
Сверяйте одинаковый промежуток
Для дневного отчёта за 18 октября по Москве используйте интервал от начала 18 октября до начала 19 октября в этом поясе. Удобное техническое правило — включать левую границу и исключать правую. Тогда операция ровно в полночь не попадёт сразу в два соседних дня.
Если выгрузка хранит UTC, переведите обе границы интервала в UTC, а не вычитайте часы вручную только у отдельных строк. Для регионов с сезонной сменой времени используйте именованный пояс и библиотеку дат. Фиксированный сдвиг, подходящий одному месяцу, может оказаться неверным для другого.
Порядок разбирательства
- Выберите конкретный ID операции, который есть хотя бы в одной системе.
- Соберите все относящиеся к нему моменты с исходным форматом и поясом.
- Приведите их к общему поясу в отдельной колонке.
- Проверьте одинаковое определение события и границы отчётов.
- Только после этого ищите отсутствующую доставку или лишнюю запись.
Рядом с итогом сохраните пояс, правило даты и момент выгрузки. Поздние продажи могут ещё дополнять прошлый период; это уже задержка конверсий. Лишние записи разбираются по правилу дедупликации, а названия полей — по контракту метрики. Одна понятная временная шкала часто экономит больше работы, чем новая интеграция.