MTD — сравнение «по то же число»

28 сентября 2026 · ~13 мин чтения

MTD — сравнение «по то же число»

MTD (month-to-date, «с начала месяца по сегодня») — это показатель, накопленный с первого числа текущего месяца до последнего полного дня. Сравнивать его честно можно только с таким же отрезком прошлого периода («август по 26-е против сентября по 26-е») или через темп в день, а не с целым прошлым месяцем.

История

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

• Бухгалтерия и розница, XIX–XX век. Как только компании начали закрывать книги по месяцам и кварталам, у управляющих возник вопрос: «как мы идём внутри месяца?». В американской розничной торговле уже в первой половине XX века были распространены сводки «sales to date» — продажи с начала периода. Производные термины YTD (year-to-date, с начала года), QTD (quarter-to-date) и MTD закрепились в деловом английском примерно в середине века. Точной даты первого употребления я не знаю: поищи в Google Books Ngram Viewer запросы «month-to-date» и «year-to-date».
• Розница и like-for-like. Британские ритейлеры (Tesco, Marks & Spencer и другие) сделали популярным показатель like-for-like sales (сопоставимые продажи): сравнивают только магазины, которые работали и в прошлом, и в текущем периоде. В США то же самое называется same-store sales или comparable sales («comps»). Идея та же, что у MTD: честное сравнение требует одинаковой базы. Разница в том, что MTD выравнивает время, а like-for-like выравнивает состав объектов.
• Эпоха BI, 1990–2010-е. В OLAP-кубах (многомерные хранилища для аналитики) и BI-инструментах вроде Microsoft Analysis Services, Power BI, Tableau и Looker MTD стал встроенной функцией. В языке DAX (Power BI) есть готовые TOTALMTD, DATESMTD и SAMEPERIODLASTYEAR, а в MDX (язык запросов к OLAP) — MTD() и PeriodsToDate(). С этого момента MTD — уже не «хитрость аналитика», а кнопка в интерфейсе.
• Сегодня. MTD есть почти в любом дашборде продаж, маркетинга и колл-центра. Грабли у него всё те же: люди продолжают сравнивать «сентябрь по 26-е» с «августом целиком» и пугаются падения на 16%, которого не было.

Что это такое

У любого бизнес-показателя, который накапливается во времени (выручка, заявки, звонки, переводы), есть неприятное свойство: пока период не закончился, его сумма всегда меньше, чем у завершённого периода. 26 сентября выручка «за сентябрь» почти наверняка ниже выручки «за август»: в сентябре прошло 26 дней, а в августе все 31. Это не падение, это арифметика.

MTD решает задачу в два шага.

1. Фиксируем окно. Текущий период — с 1-го числа по последний полный день (обычно вчера: сегодняшние данные неполные).
2. Выбираем честную базу для сравнения. Их обычно три:
   - Тот же отрезок прошлого месяца («август по 26-е»). Самый прямой вариант: одинаковое число дней и одинаковая фаза месяца.
   - Темп в день (run rate). Делим сумму на число дней в окне и сравниваем «переводов в день» с «переводов в день» базы. Так можно сравнивать даже окна разной длины.
   - Тот же отрезок прошлого года (YoY MTD), если у бизнеса сильная сезонность.

Рядом с MTD есть несколько похожих понятий, которые легко спутать.

• MTD vs полный месяц. Полный месяц — завершённый период, MTD — незавершённый. Сравнивать их в лоб нельзя, только через темп или через прогноз на полный месяц.
• MTD vs rolling 30 days (скользящие 30 дней). «Последние 30 дней» — окно, которое всегда одной длины и не привязано к календарю. Для трендов оно удобнее, но плохо совпадает с тем, как бизнес получает деньги и отчитывается: счета, планы и бонусы живут по календарным месяцам.
• MTD vs run rate (темп). MTD — это сумма, run rate — скорость. «196 переводов с начала месяца» — MTD. «7,5 перевода в день» — run rate. Хороший отчёт показывает оба.
• MTD vs like-for-like. MTD выравнивает время, like-for-like выравнивает состав. На практике нужны оба: если в августе у колл-центра было 90 проектов, а в сентябре 120, сравнение сумм «по то же число» всё равно смешивает эффект роста портфеля с эффектом качества работы.
• MTD vs forecast (прогноз на месяц). Прогноз — это MTD плюс оценка оставшихся дней. Простейший вариант: темп в день × дней в месяце. Это уже модель, а не факт, и в отчёте её стоит явно подписывать.

Аналогии из жизни

Марафон и промежуточная отсечка. Бегун на 26-м километре не сравнивает своё время с финишным временем прошлого года: он сравнивает его с отсечкой на 26-м км прошлой гонки или смотрит на темп «минут на километр». Это ровно MTD и run rate.
Где ломается: трасса марафона каждый год одна и та же, а месяцы разные. В одном 31 день, в другом 28, в одном четыре выходных, в другом пять, где-то праздники. Отсечка «на 26-м км» всегда значит одно и то же, а «26-е число» — нет: 26 августа 2026 года — среда, 26 сентября — суббота.

Кастрюля супа и дегустация. Повар пробует суп на середине готовки и понимает, куда всё идёт, не дожидаясь конца. Промежуточный замер позволяет вмешаться вовремя.
Где ломается: суп к концу не меняется скачком, а многие бизнес-показатели меняются. В B2B последняя неделя месяца может приносить треть выручки (менеджеры «закрывают план»), а в рознице пик приходится на выходные после зарплаты. Если процесс неравномерен внутри месяца, линейная экстраполяция (прогноз по прямой) MTD будет систематически врать.

Счётчик воды. Ты смотришь на счётчик 15-го числа и видишь 6 кубов. В прошлом месяце за весь месяц было 10. Паники нет: ты понимаешь, что к концу месяца выйдет около 12, то есть чуть больше обычного.
Где ломается: в этой аналогии ты сам знаешь, что было в прошлом месяце к 15-му. Аналитику часто этого не дают: в старых отчётах хранятся только итоги месяцев, а не дневная разбивка. Без дневных данных честного MTD-сравнения не построить, остаётся только темп.

Как это работает

Разберём на примере, близком к вчерашней задаче. Есть таблица событий (переводов звонка застройщику), у каждого события есть дата.

Шаг 1. Определить «сегодня» и последний полный день. Данные за текущий день неполные: если отчёт строится в 11:00, в нём половина дня. Поэтому окно заканчивается вчерашним числом. Во вчерашнем отчёте это было явно зафиксировано в полях последний_день: 2026-09-26 и сегодняшний_день_исключён: true.

Шаг 2. Построить текущее окно.

текущее = [2026-09-01 .. 2026-09-26]   # 26 дней

Шаг 3. Построить базу «по тому же числу».

база = [2026-08-01 .. 2026-08-26]      # тоже 26 дней

Здесь есть подводный камень. Если сегодня 31 марта, «февраль по 30-е» не существует. Обычное правило: обрезать базу до последнего дня базового месяца (февраль по 28/29-е) и сравнивать через темп в день, чтобы разная длина окна не искажала картину.

Шаг 4. Посчитать суммы и темпы.

переводов_в_день = переводы / дней_в_окне
текущее: 196 / 26 = 7.5
база:    242 / 26 = 9.3
дельта:  -1.8 в день, -19.4%

Шаг 5. Параллельно посчитать базу «полный прошлый месяц» в темпе. Август целиком: 31 день. Это страховка: если «август по 26-е» сам был аномальным (например, в конце августа случился всплеск), полный месяц покажет это расхождение.

Шаг 6. Разложить дельту на причины (bridge, «мост»). Сама по себе дельта −1,8 в день ничего не объясняет. Классический приём — «мост» (waterfall, водопад): делим объекты на группы и считаем вклад каждой.

выбывшие   (были в базе, нет сейчас)   -0.9
упавшие    (есть оба, стало меньше)    -1.2
прочие     (мелкие, без статуса)       -2.8
новые      (не было в базе, есть сейчас) +2.3
выросшие   (есть оба, стало больше)    +0.8
                                    = -1.8

Сумма вкладов обязана сходиться с общей дельтой. Если не сходится, где-то ошибка в группировке.

Шаг 7. Показать тренд по одинаковым отрезкам. «1–26 число каждого месяца» за полгода: так видно, падение случилось в этом месяце или тянется давно. Во вчерашних данных именно так выяснилось, что по одному региону в сентябре падения нет, а настоящее падение было в июне и августе.

Ещё два технических нюанса, о которые часто спотыкаются.

• Часовые пояса. Если события хранятся в UTC, а бизнес живёт по Москве (UTC+3), то события с 21:00 до 24:00 по UTC уже принадлежат следующему московскому дню. Граница окна должна считаться в бизнес-часовом поясе.
• Опоздавшие данные (late-arriving data). Часть событий доезжает в базу с задержкой: статус «целевой» застройщик проставляет через день или два. Тогда последние дни MTD всегда занижены, а база прошлого месяца уже «дозрела». Лечится сдвигом окна на день или два назад или отдельной пометкой «данные за последние N дней неполные».

Где встречается в обычной жизни

• Банковское приложение. Экран «Траты за сентябрь» с графиком «в прошлом месяце к этому дню вы потратили…» — это MTD против базы по тому же числу. У Тинькофф/Т-Банка и других банков похожие виджеты аналитики расходов.
• Мобильный оператор. «Израсходовано 18 из 30 ГБ, до конца периода 9 дней» — MTD плюс неявный прогноз по темпу.
• Фитнес-трекер. «В этом месяце 142 км, в прошлом к этой дате было 120» — Strava и подобные приложения показывают ровно такое сравнение.
• Зарплата продавца. Когда в магазине висит табличка «план месяца выполнен на 68%, а прошло 70% месяца», это сравнение MTD с линейным планом.
• Коммунальные счётчики и кэшбэк-лимиты. «Осталось 1 200 ₽ кэшбэка до лимита» — это тоже MTD-счётчик.

Где встречается в IT и бизнесе

• Ежедневные отчёты продаж и колл-центров. Нужно, когда руководителю важно реагировать внутри месяца, а не узнавать о провале 1-го числа следующего. Типичный вопрос: «идём ли мы в план» и «что отвалилось».
• Финансовый контроль и бюджеты. «Budget vs actual MTD»: сколько потратили на рекламу к сегодняшнему дню против запланированной доли бюджета. Нужно, когда есть риск перерасхода, например в контекстной рекламе.
• SaaS-метрики. MRR (ежемесячная регулярная выручка) MTD, новые подписки MTD, отток MTD. Нужно для прогноза закрытия месяца и для раннего обнаружения проблем в воронке.
• Облачные расходы. В AWS Cost Explorer, Google Cloud Billing и у других провайдеров есть «month-to-date costs» и «forecasted month-end costs». Нужно, когда счёт за облако может неожиданно вырасти.
• Мотивация и бонусы. Продажникам и операторам показывают MTD-выполнение плана, потому что бонус обычно считается по календарному месяцу.

Кто пользуется

• Microsoft Power BI и Analysis Services — функции TOTALMTD, DATESMTD, SAMEPERIODLASTYEAR в DAX. Power BI, по данным Microsoft, используют сотни тысяч организаций; точную актуальную цифру не знаю.
• Tableau, Looker, Metabase, Superset — MTD реализуется через фильтры по дате относительно сегодняшнего дня («Month to date» в относительных фильтрах Tableau и Looker).
• Публичные ритейлеры (Walmart, Target, X5 Group, Tesco) отчитываются сопоставимыми продажами (comparable/like-for-like), и аналитики рынка следят за этими цифрами сильнее, чем за общей выручкой.
• AWS, Google Cloud, Azure показывают клиентам MTD-стоимость и прогноз на конец месяца прямо в биллинге.
• Любой колл-центр и отдел продаж с ежедневной отчётностью. Во вчерашней задаче MTD считался по двум регионам и разрезам поставщиков, с базой «по тому же числу» и дополнительной базой «прошлый месяц целиком» в темпе.

Альтернативы и конкуренты

• Rolling window (скользящее окно: 7, 28 или 30 дней).
  Плюсы: окно всегда одной длины, нет «проседания» в начале месяца, удобно для графиков трендов.
  Минусы: не совпадает с календарём планов и счетов, трудно объяснить бизнесу «почему 28 дней».
• Week-over-week и day-of-week-aligned (выровненные по дню недели). Сравнивают «эту среду с прошлой средой» или 4 недели с 4 неделями.
  Плюсы: убирает перекос выходных, отлично подходит для бизнеса с сильной недельной сезонностью (рестораны, розница, колл-центры с разным трафиком по выходным).
  Минусы: не совпадает с месяцами; каждые несколько лет в году 53 недели, что ломает годовые сравнения.
• Прогноз на полный месяц (forecast).
  Плюсы: сразу отвечает на вопрос руководителя «сколько будет в конце месяца».
  Минусы: это модель, а не факт; линейный прогноз ошибается, если внутри месяца есть пики.
• Сравнение только закрытых периодов.
  Плюсы: никаких искажений и опоздавших данных, цифры окончательные.
  Минусы: обратная связь приходит через месяц, когда исправлять уже поздно.

Когда НЕ стоит использовать

• В первые дни месяца. 2-го числа MTD строится на одном дне, и один выходной или праздник даёт ±50% «изменения». Потому что маленькая выборка: шум доминирует над сигналом. Лучше показывать скользящее окно или прошлый месяц, а MTD включать примерно с 7–10-го числа.
• Когда процесс сильно неравномерен внутри месяца. Если 40% выручки приходит в последнюю неделю (B2B-закрытие сделок, выплаты по графику), MTD на 20-е будет стабильно выглядеть «плохо». Потому что сравнивать нужно с той же фазой, а не с линейной долей; тут нужна база «прошлый месяц по то же число» строго, без темпа, или сезонный профиль.
• Когда состав объектов сильно поменялся. Если в портфеле половина проектов новые, итоговое MTD-сравнение смешивает «стали работать хуже» и «работаем с другими объектами». Потому что MTD выравнивает только время; тут нужен мост по группам или like-for-like.

Связанные понятия

• YTD / QTD — то же самое, что MTD, но с начала года или квартала.
• Run rate (темп) — показатель в пересчёте на единицу времени (в день, в месяц, в год); основа для честного сравнения окон разной длины.
• Like-for-like / same-store sales — сравнение только тех объектов, что были в обоих периодах.
• Waterfall / bridge (мост) — разложение общей дельты на вклады групп или факторов, сумма которых сходится с итогом.
• Сезонность — повторяющиеся колебания по дню недели, месяцу, году; причина, по которой нужны выровненные сравнения.
• Late-arriving data — данные, которые доезжают в хранилище с задержкой и занижают свежие дни.

Литература и источники

• Документация Microsoft по DAX: функции TOTALMTD, DATESMTD, SAMEPERIODLASTYEAR — https://learn.microsoft.com/dax/ (en).
• Ральф Кимбалл, Марджи Росс, «The Data Warehouse Toolkit», 3-е издание, 2013 (en; есть старые русские переводы) — классика по измерениям «дата» и календарным таблицам, на которых строятся MTD-отчёты.
• Статья «Same-store sales» в английской Википедии — https://en.wikipedia.org/wiki/Same-store_sales.
• Статья «Year-to-date» в английской Википедии — https://en.wikipedia.org/wiki/Year-to-date.
• Кол Нуссбаумер Нафлик, «Storytelling with Data», 2015 (en; есть русский перевод «Сторителлинг на языке данных») — про то, как подписывать сравнения, чтобы их не понимали превратно.
• Для практики: поищи в Google «time intelligence DAX patterns» (сайт SQLBI, Марко Руссо и Альберто Феррари), там разобраны все краевые случаи вроде «31 марта против февраля».

Где встретилось у меня

Вчера генерировались текстовые разборы для отчёта колл-центра: почему упали переводы звонков застройщикам в Москве и Петербурге, в целом и по двум поставщикам заявок. Все сравнения строились как «сентябрь по 26-е против августа по тому же числу» в темпе на день, с «мостом» по выбывшим, упавшим, новым и выросшим объектам и полугодовым трендом по одинаковым отрезкам месяца.

Краткое резюме

• MTD — сумма с начала месяца по последний полный день. Сравнивать её с полным прошлым месяцем в лоб нельзя.
• Честные базы: тот же отрезок прошлого месяца («по тому же числу»), темп в день или тот же отрезок прошлого года.
• Сегодняшний день исключается, границы считаются в бизнес-часовом поясе, опоздавшие данные помечаются.
• Общую дельту полезно разложить мостом по группам, а тренд показывать по одинаковым отрезкам месяцев.
• MTD выравнивает только время: для изменения состава нужен like-for-like, для неравномерных внутри месяца процессов — сезонный профиль.