iiuniversitet.ruЦентр обучения нейросетямОткрыть каталог

Проверка анализа перед отправкой

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

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуется
Скачать на русскомОригинал на английском (архив)Источник ↗
Что делает
Проверяет анализ на ошибки в методике, расчётах и графиках и выдаёт оценку: можно отправлять, с оговорками или нужна доработка.
Когда брать
Перед презентацией для руководства или клиента, когда нужно перепроверить расчёты, SQL-запрос или убедиться, что выводы подкреплены данными.
Пример запроса
Проверь этот квартальный анализ выручки, прежде чем я отправлю его руководству.

Входит в плагин data. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

  1. Нажмите «Скачать на русском» и сохраните архив.
  2. В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
  3. Включите скилл переключателем.
Для терминала

Распакуйте архив и положите папку validate-data в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: validate-data
description: Проверь качество анализа перед тем, как делиться им, — методологию, точность и смещения. Используй, когда нужно просмотреть анализ перед презентацией для заинтересованных лиц, выборочно проверить расчёты и логику агрегации, убедиться, что результаты SQL-запроса выглядят правильно, или оценить, подкреплены ли выводы данными.
argument-hint: "<analysis to review>"
---

/validate-data - Проверка анализа перед отправкой

Если встретишь незнакомые подстановки или нужно проверить, какие инструменты подключены, смотри [CONNECTORS.md](../../CONNECTORS.md).

Проверь анализ на точность, методологию и возможные смещения, прежде чем делиться им с заинтересованными лицами. Результат — оценка уверенности и предложения по улучшению.

Использование

/validate-data <analysis to review>

Анализом может быть:

  • Документ или отчёт в разговоре
  • Файл (markdown, ноутбук, таблица)
  • SQL-запросы и их результаты
  • Графики и данные, на которых они построены
  • Описание методологии и выводов

Рабочий процесс

1. Проверь методологию и допущения

Изучи:

  • Формулировку вопроса: отвечает ли анализ на правильный вопрос? Можно ли понять вопрос иначе?
  • Выбор данных: используются ли нужные таблицы и наборы данных? Подходит ли период?
  • Определение выборки: правильно ли определена анализируемая группа? Нет ли непреднамеренных исключений?
  • Определения метрик: чётко ли и единообразно определены метрики? Совпадают ли они с тем, как их понимают заинтересованные лица?
  • Базовый уровень и сравнение: честное ли сравнение? Сопоставимы ли периоды, размеры когорт и контексты?

2. Пройди контрольный список QA перед отправкой

Пройди по приведённому ниже списку — проверки качества данных, расчётов, правдоподобия и подачи.

3. Проверь типичные ловушки анализа

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

4. Проверь расчёты и агрегации

Где возможно, проведи выборочную проверку:

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

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

5. Оцени визуализации

Если в анализе есть графики:

  • Начинаются ли оси с подходящих значений (с нуля для столбчатых диаграмм)?
  • Согласованы ли шкалы на графиках, которые сравниваются?
  • Точно ли заголовки графиков описывают то, что показано?
  • Могла ли визуализация ввести в заблуждение того, кто смотрит бегло?
  • Нет ли усечённых осей, неравных интервалов или 3D-эффектов, искажающих восприятие?

6. Оцени текст и выводы

Проверь, что:

  • Выводы подкреплены показанными данными
  • Альтернативные объяснения учтены
  • Неопределённость передана должным образом
  • Рекомендации логически следуют из выводов
  • Уровень уверенности соответствует силе доказательств

7. Предложи улучшения

Дай конкретные, применимые предложения:

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

8. Выдай оценку уверенности

Оцени анализ по трёхуровневой шкале:

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

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

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

Формат результата

## Отчёт о проверке

### Общая оценка: [Готов к отправке | Отправлять с оговорками | Требует доработки]

### Проверка методологии
[Выводы о подходе, выборе данных, определениях]

### Найденные проблемы
1. [Серьёзность: высокая/средняя/низкая] [Описание проблемы и её влияние]
2. ...

### Выборочная проверка расчётов
- [Метрика]: [Проверено / Найдено расхождение]
- ...

### Проверка визуализаций
[Любые проблемы с графиками или визуальной подачей]

### Предлагаемые улучшения
1. [Улучшение и почему оно важно]
2. ...

### Обязательные оговорки для заинтересованных лиц
- [Оговорка, о которой нужно сообщить]
- ...

Контрольный список QA перед отправкой

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

Проверки качества данных

  • [ ] Проверка источников: подтверждено, какие таблицы и источники данных использовались. Подходят ли они для этого вопроса?
  • [ ] Актуальность: данные достаточно свежие для анализа. Указана дата «по состоянию на».
  • [ ] Полнота: нет неожиданных пропусков во временных рядах и отсутствующих сегментов.
  • [ ] Обработка null: проверена доля пустых значений в ключевых столбцах. Пустые значения обработаны правильно (исключены, заполнены или помечены).
  • [ ] Дедупликация: подтверждено, что нет двойного счёта из-за неудачных соединений или дублирующихся исходных записей.
  • [ ] Проверка фильтров: все условия WHERE и фильтры верны. Нет непреднамеренных исключений.

Проверки расчётов

  • [ ] Логика агрегации: GROUP BY включает все неагрегированные столбцы. Уровень агрегации соответствует гранулярности анализа.
  • [ ] Правильность знаменателя: в расчётах долей и процентов используется правильный знаменатель. Знаменатели не равны нулю.
  • [ ] Согласование дат: в сравнениях периоды одинаковой длины. Неполные периоды исключены или отмечены.
  • [ ] Правильность соединений: типы JOIN подходят (INNER или LEFT). Соединения «многие ко многим» не раздули подсчёты.
  • [ ] Определения метрик: метрики совпадают с тем, как их определяют заинтересованные лица. Все отклонения отмечены.
  • [ ] Сумма промежуточных итогов: части в сумме дают целое, где этого ждут. Если нет, объяснено почему (например, пересечения).

Проверки правдоподобия

  • [ ] Порядок величин: числа в правдоподобном диапазоне. Выручка не отрицательна. Проценты находятся в пределах 0–100%.
  • [ ] Непрерывность тренда: нет необъяснимых скачков и провалов во временных рядах.
  • [ ] Перекрёстная сверка: ключевые числа совпадают с другими известными источниками (дашбордами, прошлыми отчётами, финансовыми данными).
  • [ ] Порядок величин в целом: общая выручка примерно соответствует действительности. Число пользователей совпадает с известными цифрами.
  • [ ] Крайние случаи: что происходит на границах? Пустые сегменты, периоды без активности, новые объекты.

Проверки подачи

  • [ ] Точность графиков: столбчатые диаграммы начинаются с нуля. Оси подписаны. Шкалы согласованы на разных панелях.
  • [ ] Форматирование чисел: подходящая точность. Единое оформление валюты и процентов. Разделители тысяч там, где нужно.
  • [ ] Ясность заголовков: заголовки формулируют вывод, а не просто метрику. Указаны периоды.
  • [ ] Прозрачность оговорок: известные ограничения и допущения указаны явно.
  • [ ] Воспроизводимость: кто-то другой мог бы повторить этот анализ по приложенной документации.

Типичные ловушки анализа данных

Взрыв строк при соединении (join explosion)

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

Как обнаружить:

-- Check row count before and after join
SELECT COUNT(*) FROM table_a;  -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3,500 (uh oh)

Как предотвратить:

  • Всегда проверяй число строк после соединений
  • Если число растёт, изучи связь в соединении (действительно ли она 1:1 или 1:много?)
  • Используй COUNT(DISTINCT a.id) вместо COUNT(*), когда считаешь объекты через соединения

Ошибка выжившего

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

Примеры:

  • Анализ поведения «текущих пользователей» упускает ушедших
  • Изучение «компаний, которые используют наш продукт», игнорирует тех, кто оценивал продукт и ушёл
  • Изучение свойств «успешных» исходов без «неуспешных»

Как предотвратить: перед выводами спроси: «Кого НЕТ в этом наборе данных?»

Сравнение неполных периодов

Проблема: неполный период сравнивается с полным.

Примеры:

  • «Выручка за январь — $500 тыс. против $800 тыс. в декабре» — но январь ещё не закончился
  • «Регистраций на этой неделе меньше» — проверено в среду, а сравнивают с целой прошлой неделей

Как предотвратить: всегда отбирай только завершённые периоды или сравнивай одни и те же дни месяца и одинаковое число дней.

Смещение знаменателя

Проблема: знаменатель меняется между периодами, и доли становятся несопоставимы.

Примеры:

  • Конверсия улучшилась, потому что изменился способ подсчёта «подходящих» пользователей
  • Отток изменился, потому что обновили определение «активного»

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

Среднее средних

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

Пример:

  • Группа A: 100 пользователей, средняя выручка $50
  • Группа B: 10 пользователей, средняя выручка $200
  • Неверно: среднее средних = ($50 + $200) / 2 = $125
  • Верно: взвешенное среднее = (100*$50 + 10*$200) / 110 = $63,64

Как предотвратить: всегда агрегируй из сырых данных. Никогда не усредняй уже агрегированные средние.

Несовпадение часовых поясов

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

Примеры:

  • Метки времени событий в UTC и даты для пользователя в местном времени
  • Ежедневные сводки с разными границами суток

Как предотвратить: приведи все метки времени к одному часовому поясу (рекомендуется UTC) до анализа. Задокументируй использованный часовой пояс.

Смещение выборки при сегментации

Проблема: сегменты определены по тому результату, который ты измеряешь, и получается замкнутая логика.

Примеры:

  • «Пользователи, прошедшие адаптацию, лучше удерживаются» — конечно, они сами себя отобрали
  • «Активные пользователи приносят больше выручки» — они стали активными, ПОТОМУ ЧТО приносили выручку

Как предотвратить: определяй сегменты по характеристикам до воздействия, а не по результатам.

Другие статистические ловушки

  • Парадокс Симпсона: тренд меняется на обратный при агрегации данных и при их разбиении по сегментам
  • Корреляция, выдаваемая за причинность, без подтверждающих доказательств
  • Малые выборки, ведущие к ненадёжным выводам
  • Выбросы, непропорционально влияющие на средние (не стоит ли использовать медианы?)
  • Множественные проверки / выборочный отбор значимых результатов
  • Заглядывание в будущее (look-ahead bias): использование будущей информации для объяснения прошлых событий
  • Выбранные под нужный вывод периоды времени, подгоняющие данные под определённую историю

Проверка результатов на здравый смысл

Проверки порядка величин

Для любого ключевого числа в анализе проверь, проходит ли оно проверку «на запах»:

Тип метрикиПроверка на здравый смысл
Число пользователейСовпадает ли оно с известными показателями MAU/DAU?
ВыручкаПравильный ли это порядок величины по сравнению с известной ARR?
КонверсииНаходится ли значение между 0% и 100%? Совпадает ли оно с цифрами в дашбордах?
Темпы ростаРеалистичен ли рост 50%+ месяц к месяцу или это проблема с данными?
СредниеРазумно ли среднее, исходя из того, что тебе известно о распределении?
ПроцентыДают ли проценты по сегментам в сумме ~100%?

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

  1. Посчитай ту же метрику двумя разными способами и проверь, что результаты совпадают
  2. Выборочно проверь отдельные записи — выбери несколько конкретных объектов и проследи их данные вручную
  3. Сравни с известными ориентирами — сопоставь с опубликованными дашбордами, финансовыми отчётами или прошлыми анализами
  4. Проверь обратным расчётом — если общая выручка равна X, примерно ли равна X выручка на пользователя, умноженная на число пользователей?
  5. Проверь на границах — что происходит, если отфильтровать один день, одного пользователя или одну категорию? Разумны ли эти микрорезультаты?

Тревожные сигналы, которые требуют разбора

  • Любая метрика, изменившаяся больше чем на 50% между периодами без очевидной причины
  • Счётчики или суммы, равные ровным круглым числам (говорит о проблеме с фильтром или значением по умолчанию)
  • Доли ровно 0% или 100% (могут указывать на неполные данные)
  • Результаты, которые идеально подтверждают гипотезу (реальность обычно запутаннее)
  • Одинаковые значения в разных периодах или сегментах (говорит о том, что запрос игнорирует какое-то измерение)

Стандарты документирования для воспроизводимости

Шаблон документации анализа

Каждый нетривиальный анализ должен включать:

## Анализ: [Название]

### Вопрос
[Конкретный вопрос, на который отвечает анализ]

### Источники данных
- Таблица: [schema.table_name] (по состоянию на [дата])
- Таблица: [schema.other_table] (по состоянию на [дата])
- Файл: [имя файла] (источник: [откуда взят])

### Определения
- [Метрика A]: [Как именно она считается]
- [Сегмент X]: [Как именно определяется принадлежность]
- [Период времени]: с [дата начала] по [дата окончания], [часовой пояс]

### Методология
1. [Шаг 1 подхода к анализу]
2. [Шаг 2]
3. [Шаг 3]

### Допущения и ограничения
- [Допущение 1 и почему оно разумно]
- [Ограничение 1 и его возможное влияние на выводы]

### Ключевые выводы
1. [Вывод 1 с подтверждающими доказательствами]
2. [Вывод 2 с подтверждающими доказательствами]

### SQL-запросы
[Все использованные запросы, с комментариями]

### Оговорки
- [О чём читателю нужно знать, прежде чем действовать на основе этого анализа]

Документирование кода

Для любого кода (SQL, Python), который могут использовать повторно:

"""
Анализ: Месячное удержание когорт
Автор: [Имя]
Дата: [Дата]
Источник данных: таблица events, таблица users
Последняя проверка: [Дата] -- результаты совпали с дашбордом с точностью до 2%

Назначение:
    Рассчитать месячное удержание пользовательских когорт по дате первой активности.

Допущения:
    - «Активный» означает как минимум одно событие в течение месяца
    - Тестовые и внутренние аккаунты исключены (user_type != 'internal')
    - Везде используются даты в UTC

Результат:
    Матрица удержания когорт со строками cohort_month и столбцами months_since_signup.
    Значения — доли удержания (0–100%).
"""

Контроль версий для анализов

  • Храни запросы и код в системе контроля версий (git) или в общей системе документов
  • Отмечай дату снимка данных, который использовался
  • Если анализ перезапущен на обновлённых данных, задокументируй, что изменилось и почему
  • Давай ссылки на прошлые версии регулярных анализов для сравнения трендов

Примеры

/validate-data Проверь этот квартальный анализ выручки, прежде чем я отправлю его руководству: [анализ]
/validate-data Проверь мой анализ оттока — я сравниваю отток в 4 квартале с 3 кварталом, но в 4 квартале окно измерения короче
/validate-data Вот SQL-запрос и его результаты по нашей воронке конверсии. Логика выглядит правильно? [запрос + результаты]

Советы

  • Запускай /validate-data перед любой важной презентацией или решением
  • Даже быстрым анализам полезна проверка на здравый смысл — она занимает минуту и может уберечь вашу репутацию
  • Если проверка находит проблемы, исправь их и проверь заново
  • Прикладывай результат проверки к анализу — так вы укрепите доверие заинтересованных лиц

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/data/skills/validate-data, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском 
---
name: validate-data
description: QA an analysis before sharing -- methodology, accuracy, and bias checks. Use when reviewing an analysis before a stakeholder presentation, spot-checking calculations and aggregation logic, verifying a SQL query's results look right, or assessing whether conclusions are actually supported by the data.
argument-hint: "<analysis to review>"
---

# /validate-data - Validate Analysis Before Sharing

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Review an analysis for accuracy, methodology, and potential biases before sharing with stakeholders. Generates a confidence assessment and improvement suggestions.

## Usage

```
/validate-data <analysis to review>
```

The analysis can be:
- A document or report in the conversation
- A file (markdown, notebook, spreadsheet)
- SQL queries and their results
- Charts and their underlying data
- A description of methodology and findings

## Workflow

### 1. Review Methodology and Assumptions

Examine:

- **Question framing**: Is the analysis answering the right question? Could the question be interpreted differently?
- **Data selection**: Are the right tables/datasets being used? Is the time range appropriate?
- **Population definition**: Is the analysis population correctly defined? Are there unintended exclusions?
- **Metric definitions**: Are metrics defined clearly and consistently? Do they match how stakeholders understand them?
- **Baseline and comparison**: Is the comparison fair? Are time periods, cohort sizes, and contexts comparable?

### 2. Run the Pre-Delivery QA Checklist

Work through the checklist below — data quality, calculation, reasonableness, and presentation checks.

### 3. Check for Common Analytical Pitfalls

Systematically review against the detailed pitfall catalog below (join explosion, survivorship bias, incomplete period comparison, denominator shifting, average of averages, timezone mismatches, selection bias).

### 4. Verify Calculations and Aggregations

Where possible, spot-check:

- Recalculate a few key numbers independently
- Verify that subtotals sum to totals
- Check that percentages sum to 100% (or close to it) where expected
- Confirm that YoY/MoM comparisons use the correct base periods
- Validate that filters are applied consistently across all metrics

Apply the result sanity-checking techniques below (magnitude checks, cross-validation, red-flag detection).

### 5. Assess Visualizations

If the analysis includes charts:

- Do axes start at appropriate values (zero for bar charts)?
- Are scales consistent across comparison charts?
- Do chart titles accurately describe what's shown?
- Could the visualization mislead a quick reader?
- Are there truncated axes, inconsistent intervals, or 3D effects that distort perception?

### 6. Evaluate Narrative and Conclusions

Review whether:

- Conclusions are supported by the data shown
- Alternative explanations are acknowledged
- Uncertainty is communicated appropriately
- Recommendations follow logically from findings
- The level of confidence matches the strength of evidence

### 7. Suggest Improvements

Provide specific, actionable suggestions:

- Additional analyses that would strengthen the conclusions
- Caveats or limitations that should be noted
- Better visualizations or framings for key points
- Missing context that stakeholders would want

### 8. Generate Confidence Assessment

Rate the analysis on a 3-level scale:

**Ready to share** -- Analysis is methodologically sound, calculations verified, caveats noted. Minor suggestions for improvement but nothing blocking.

**Share with noted caveats** -- Analysis is largely correct but has specific limitations or assumptions that must be communicated to stakeholders. List the required caveats.

**Needs revision** -- Found specific errors, methodological issues, or missing analyses that should be addressed before sharing. List the required changes with priority order.

## Output Format

```
## Validation Report

### Overall Assessment: [Ready to share | Share with caveats | Needs revision]

### Methodology Review
[Findings about approach, data selection, definitions]

### Issues Found
1. [Severity: High/Medium/Low] [Issue description and impact]
2. ...

### Calculation Spot-Checks
- [Metric]: [Verified / Discrepancy found]
- ...

### Visualization Review
[Any issues with charts or visual presentation]

### Suggested Improvements
1. [Improvement and why it matters]
2. ...

### Required Caveats for Stakeholders
- [Caveat that must be communicated]
- ...
```

---

## Pre-Delivery QA Checklist

Run through this checklist before sharing any analysis with stakeholders.

### Data Quality Checks

- [ ] **Source verification**: Confirmed which tables/data sources were used. Are they the right ones for this question?
- [ ] **Freshness**: Data is current enough for the analysis. Noted the "as of" date.
- [ ] **Completeness**: No unexpected gaps in time series or missing segments.
- [ ] **Null handling**: Checked null rates in key columns. Nulls are handled appropriately (excluded, imputed, or flagged).
- [ ] **Deduplication**: Confirmed no double-counting from bad joins or duplicate source records.
- [ ] **Filter verification**: All WHERE clauses and filters are correct. No unintended exclusions.

### Calculation Checks

- [ ] **Aggregation logic**: GROUP BY includes all non-aggregated columns. Aggregation level matches the analysis grain.
- [ ] **Denominator correctness**: Rate and percentage calculations use the right denominator. Denominators are non-zero.
- [ ] **Date alignment**: Comparisons use the same time period length. Partial periods are excluded or noted.
- [ ] **Join correctness**: JOIN types are appropriate (INNER vs LEFT). Many-to-many joins haven't inflated counts.
- [ ] **Metric definitions**: Metrics match how stakeholders define them. Any deviations are noted.
- [ ] **Subtotals sum**: Parts add up to the whole where expected. If they don't, explain why (e.g., overlap).

### Reasonableness Checks

- [ ] **Magnitude**: Numbers are in a plausible range. Revenue isn't negative. Percentages are between 0-100%.
- [ ] **Trend continuity**: No unexplained jumps or drops in time series.
- [ ] **Cross-reference**: Key numbers match other known sources (dashboards, previous reports, finance data).
- [ ] **Order of magnitude**: Total revenue is in the right ballpark. User counts match known figures.
- [ ] **Edge cases**: What happens at the boundaries? Empty segments, zero-activity periods, new entities.

### Presentation Checks

- [ ] **Chart accuracy**: Bar charts start at zero. Axes are labeled. Scales are consistent across panels.
- [ ] **Number formatting**: Appropriate precision. Consistent currency/percentage formatting. Thousands separators where needed.
- [ ] **Title clarity**: Titles state the insight, not just the metric. Date ranges are specified.
- [ ] **Caveat transparency**: Known limitations and assumptions are stated explicitly.
- [ ] **Reproducibility**: Someone else could recreate this analysis from the documentation provided.

## Common Data Analysis Pitfalls

### Join Explosion

**The problem**: A many-to-many join silently multiplies rows, inflating counts and sums.

**How to detect**:
```sql
-- Check row count before and after join
SELECT COUNT(*) FROM table_a;  -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3,500 (uh oh)
```

**How to prevent**:
- Always check row counts after joins
- If counts increase, investigate the join relationship (is it really 1:1 or 1:many?)
- Use `COUNT(DISTINCT a.id)` instead of `COUNT(*)` when counting entities through joins

### Survivorship Bias

**The problem**: Analyzing only entities that exist today, ignoring those that were deleted, churned, or failed.

**Examples**:
- Analyzing user behavior of "current users" misses churned users
- Looking at "companies using our product" ignores those who evaluated and left
- Studying properties of "successful" outcomes without "unsuccessful" ones

**How to prevent**: Ask "who is NOT in this dataset?" before drawing conclusions.

### Incomplete Period Comparison

**The problem**: Comparing a partial period to a full period.

**Examples**:
- "January revenue is $500K vs. December's $800K" -- but January isn't over yet
- "This week's signups are down" -- checked on Wednesday, comparing to a full prior week

**How to prevent**: Always filter to complete periods, or compare same-day-of-month / same-number-of-days.

### Denominator Shifting

**The problem**: The denominator changes between periods, making rates incomparable.

**Examples**:
- Conversion rate improves because you changed how you count "eligible" users
- Churn rate changes because the definition of "active" was updated

**How to prevent**: Use consistent definitions across all compared periods. Note any definition changes.

### Average of Averages

**The problem**: Averaging pre-computed averages gives wrong results when group sizes differ.

**Example**:
- Group A: 100 users, average revenue $50
- Group B: 10 users, average revenue $200
- Wrong: Average of averages = ($50 + $200) / 2 = $125
- Right: Weighted average = (100*$50 + 10*$200) / 110 = $63.64

**How to prevent**: Always aggregate from raw data. Never average pre-aggregated averages.

### Timezone Mismatches

**The problem**: Different data sources use different timezones, causing misalignment.

**Examples**:
- Event timestamps in UTC vs. user-facing dates in local time
- Daily rollups that use different cutoff times

**How to prevent**: Standardize all timestamps to a single timezone (UTC recommended) before analysis. Document the timezone used.

### Selection Bias in Segmentation

**The problem**: Segments are defined by the outcome you're measuring, creating circular logic.

**Examples**:
- "Users who completed onboarding have higher retention" -- obviously, they self-selected
- "Power users generate more revenue" -- they became power users BY generating revenue

**How to prevent**: Define segments based on pre-treatment characteristics, not outcomes.

### Other Statistical Traps

- **Simpson's paradox**: Trend reverses when data is aggregated vs. segmented
- **Correlation presented as causation** without supporting evidence
- **Small sample sizes** leading to unreliable conclusions
- **Outliers disproportionately affecting averages** (should medians be used instead?)
- **Multiple testing / cherry-picking** significant results
- **Look-ahead bias**: Using future information to explain past events
- **Cherry-picked time ranges** that favor a particular narrative

## Result Sanity Checking

### Magnitude Checks

For any key number in your analysis, verify it passes the "smell test":

| Metric Type | Sanity Check |
|---|---|
| User counts | Does this match known MAU/DAU figures? |
| Revenue | Is this in the right order of magnitude vs. known ARR? |
| Conversion rates | Is this between 0% and 100%? Does it match dashboard figures? |
| Growth rates | Is 50%+ MoM growth realistic, or is there a data issue? |
| Averages | Is the average reasonable given what you know about the distribution? |
| Percentages | Do segment percentages sum to ~100%? |

### Cross-Validation Techniques

1. **Calculate the same metric two different ways** and verify they match
2. **Spot-check individual records** -- pick a few specific entities and trace their data manually
3. **Compare to known benchmarks** -- match against published dashboards, finance reports, or prior analyses
4. **Reverse engineer** -- if total revenue is X, does per-user revenue times user count approximately equal X?
5. **Boundary checks** -- what happens when you filter to a single day, a single user, or a single category? Are those micro-results sensible?

### Red Flags That Warrant Investigation

- Any metric that changed by more than 50% period-over-period without an obvious cause
- Counts or sums that are exact round numbers (suggests a filter or default value issue)
- Rates exactly at 0% or 100% (may indicate incomplete data)
- Results that perfectly confirm the hypothesis (reality is usually messier)
- Identical values across time periods or segments (suggests the query is ignoring a dimension)

## Documentation Standards for Reproducibility

### Analysis Documentation Template

Every non-trivial analysis should include:

```markdown
## Analysis: [Title]

### Question
[The specific question being answered]

### Data Sources
- Table: [schema.table_name] (as of [date])
- Table: [schema.other_table] (as of [date])
- File: [filename] (source: [where it came from])

### Definitions
- [Metric A]: [Exactly how it's calculated]
- [Segment X]: [Exactly how membership is determined]
- [Time period]: [Start date] to [end date], [timezone]

### Methodology
1. [Step 1 of the analysis approach]
2. [Step 2]
3. [Step 3]

### Assumptions and Limitations
- [Assumption 1 and why it's reasonable]
- [Limitation 1 and its potential impact on conclusions]

### Key Findings
1. [Finding 1 with supporting evidence]
2. [Finding 2 with supporting evidence]

### SQL Queries
[All queries used, with comments]

### Caveats
- [Things the reader should know before acting on this]
```

### Code Documentation

For any code (SQL, Python) that may be reused:

```python
"""
Analysis: Monthly Cohort Retention
Author: [Name]
Date: [Date]
Data Source: events table, users table
Last Validated: [Date] -- results matched dashboard within 2%

Purpose:
    Calculate monthly user retention cohorts based on first activity date.

Assumptions:
    - "Active" means at least one event in the month
    - Excludes test/internal accounts (user_type != 'internal')
    - Uses UTC dates throughout

Output:
    Cohort retention matrix with cohort_month rows and months_since_signup columns.
    Values are retention rates (0-100%).
"""
```

### Version Control for Analyses

- Save queries and code in version control (git) or a shared docs system
- Note the date of the data snapshot used
- If an analysis is re-run with updated data, document what changed and why
- Link to prior versions of recurring analyses for trend comparison

## Examples

```
/validate-data Review this quarterly revenue analysis before I send it to the exec team: [analysis]
```

```
/validate-data Check my churn analysis -- I'm comparing Q4 churn rates to Q3 but Q4 has a shorter measurement window
```

```
/validate-data Here's a SQL query and its results for our conversion funnel. Does the logic look right? [query + results]
```

## Tips

- Run /validate-data before any high-stakes presentation or decision
- Even quick analyses benefit from a sanity check -- it takes a minute and can save your credibility
- If the validation finds issues, fix them and re-validate
- Share the validation output alongside your analysis to build stakeholder confidence

Источник: anthropics/knowledge-work-plugins / data / validate-data ↗. Ссылка проверена 2026-10-10.

Похожие