Предположим, в аналитике за понедельник 18 обращений, в CRM — 21. Во вторник разница почти обратная. Прежде чем искать потерянные заявки, проверьте, по какому времени каждая система относит событие к дню. Одно и то же обращение около полуночи может попасть в разные календарные даты.
Это не свойство всех CRM и счётчиков: настройки конкретных систем нужно проверять отдельно. Ниже — способ диагностики, который не зависит от названия платформы.
Для учебного примера предположим, что один отчёт использует UTC, а другой — UTC+3. Событие 24 сентября в 22:15 UTC соответствует 25 сентября в 01:15 UTC+3. Если группировать по локальной дате без приведения времени, первая система покажет его 24-го, вторая — 25-го.
24.09, 20:59 UTC — та же отметка 24.09, 23:59 UTC+3. Календарный день в двух отчётах совпадает.
24.09, 21:00 UTC — та же отметка 25.09, 00:00 UTC+3. Календарный день в двух отчётах различается.
24.09, 23:10 UTC — та же отметка 25.09, 02:10 UTC+3. Календарный день в двух отчётах различается.
25.09, 00:10 UTC — та же отметка 25.09, 03:10 UTC+3. Календарный день в двух отчётах совпадает.
Числа здесь служат примером преобразования, а не описанием настроек вашего аккаунта. Для реальной проверки нужны исходные идентификаторы событий, время и указание часового пояса.
Даже после приведения часовых поясов даты могут различаться. Клиент отправил форму в 23:58, а интеграция создала сделку в 00:02. Это разные моменты. Если отчёт сравнивает отправку формы с созданием CRM-записи, часть расхождения останется закономерной.
Запишите для контрольной заявки четыре отметки, если они доступны: действие пользователя, приём на стороне сайта, отправка в интеграцию, создание записи. Не подменяйте отсутствующее время известным. Для каждой отметки укажите происхождение и смысл.
Проверьте также, не было ли ручного изменения даты и повторной доставки. Совпадение телефона ещё не доказывает, что вы смотрите на одно событие; надёжнее использовать идентификатор обращения и дополнительные признаки.
В нём достаточно пяти полей: какое событие группируем, какое время берём, в каком поясе храним, в каком показываем, как трактуем границы периода. Формулировка «за понедельник» должна означать точный интервал, понятный аналитикам обеих сторон.
Для бизнеса с несколькими регионами отдельно решите, нужен ли единый управленческий день или локальные дни филиалов. Единое время удобно для общего отчёта, локальное — для оценки смены и скорости ответа. Выбор определяется вопросом, а не привычкой одного сотрудника.
Смена правила должна иметь дату. После обновления настроек исторический график может пересчитаться. Без отметки о смене правила такой сдвиг легко принять за исправление потерь или появление новых заявок.
Месячные суммы способны совпасть, даже если дневные распределения неверны. Для приёмки возьмите контрольные события до и после полуночи, на границе месяца и при задержанной доставке. Если бизнес работает в регионах с сезонным переводом часов, добавьте соответствующие переходы по правилам выбранного региона; не рассчитывайте их произвольным постоянным сдвигом.
Ожидаемый результат формулируется заранее: идентичные обращения должны попасть в одинаковый интервал при одинаковом определении времени. Отдельно допустима разница между датой события и датой записи, если она явно отражена в отчёте.
Агентство Эйч рассматривает такие проверки как часть диагностики расхождений в маркетинговых данных. Если после выравнивания времени остаются лишние или недостающие записи, продолжайте разбор по идентификаторам. Часовой пояс объясняет сдвиг даты, но не доказывает, что доставка обращений работает без потерь.