Если график включает отмененные заказы, отчет может завышать продажи, средний чек и конверсию. Сначала нужно определить бизнес-смысл метрики: созданные, оплаченные, завершенные или неотмененные заказы — это разные показатели.
Возьмите несколько заказов с известной историей и сравните их вклад в SQL, витрину и график. Исправляйте единое определение метрики, а не фильтр только в визуализации.
Коротко: что сделать
- Зафиксировать формулу показателя
- Составить карту статусов заказа
- Проверить дату создания, оплаты и отмены
- Проверить возвраты и частичные возвраты
- Сверить SQL источника и настройки BI
Почему возникает проблема
Отмена часто хранится отдельным событием или статусом, который меняется после попадания заказа в агрегированную витрину.
- Отчет фильтрует только status != cancelled, но есть другие отмененные статусы
- Витрина добавляет заказ при создании и не пересчитывает после отмены
- Используется дата создания вместо даты оплаты
- Возврат учитывается как отдельная продажа
- Кэш BI не обновился
- Статусы из разных систем сопоставлены неправильно
Пошаговая диагностика
Проверку лучше проводить на одном воспроизводимом примере и фиксировать результат каждого шага. Так можно быстро отделить первопричину от побочных ошибок и не менять несколько компонентов одновременно.
- Выбрать 10 заказов разных статусов
- Сверить исходную таблицу и витрину по ID
- Проверить историю изменения статуса
- Выполнить SQL без агрегации
- Проверить часовой пояс периода
- Проверить refresh dataset и кэш dashboard
Как исправить
Метрику следует вычислять на уровне подготовленной модели данных с единым справочником статусов.
- Создать нормализованную группу business_status
- Считать продажи по подтвержденному событию оплаты
- Применять отмены и возвраты при пересчете витрины
- Сделать инкрементальную загрузку захватывающей измененные заказы
- Исправить join, который размножает строки
- Отобразить отдельно созданные, оплаченные и отмененные заказы
Как проверить результат
- Сверить итог по контрольным заказам
- Сравнить сумму с платежной системой
- Проверить изменение статуса задним числом
- Проверить частичный возврат
- Проверить разные периоды и часовые пояса
Как не допустить повторения
Каждая BI-метрика должна иметь владельца, формулу и набор контрольных примеров.
- Вести словарь метрик
- Добавить тесты качества витрины
- Мониторить расхождение с источником
- Версионировать SQL и правила статусов
Чего не стоит делать
- Не скрывать отмены только фильтром виджета
- Не менять формулу без согласования смысла
- Не суммировать строки после размножающего join
- Не сравнивать отчеты с разными датами события
Что подготовить для диагностики
- Список статусов
- Примеры заказов и их история
- SQL датасета
- Расписание обновления
- Ожидаемая формула показателя
Частые вопросы
Нужно ли исключать все отмененные заказы?
Для выручки обычно да, но для воронки созданных заказов отмены могут учитываться отдельным этапом.
Почему вчера цифра была другой?
Заказы могли отмениться позже, витрина пересчиталась или изменился статус оплаты.
Как учитывать возвраты?
Отдельно от отмен: полный или частичный возврат должен уменьшать признанную сумму по согласованному правилу.
Когда стоит обратиться за помощью
Помощь нужна, если данные приходят из CRM, сайта и платежной системы, а разные отчеты используют разные статусы и суммы.
Итог
Корректный график начинается с определения метрики, нормализации статусов и проверяемой витрины. Исправить SQL и BI-логику можно через @rabotator_support.