Нормализация валют и часовых поясов в рекламных отчётах

Редакция mevrica

Аналитика4 мин чтения

Обновлено 1 августа 2026 г.

Два кабинета могут показывать правильные данные и при этом не совпадать за «вчера». Причина — разные границы суток, валюта учёта и момент обновления статуса. Нормализация не означает переписать все значения в рубли и московское время. Она означает сохранить исходные данные и построить воспроизводимый слой сравнения по одному правилу.

Базовая модель

У каждой суммы храните amount_minor, currency и occurred_at. У каждого события — исходное время с зоной, UTC-время, время получения и бизнес-день отчёта. Любой пересчёт должен иметь rate, rate_source и rate_date.

Четыре времени одного события

• occurred_at — когда действие фактически произошло
• received_at — когда система получила уведомление
• decided_at — когда изменился коммерческий статус
• reporting_date — к какому бизнес-дню событие отнесено

Для клика occurred_at и received_at почти совпадают, а approved может прийти через дни. Если выручку группировать по decided_at, старые когорты попадут в сегодняшний отчёт. Для экономики привлечения нужен также разрез по дате исходного клика.

Хранение UTC не отменяет локальное время

UTC удобен для соединения систем и сортировки. Но суточный бизнес-отчёт может закрываться в Europe/Moscow, America/Sao_Paulo или зоне программы. Храните идентификатор IANA, а не только смещение +03:00: некоторые регионы меняют правила и сезонное время. Историческое преобразование должно использовать зону на дату события.

День без 24 часов

При переходе на летнее или зимнее время локальные сутки могут быть короче или длиннее. Отчёт с фильтром «00:00–24:00 плюс фиксированное смещение» рискует потерять или дважды включить час. Безопаснее строить локальные границы даты, переводить обе в UTC и выбирать полуинтервал start <= occurred_at < end.

Модель денег

Сумма 19,99 хранится как 1999 минимальных единиц и код валюты. Для валют без двух десятичных знаков правило берут из валютного справочника. Float не используют для финансовой сверки. Пересчитанная сумма не заменяет исходную.

Три разных курса

Курс операции

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

Управленческий курс

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

Договорный курс

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

Рассчитанный пример

Источник списал 1 000 EUR. Управленческий курс на дату расхода — 95 RUB/EUR, поэтому нормализованный расход равен 95 000 рублей. Партнёрка начислила 1 300 USD по договорному курсу 88 RUB/USD — 114 400 рублей. Управленческая прибыль равна 19 400 рублей, ROI — около 20,4%. Если применить сегодняшний курс к обоим потокам, цифра изменится без изменения кампании. Поэтому отчёт обязан показывать использованные курсы.

Поиск ложного расхождения

1. Сравнить исходные валюты и минимальные единицы.
2. Уточнить часовой пояс каждого кабинета.
3. Построить один UTC-интервал и повторить выгрузку.
4. Разделить occurred_at и decided_at.
5. Проверить задержанные статусы после закрытия дня.
6. Только затем искать потерянные события по ID.

Закрытие периода

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

Вывод

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