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

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

В проектах с BI-отчётностью я работал с контуром, где данные проходили путь от операционных систем и общей базы через API и выгрузки к ручной обработке, отчётам и справкам. При такой схеме итог зависит не только от SQL-запроса. На него влияют состояние источника, дата среза, справочники, правила исключения, ручные преобразования и момент обновления каждого звена.

Поэтому расхождение лучше расследовать не как спор двух чисел, а как сравнение двух воспроизводимых расчётов. В этой статье разберу, из каких слоёв состоит показатель, как локализовать различие и что изменить в аналитическом контуре, чтобы одинаковая бизнес-метрика не реализовывалась заново в каждом отчёте.

Показатель - это не формула

Запись вида Количество = COUNT(DISTINCT object_id) выглядит однозначно, но не отвечает на основные вопросы:

• какие объекты входят в исходное множество;

• какой идентификатор считается уникальным;

• на каком уровне детализации выполняется расчёт;

• какая дата связывает объект с периодом;

• на какой момент зафиксировано состояние данных;

• какие статусы и категории исключаются;

• как учитываются поздние записи и исправления;

• какая версия определения применяется;

• какие ограничения доступа изменяют доступное множество.

Для себя я рассматриваю значение показателя как функцию от нескольких параметров:

M = F(D, P, G, T, C, I, R, V)

Где:

• D - версия или срез набора данных;

• P - популяция, то есть правила включения записей;

• G - гранулярность расчёта;

• T - временная семантика;

• C - дата и время отсечения данных;

• I - правила идентификации сущностей;

• R - контекст доступа пользователя;

• V - версия определения показателя.

Формула агрегации находится внутри F, но сама по себе не определяет результат. Если хотя бы один аргумент различается, ожидать равенства двух значений нельзя.

Из этого следует полезный практический приём: при сверке отчётов сначала сравнивать не цифры, а сигнатуры расчёта. Сигнатура - это компактный набор параметров, достаточный для воспроизведения метрики. Такой термин я использую как рабочее обозначение, а не как отдельный отраслевой стандарт.

Например:

metric: active_entities
version: 3
entity: entity_id
population: completed_operations
grain: entity_day
event_time: completed_at
timezone: agreed_business_timezone
cutoff: daily_publication_time
late_data_policy: restate_open_period
aggregation: count_distinct(entity_id)
null_policy: exclude_missing_entity_id
access_scope: user_role
owner: analytics_team
effective_from: definition_approval_date

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

Семь слоёв, на которых расходятся показатели

На практике причины удобно группировать по слоям. Это помогает не проверять весь контур сразу.

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

Одинаковое название может скрывать разные события

Предположим, в двух отчётах есть показатель «Количество завершённых объектов за месяц».

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

Можно сформулировать ещё три технически корректных варианта:

1. Количество уникальных объектов, хотя бы раз находившихся в статусе за период.

2. Количество событий перехода в статус, включая повторные переходы.

3. Количество объектов в статусе на отчётную дату.

Это не три способа посчитать одну метрику. Это три разные метрики, которым дали одно название.

В BI-проекте с данными разных направлений именно границы показателя требовали отдельного согласования. Наличие поля или готового итога в источнике ещё не означало, что его можно без изменений использовать для сравнения подразделений. Нужно было определить объект, состояние, период, исключения и возможность одинаково применить правило ко всем участникам сравнения.

Поэтому в разборе расхождения первым вопросом должен быть не «какая формула используется?», а «какое событие или состояние делает объект частью расчёта?».

Гранулярность и fan-out при объединениях

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

Допустим, есть таблица операций и таблица категорий. У одной операции может быть несколько категорий. После объединения сумма операций повторится по числу связанных категорий. COUNT(DISTINCT operation_id) может скрыть дублирование количества, но сумма, среднее или знаменатель относительного показателя останутся искажёнными.

Такое размножение строк называют fan-out. Его опасность в том, что запрос выполняется без ошибки, а отдельные разрезы могут выглядеть правдоподобно.

Перед объединением я бы фиксировал гранулярность каждого набора одной фразой:

• одна строка на операцию;

• одна строка на операцию и категорию;

• одна строка на объект и день;

• одна строка на подразделение и месяц.

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

Полезная проверка выглядит проще самого отчёта:

select
    count(*) as rows_total,
    count(distinct operation_id) as operations_total,
    count(*) - count(distinct operation_id) as duplicated_rows
from enriched_operations;

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

Время события, время загрузки и время знания

В периодическом отчёте обычно есть не одна дата.

• event_time - когда событие произошло в предметной области;

• ingested_at - когда запись поступила в аналитический контур;

• processed_at - когда её обработала конкретная задача;

• valid_from и valid_to - когда значение считалось действующим в предметной области;

• recorded_at - когда система узнала об этом значении.

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

В потоковой обработке различие между event time и processing time является отдельной частью модели вычислений. События могут приходить не по порядку, а водяные знаки и политика допустимого опоздания определяют, когда окно считается достаточно полным. Это подробно описано в документации Apache Flink о event time, processing time и late events. Даже если отчёт строится пакетно, а не в стриме, проблема остаётся той же: период нельзя считать окончательно сформированным, пока не определено, какие опоздавшие данные ещё будут приняты.

Для управляемой метрики недостаточно поля date. Нужны ответы на четыре вопроса:

1. По какой дате запись относится к периоду?

2. В каком часовом поясе определяется граница суток?

3. На какой момент данные считаются опубликованными?

4. Может ли закрытый период измениться после публикации?

Дата отсечения особенно важна для сверки. Значение «за август» без уточнения «по состоянию на 2 сентября 08:00» не является полностью воспроизводимым, если источник продолжает принимать исправления.

Текущее состояние не восстанавливает прошлое

Операционная система часто хранит актуальное состояние объекта. Для текущей работы этого достаточно, но аналитический отчёт может требовать ответ на вопрос: что было известно на конец прошлого месяца?

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

Здесь важно различать два запроса:

• показать прошлые события в сегодняшней классификации;

• восстановить картину в той классификации, которая действовала тогда.

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

Технически это приводит к хранению истории изменений и соединению «на момент времени». Для записи события выбирается версия справочника, интервал действия которой включает дату события. Но даже такая модель не решает вопрос автоматически: нужно определить, используется дата фактического действия или дата, когда изменение было зарегистрировано.

Фактически появляются две временные оси:

• действительность в предметной области;

• знание системы об этой действительности.

Это полезная модель для исправлений задним числом. Она позволяет воспроизвести как актуально пересчитанную историю, так и значение, которое пользователь видел в момент принятия решения.

Поздние данные требуют политики, а не ручного объяснения

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

Полный перерасчёт истории

Новая информация применяется ко всему сопоставимому периоду. Пользователь всегда видит наиболее актуальную версию прошлого.

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

Фиксированный опубликованный срез

После закрытия периода значение не меняется. Поздние данные переходят в корректирующий период или отдельную поправку.

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

Управляемое окно пересмотра

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

Ни одна политика не является правильной для всех показателей. Ошибка появляется, когда два отчёта неявно используют разные политики. Тогда один показывает уточнённую историю, второй - первоначально опубликованное значение, а пользователю это выглядит как сбой.

В паспорте метрики я бы хранил не только расписание обновления, но и restatement_policy: можно ли пересчитывать закрытые периоды, как долго они остаются открытыми и как обозначается разрыв методики.

Уникальность зависит от модели идентичности

COUNT(DISTINCT user_id) выглядит надёжнее обычного количества строк, но результат определяется тем, что именно находится в user_id.

В мобильном продукте один человек может последовательно появиться как анонимная установка, устройство, учётная запись и авторизованный профиль. После повторной установки изменится идентификатор приложения, после входа может объединиться история нескольких устройств. Если один отчёт считает устройства, другой - учётные записи, а третий применяет объединение профилей, название «уникальные пользователи» не делает значения сопоставимыми.

При проектировании аналитики мобильного приложения я закладывал не только DAU, WAU и MAU, но и события ключевых действий, успешные и ошибочные сценарии, версии приложения, устройства и операционные системы. Уже на этапе плана измерений важно было определить, какое событие подтверждает действие и какой идентификатор доступен в этот момент. Например, отправка события «успех» до ответа сервера создаёт аналитический факт, которого ещё нет в бизнес-процессе. Повторное нажатие может создать несколько событий для одного действия.

Поэтому для метрик уникальности нужно зафиксировать:

• сущность: человек, аккаунт, устройство, сессия или установка;

• главный ключ и резервные ключи;

• правила объединения и разделения профилей;

• возможность изменения связи задним числом;

• момент, с которого анонимная активность связывается с аккаунтом;

• правила удаления технических и тестовых субъектов.

Без модели идентичности спор о правильном distinct count не имеет однозначного ответа.

Не все показатели можно складывать

Даже при одинаковом наборе строк два отчёта могут расходиться из-за порядка агрегации.

Например, средняя доля по подразделениям не равна общей доле по организации:

AVG(numerator_i / denominator_i) != SUM(numerator_i) / SUM(denominator_i)

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

Подобная проблема возникает с уникальными пользователями. Сумма дневных DAU не равна числу уникальных пользователей за месяц, потому что один пользователь может присутствовать в нескольких днях. Нельзя без дополнительного состояния складывать медианы, процентили и distinct count по произвольным разрезам.

Для показателя полезно явно определить аддитивность:

• аддитивный - можно суммировать по всем нужным измерениям;

• полуаддитивный - можно суммировать только по части измерений;

• неаддитивный - требуется пересчёт на целевой детализации.

Это свойство должно находиться рядом с определением метрики, а не оставаться знанием автора конкретного дашборда.

Права доступа тоже являются фильтром

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

Один отчёт применяет ограничение строк на уровне модели, другой - заранее агрегирует данные до проверки роли. Один использует текущее подразделение пользователя, другой - подразделение на дату события. В одном контуре записи без сопоставленного владельца скрываются, в другом попадают в общий итог.

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

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

Кэш и свежесть создают временно правильные цифры

В многослойном аналитическом контуре обновление не происходит одновременно. Источник уже изменился, витрина ещё строится, семантическая модель обновлена, а BI-инструмент продолжает показывать кэш предыдущего запроса.

Вместо одной отметки «обновлено» полезно различать:

• максимальное время события в данных;

• время завершения загрузки источника;

• время успешного построения витрины;

• время обновления модели или набора данных;

• время формирования конкретного результата;

• версию кэша.

Пользователю не обязательно показывать всю техническую цепочку. Но для расследования она должна быть доступна. Иначе отчёт с более свежей датой интерфейса может содержать более старый срез данных.

Я бы также отделял свежесть от полноты. Набор может обновиться минуту назад, но получить только часть ожидаемых разделов. Проверка времени загрузки не заменяет контроль числа записей, диапазона дат и наличия всех источников.

Как расследовать расхождение без перебора всех формул

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

Зафиксировать условия сравнения

Для обоих отчётов записываются:

• точный показатель и его отображаемая версия;

• пользовательская роль;

• все фильтры, включая скрытые и значения по умолчанию;

• период и часовой пояс;

• дата отсечения;

• время последнего успешного обновления;

• выбранная детализация;

• ссылка или идентификатор версии отчёта.

Скриншот полезен как свидетельство, но не как описание расчёта. Без перечисленных параметров его часто невозможно воспроизвести.

После фиксации условий область сравнения стоит постепенно уменьшать. Не нужно сразу сопоставлять год по всей организации. Лучше оставить один период, затем одно подразделение, одну категорию, один статус и в итоге несколько конкретных объектов.

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

Сравнить состав, а не только итог

Если отчёт A показывает 100, а отчёт B - 97, разница 3 почти ничего не объясняет. Возможно, в A есть десять дополнительных объектов, а в B - семь других. Нужно сравнить состав.

Общий шаблон сверки можно построить через FULL OUTER JOIN по обезличенному ключу:

with report_a as (
    select entity_key, sum(metric_contribution) as contribution
    from calculation_a
    group by entity_key
),
report_b as (
    select entity_key, sum(metric_contribution) as contribution
    from calculation_b
    group by entity_key
)
select
    coalesce(a.entity_key, b.entity_key) as entity_key,
    case
        when a.entity_key is null then 'only_b'
        when b.entity_key is null then 'only_a'
        when a.contribution <> b.contribution then 'different_contribution'
        else 'same'
    end as reconciliation_status,
    a.contribution as contribution_a,
    b.contribution as contribution_b
from report_a a
full outer join report_b b
    on a.entity_key = b.entity_key;

После этого анализируются три группы: записи только в A, только в B и записи с разным вкладом. Обычно причина становится видна по общему признаку: статусу, дате, источнику, отсутствующему ключу или времени загрузки.

Если показатель не сводится к объектам, сравнение выполняется на минимальной гранулярности, на которой определён его вклад. Для отношения отдельно сверяются числитель и знаменатель. Для distinct count строятся множества идентификаторов. Для снимка состояния сравниваются объект и версия на дату.

Найти точку расхождения в цепочке

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

На каждом переходе проверяются:

• число строк и уникальных ключей;

• минимальная и максимальная дата;

• доля NULL в ключевых полях;

• распределение по статусам;

• число дубликатов на ожидаемой гранулярности;

• время формирования набора;

• версия кода или конфигурации;

• сохранение контрольного итога.

Первый слой, на котором одинаковые входы дают разные контрольные результаты, сужает область расследования.

Для автоматизации этой карты можно использовать lineage. Спецификация OpenLineage описывает связи между заданиями, их запусками и входными и выходными наборами данных. В метаданные также могут входить версия источника кода, схема набора, показатели качества и результаты проверок. Lineage не доказывает, что формула верна, но помогает увидеть путь показателя и определить, какие отчёты затронуты изменением.

Отделить ошибку от различий в определении

Когда точка расхождения найдена, остаётся определить, что именно обнаружено:

1. Дефект данных - потеря, дублирование или неверная запись.

2. Дефект преобразования - ошибочное объединение, фильтр или агрегация.

3. Рассинхронизация - разные срезы, кэш или неполное обновление.

4. Разные определения - оба отчёта реализуют разные бизнес-правила.

5. Допустимое представление - значения должны различаться, но это не объяснено пользователю.

Только первые три пункта обязательно требуют исправления вычисления. В четвёртом случае сначала нужен владелец бизнес-определения. В пятом - переименование показателей, пояснение контекста или запрет некорректного сравнения.

От сверки отчётов к контракту метрики

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

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

Контракт может начинаться как таблица или YAML-файл. Важнее не формат, а возможность однозначно ответить, какая версия использована и кто согласовал изменение.

Для контрактов именно на наборы данных существует Open Data Contract Standard, который предусматривает описание схемы, качества, ролей, SLA и инфраструктуры. Он не заменяет бизнес-определение показателя, но полезен на границе между производителем данных и аналитическим потребителем: изменение поля, допустимых значений или срока доставки становится управляемым изменением, а не сюрпризом в отчёте.

Семантический слой уменьшает число реализаций

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

Например, dbt Semantic Layer централизует определения метрик над моделями данных и выполняет соединения при запросе. В текущей спецификации dbt отдельно задаются простые, накопительные, производные, относительные и конверсионные метрики, фильтры, временное измерение и неаддитивные измерения. Практическая ценность здесь не в конкретном продукте, а в самом принципе: определение метрики покидает отдельный дашборд и становится повторно используемым компонентом. Подробности есть в документации dbt Semantic Layer и описании типов метрик.

Но семантический слой не является автоматическим источником истины. Если в него перенести неоднозначное определение, оно станет централизованно неоднозначным. Он также не исправляет задержки источников, ошибки идентификации и неверную историю справочников.

Поэтому порядок важен:

1. Согласовать смысл и границы.

2. Подготовить канонические сущности и временную модель.

3. Реализовать метрику один раз.

4. Подключить потребителей к общей реализации.

5. Проверять изменения до публикации.

Версионирование: новая формула не должна молча переписывать прошлое

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

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

Для каждой версии нужны как минимум:

• уникальный номер;

• дата вступления в силу;

• причина изменения;

• владелец решения;

• перечень изменённых правил;

• оценка влияния на историю;

• список зависимых отчётов;

• выбранная политика перерасчёта.

Дальше возможны три режима.

Ретроспективное применение

Новая формула применяется ко всей истории, если исходные данные позволяют сопоставимый пересчёт. Предыдущее определение сохраняется в журнале, а дата пересчёта указывается в метаданных.

Перспективное применение

Новая версия действует только с определённой даты. На графике отмечается разрыв методики, потому что значения до и после него нельзя интерпретировать как полностью однородный ряд.

Параллельный переход

Старая и новая версии некоторое время рассчитываются одновременно. Разница анализируется на нескольких периодах и сегментах, после чего новая версия становится основной.

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

Проверки метрики должны выполняться до дашборда

Обычная проверка «запрос выполнился и вернул строки» слишком слабая. Для метрики нужен набор тестов на разных уровнях.

Структурные проверки

• уникальность ключа на заявленной гранулярности;

• отсутствие неожиданных NULL;

• ссылочная целостность со справочниками;

• допустимые значения статусов;

• отсутствие fan-out после обогащения.

Временные проверки

• свежесть каждого источника;

• полнота ожидаемого диапазона дат;

• доля поздних записей;

• изменение закрытого периода после пересчёта;

• корректность границ суток и часового пояса.

Семантические инварианты

• числитель не превышает знаменатель, если это следует из смысла;

• количество завершённых объектов не превышает количество всех объектов соответствующей популяции;

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

• доля находится в допустимом диапазоне;

• детализация сворачивается в опубликованный итог.

Сверка с контрольным расчётом

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

Регрессионная проверка

При изменении контракта новая версия рассчитывается на фиксированном тестовом наборе и на нескольких исторических срезах. Система показывает, какие значения и сегменты изменились. Изменение принимается осознанно, а не обнаруживается после публикации.

Такой процесс можно рассматривать как CI для метрик. Код, контракт, тесты и ожидаемое влияние проходят одну проверку до того, как новая версия станет доступна в отчётах.

Минимальная архитектура согласованных показателей

Для небольшого аналитического контура не обязательно сразу внедрять отдельную платформу управления метриками. Но ответственность слоёв лучше разделить с начала.

Если отдельного семантического инструмента нет, эту структуру можно реализовать в базе и репозитории: канонические представления, версионированные SQL-модели, YAML-паспорта, тесты и таблица публикаций. Важен не бренд технологии, а отсутствие нескольких независимых мест, где показатель получает новый смысл.

Что я бы изменил в работе над BI-контуром

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

Если переносить этот опыт на следующий уровень зрелости, я бы добавил пять элементов.

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

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

Третий - автоматическую сверку вкладов на уровне обезличенных сущностей, а не только общих итогов.

Четвёртый - параллельный расчёт старой и новой версии перед изменением методики.

Пятый - lineage зависимостей, чтобы изменение источника или формулы запускало проверку всех связанных отчётов.

Эти элементы не отменяют согласование с пользователями. Они переводят его результат из переписки и памяти команды в воспроизводимую систему.

Чек-лист разбора расхождения

Перед тем как исправлять один из отчётов, я бы прошёл следующие вопросы:

1. Одинаковый ли бизнес-смысл скрывается за названием?

2. Какое событие или состояние включает объект в расчёт?

3. Совпадают ли популяция и исключения?

4. Одинакова ли минимальная гранулярность?

5. Не размножаются ли строки после JOIN?

6. Какая дата относит запись к периоду?

7. Совпадают ли часовой пояс и границы интервала?

8. На одну ли дату отсечения сформированы значения?

9. Как учитываются поздние записи и исправления?

10. Используется текущий справочник или версия на момент события?

11. Одинаково ли определяется уникальная сущность?

12. Можно ли агрегировать показатель выбранным способом?

13. Совпадает ли контекст прав доступа?

14. Все ли источники обновились полностью?

15. Одинакова ли версия определения метрики?

16. Можно ли получить множества записей только в A и только в B?

17. На каком слое цепочки впервые появляется различие?

18. Является ли расхождение дефектом или допустимым различием смысла?

19. Какие зависимые отчёты затронет исправление?

20. Нужно ли пересчитать историю или отметить разрыв методики?

Итог

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

Поэтому поиск «правильной цифры» стоит заменить сравнением контрактов и множеств данных. Сначала фиксируется контекст, затем находится минимальный расходящийся срез, сравнивается состав записей и определяется первый слой, на котором возникло различие.

Долгосрочное решение состоит не в ещё одной ручной сверке. Общие показатели нужно вынести из отдельных дашбордов в версионированный семантический слой, связать с контрактами данных, тестами качества и lineage зависимостей. Тогда изменение формулы становится управляемым выпуском новой версии, а расхождение - наблюдаемым событием с понятной причиной.

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