Короткий ответ
Делаю анализ на доступных данных, явно указываю период и источник, которых не хватает, оцениваю направление возможного смещения (например, недооценка метрики из-за отсутствия свежих записей) и формулирую выводы с явными оговорками, а не как окончательный результат.
Как это работает подробнее
неполные данные не означают «нельзя анализировать» — они означают, что нужно явно обозначить, какую часть картины не видно, и в какую сторону это может искажать выводы, чтобы потребитель отчёта не принял частичный результат за полный.
Пример кода
analysis.sql
SELECT date_trunc('day', updated_at) AS load_day, count(*) AS rows_loaded
FROM crm_export_log
WHERE updated_at >= current_date - interval '14 days'
GROUP BY 1 ORDER BY 1;Что использовать на практике
- На практике: сначала проверяю масштаб проблемы (какая доля данных и какого периода отсутствует); рассуждаю о направлении смещения (если отсутствуют именно свежие записи CRM, то метрики «за последнюю неделю» могут быть занижены); там, где можно, сверяю с альтернативным источником (например, биллингом) для частичной проверки; в отчёте отдельным блоком указываю ограничения и степень уверенности в выводах.
- Проверка: если rows_loaded = 0 за последние 7 дней, это подтверждает масштаб проблемы; в отчёт добавляю пометку «данные CRM актуальны по <дата>, метрики за последнюю неделю могут быть занижены».
Подводные камни
- Частые ошибки: молча выдавать отчёт на неполных данных как будто он полный; полностью отказываться от анализа из-за неполноты данных, хотя частичный, но помеченный как предварительный результат может быть полезен для срочного решения; не указывать направление возможного смещения, оставляя потребителя отчёта без понимания, куда «подправить» цифру мысленно.