Иногда желание увеличить количество источников информации заводит процесс в тупик. Представим совещание, показывают два отчёта. В обоих есть строка «Новые клиенты за месяц», но числа разные. Ошибка или сначала стоит спросить: что именно посчитала каждая система?   Как это могло получиться. В октябре десять организаций впервые заключили договор с компанией. Семь из них впервые заплатили в октябре, три - в ноябре. Допустим, других организаций, впервые заключивших договор или впервые заплативших, в эти месяцы не было. Система продаж считает клиента новым по дате первого договора, платёжный отчёт - по дате первой оплаты. Поэтому за октябрь в одном отчёте десять клиентов, в другом - семь.   Оба расчёта верны: они считают разные события. Ошибка - выдать их за один показатель или «исправить» отчёт продаж, убрав клиентов, которые ещё не оплатили договор.   Начать стоит с записей, попавших только в один отчёт. В примере их три: договор заключён в октябре, оплата поступила позже. Мы нашли различие правил, а не неисправность обмена.   Например, в прежней версии веб-аналитики от Google, Universal Analytics, подпись «Users» в большинстве отчётов означала общее число пользователей. В Google Analytics 4 под той же подписью показывают уже число активных пользователей. Название совпадает, а правила подсчёта различаются, то есть для сравнения нужно учитывать и настройки.   Если правила подсчёта одинаковые, проверьте, за какой период собран каждый отчёт и когда обновлены данные. Затем - какие клиенты и операции в него вошли, что исключили и нет ли повторных записей. Отчёт за октябрь, выгруженный первого ноября, и тот же отчёт после поздних исправлений, и выгруженный 10 ноября, могут содержать разные данные. Совпадение итогов тоже не доказывает совпадение списков.   Не всякое расхождение объясняется разными правилами подсчёта. Если правила, период и исходные данные одинаковые, нужно искать ошибку в отборе записей, обработке данных или расчёте.   Данные могут передаваться без ошибок, хотя системы считают разные события. Поэтому сначала нужно договориться, что именно считаем. Если нужны оба ответа, дать им разные названия: «Впервые заключили договор» и «Впервые оплатили».   После сверки стоит записать правило расчёта, источник и того, кто отвечает за определение показателя. Договорённость «первую оплату берём из платёжной системы» не делает её главным источником для всех вопросов о клиентах: число заключённых договоров может потребовать другого источника.   Отдельная ловушка - смена правил подсчёта. Если раньше клиент считался новым по договору, а теперь по оплате, рост или снижение показателя нельзя автоматически связывать с работой отдела продаж. Нужно указать дату смены определения и, если позволяют данные, пересчитать прошлые периоды по тому же правилу. Если пересчитать их нельзя, нужно отметить, с какого момента показатели нельзя сравнивать напрямую. Иначе изменение методики легко принять за изменение бизнеса.   В сводке, подготовленной ИИ, я бы сохранял раздельные названия показателей и связь каждого числа с исходной выгрузкой: системой, периодом и временем обновления. Просьба «объясни, почему цифры не сходятся» не даёт недостающих сведений. Версию о задержке обновления или неоплаченных договорах нужно подтвердить записями, а не выбирать потому, что она убедительно звучит.   Прежде чем добиваться одинаковых цифр, стоит добиться одинакового понимания вопроса. Иногда итогом сверки должны стать исправленные данные. А иногда - два разных названия для двух корректных показателей, которые больше не пытаются выдать за один.

А вы сталкивались с ситуацией, когда пользователь системы находит ошибку в виде разных цифр по одному и тому показателю, полученному из разных отчётов в одной системе или даже из разных систем?