/validate-data - Valider une analyse avant de la partager

Si vous voyez des placeholders inconnus ou besoin de vérifier quels outils sont connectés, consultez CONNECTORS.md.

Examinez une analyse pour sa précision, sa méthodologie et les biais potentiels avant de la partager avec les parties prenantes. Génère une évaluation de confiance et des suggestions d'amélioration.

Utilisation

/validate-data <analysis to review>

L'analyse peut être :

• Un document ou rapport dans la conversation
• Un fichier (markdown, notebook, feuille de calcul)
• Des requêtes SQL et leurs résultats
• Des graphiques et leurs données sous-jacentes
• Une description de la méthodologie et des résultats

Flux de travail

1. Examiner la méthodologie et les hypothèses

Examinez :

• Formulation de la question : L'analyse répond-elle à la bonne question ? La question pourrait-elle être interprétée différemment ?
• Sélection des données : Les bonnes tables/datasets sont-ils utilisés ? La plage temporelle est-elle appropriée ?
• Définition de la population : La population de l'analyse est-elle correctement définie ? Y a-t-il des exclusions involontaires ?
• Définitions des métriques : Les métriques sont-elles définies clairement et consistamment ? Correspondent-elles à la compréhension des parties prenantes ?
• Baseline et comparaison : La comparaison est-elle équitable ? Les périodes, tailles de cohortes et contextes sont-ils comparables ?

2. Exécuter la liste de contrôle QA pré-livraison

Travaillez à travers la liste de contrôle ci-dessous — vérifications de qualité des données, de calcul, de plausibilité et de présentation.

3. Vérifier les pièges analytiques courants

Examinez systématiquement le catalogue détaillé des pièges ci-dessous (explosion de jointure, survivorship bias, comparaison de période incomplète, dénominateur changeant, moyenne de moyennes, décalages de fuseau horaire, biais de sélection).

4. Vérifier les calculs et agrégations

Où possible, vérifiez par sondage :

• Recalculez quelques nombres clés indépendamment
• Vérifiez que les sous-totaux s'additionnent aux totaux
• Vérifiez que les pourcentages s'additionnent à 100 % (ou proche) quand c'est prévu
• Confirmez que les comparaisons YoY/MoM utilisent les bonnes périodes de base
• Validez que les filtres sont appliqués consistemment sur toutes les métriques

Appliquez les techniques de vérification de plausibilité des résultats ci-dessous (vérifications de magnitude, validation croisée, détection de drapeaux rouges).

5. Évaluer les visualisations

Si l'analyse inclut des graphiques :

• Les axes commencent-ils à des valeurs appropriées (zéro pour les diagrammes en barres) ?
• Les échelles sont-elles consistantes entre les graphiques de comparaison ?
• Les titres des graphiques décrivent-ils précisément ce qui est montré ?
• La visualisation pourrait-elle tromper un lecteur rapide ?
• Y a-t-il des axes tronqués, des intervalles inconsistants ou des effets 3D qui distordent la perception ?

6. Évaluer le narrative et les conclusions

Vérifiez si :

• Les conclusions sont soutenues par les données affichées
• Les explications alternatives sont reconnues
• L'incertitude est communiquée de manière appropriée
• Les recommandations suivent logiquement des résultats
• Le niveau de confiance correspond à la force de la preuve

7. Proposer des améliorations

Fournissez des suggestions spécifiques et actionnables :

• Analyses supplémentaires qui renforceraient les conclusions
• Avertissements ou limitations qui devraient être notés
• Meilleures visualisations ou cadrages pour les points clés
• Contexte manquant que les parties prenantes aimeraient avoir

8. Générer une évaluation de confiance

Évaluez l'analyse sur une échelle à 3 niveaux :

Prête à partager -- L'analyse est méthodologiquement solide, les calculs sont vérifiés, les avertissements sont notés. Suggestions mineures d'amélioration mais rien de bloquant.

Partager avec avertissements notés -- L'analyse est largement correcte mais a des limitations ou hypothèses spécifiques qui doivent être communiquées aux parties prenantes. Listez les avertissements requis.

Nécessite une révision -- Erreurs spécifiques trouvées, problèmes méthodologiques ou analyses manquantes qui devraient être corrigés avant partage. Listez les changements requis par ordre de priorité.

Format de sortie

## Rapport de validation

### Évaluation globale : [Prête à partager | Partager avec avertissements | Nécessite une révision]

### Examen de la méthodologie
[Résultats sur l'approche, la sélection des données, les définitions]

### Problèmes trouvés
1. [Sévérité : Haute/Moyenne/Basse] [Description du problème et impact]
2. ...

### Vérifications de calcul par sondage
- [Métrique] : [Vérifiée / Discordance trouvée]
- ...

### Examen des visualisations
[Tout problème avec les graphiques ou la présentation visuelle]

### Améliorations suggérées
1. [Amélioration et pourquoi c'est important]
2. ...

### Avertissements requis pour les parties prenantes
- [Avertissement qui doit être communiqué]
- ...

Liste de contrôle QA pré-livraison

Passez en revue cette liste de contrôle avant de partager une analyse avec les parties prenantes.

Vérifications de qualité des données

• [ ] Vérification des sources : Confirmé quelles tables/sources de données ont été utilisées. Sont-ce les bonnes pour cette question ?
• [ ] Fraîcheur : Les données sont assez actuelles pour l'analyse. Date « au » notée.
• [ ] Complétude : Pas de lacunes inattendues dans les séries temporelles ou segments manquants.
• [ ] Gestion des nulls : Vérifiez les taux de nulls dans les colonnes clés. Les nulls sont gérés de manière appropriée (exclus, imputés ou signalés).
• [ ] Dédupplication : Confirmé qu'il n'y a pas de double-comptage provenant de mauvaises jointures ou de doublons en source.
• [ ] Vérification des filtres : Toutes les clauses WHERE et filtres sont corrects. Pas d'exclusions involontaires.

Vérifications de calcul

• [ ] Logique d'agrégation : GROUP BY inclut toutes les colonnes non-agrégées. Le niveau d'agrégation correspond au grain de l'analyse.
• [ ] Exactitude du dénominateur : Les calculs de taux et pourcentages utilisent le bon dénominateur. Les dénominateurs ne sont pas zéro.
• [ ] Alignement des dates : Les comparaisons utilisent la même longueur de période. Les périodes partielles sont exclues ou notées.
• [ ] Exactitude de la jointure : Les types de JOIN sont appropriés (INNER vs LEFT). Les jointures many-to-many n'ont pas gonflé les comptages.
• [ ] Définitions des métriques : Les métriques correspondent à la façon dont les parties prenantes les définissent. Toute déviation est notée.
• [ ] Sous-totaux qui s'additionnent : Les parties s'additionnent au tout quand c'est prévu. Si ce n'est pas le cas, expliquez pourquoi (par ex., chevauchement).

Vérifications de plausibilité

• [ ] Magnitude : Les nombres sont dans une plage plausible. Les revenus ne sont pas négatifs. Les pourcentages sont entre 0-100 %.
• [ ] Continuité des tendances : Pas de sauts ou baissesexpliqués dans les séries temporelles.
• [ ] Référence croisée : Les nombres clés correspondent à d'autres sources connues (tableaux de bord, rapports précédents, données financières).
• [ ] Ordre de magnitude : Le revenu total est dans le bon ordre de grandeur. Les comptages d'utilisateurs correspondent aux chiffres connus.
• [ ] Cas limites : Que se passe-t-il aux frontières ? Segments vides, périodes sans activité, nouvelles entités.

Vérifications de présentation

• [ ] Exactitude des graphiques : Les diagrammes en barres commencent à zéro. Les axes sont étiquetés. Les échelles sont consistantes entre les panneaux.
• [ ] Formatage des nombres : Précision appropriée. Formatage consistent des devises/pourcentages. Séparateurs de milliers où nécessaire.
• [ ] Clarté des titres : Les titres énoncent l'insight, pas simplement la métrique. Les plages de dates sont spécifiées.
• [ ] Transparence des avertissements : Les limitations et hypothèses connues sont énoncées explicitement.
• [ ] Reproductibilité : Quelqu'un d'autre pourrait recréer cette analyse à partir de la documentation fournie.

Pièges courants de l'analyse de données

Explosion de jointure

Le problème : Une jointure many-to-many multiplie silencieusement les lignes, gonflant les comptages et sommes.

Comment détecter :

-- Vérifiez le comptage de lignes avant et après la jointure
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)

Comment prévenir :

• Vérifiez toujours les comptages de lignes après les jointures
• Si les comptages augmentent, enquêtez sur la relation de jointure (est-ce vraiment 1:1 ou 1:many ?)
• Utilisez COUNT(DISTINCT a.id) au lieu de COUNT(*) quand vous comptez des entités via des jointures

Survivorship Bias

Le problème : Analyser uniquement les entités qui existent aujourd'hui, en ignorant celles qui ont été supprimées, désabonnées ou qui ont échoué.

Exemples :

• Analyser le comportement des utilisateurs des « utilisateurs actuels » omet les utilisateurs désabonnés
• Regarder les « entreprises utilisant notre produit » ignore celles qui ont évalué et parti
• Étudier les propriétés des résultats « réussis » sans les résultats « non réussis »

Comment prévenir : Posez-vous « qui n'est PAS dans ce dataset ? » avant de tirer des conclusions.

Comparaison de période incomplète

Le problème : Comparer une période partielle à une période complète.

Exemples :

• « Le revenu de janvier est 500 K$ contre 800 K$ en décembre » -- mais janvier n'est pas terminé
• « Les inscriptions de cette semaine sont baissées » -- vérifiés mercredi, comparés à une semaine précédente complète

Comment prévenir : Filtrez toujours les périodes complètes, ou comparez le même jour du mois / même nombre de jours.

Dénominateur changeant

Le problème : Le dénominateur change entre les périodes, rendant les taux incomparables.

Exemples :

• Le taux de conversion s'améliore parce que vous avez changé comment vous comptez les utilisateurs « éligibles »
• Le taux de churn change parce que la définition d'« actif » a été mise à jour

Comment prévenir : Utilisez des définitions consistantes sur toutes les périodes comparées. Notez tout changement de définition.

Moyenne de moyennes

Le problème : Faire la moyenne de moyennes pré-calculées donne des résultats incorrects quand les tailles de groupes diffèrent.

Exemple :

• Groupe A : 100 utilisateurs, revenu moyen 50 $
• Groupe B : 10 utilisateurs, revenu moyen 200 $
• Incorrect : Moyenne des moyennes = (50 $ + 200 $) / 2 = 125 $
• Correct : Moyenne pondérée = (10050 $ + 10200 $) / 110 = 63,64 $

Comment prévenir : Agrégez toujours à partir des données brutes. N'faites jamais la moyenne de moyennes pré-agrégées.

Décalages de fuseau horaire

Le problème : Différentes sources de données utilisent différents fuseaux horaires, causant un désalignement.

Exemples :

• Timestamps d'événements en UTC vs. dates côté utilisateur en heure locale
• Les cumuls quotidiens qui utilisent différentes heures de coupure

Comment prévenir : Standardisez tous les timestamps à un seul fuseau horaire (UTC recommandé) avant l'analyse. Documentez le fuseau horaire utilisé.

Biais de sélection dans la segmentation

Le problème : Les segments sont définis par le résultat que vous mesurez, créant une logique circulaire.

Exemples :

• « Les utilisateurs qui ont complété l'onboarding ont une meilleure rétention » -- évidemment, ils se sont auto-sélectionnés
• « Les utilisateurs puissants génèrent plus de revenu » -- ils sont devenus des utilisateurs puissants EN générant du revenu

Comment prévenir : Définissez les segments basés sur les caractéristiques pré-traitement, pas sur les résultats.

Autres pièges statistiques

• Paradoxe de Simpson : La tendance s'inverse quand les données sont agrégées vs. segmentées
• Corrélation présentée comme causalité sans preuve à l'appui
• Petites tailles d'échantillon menant à des conclusions peu fiables
• Les outliers affectent disproportionnément les moyennes (les médianes devraient-elles être utilisées à la place ?)
• Tests multiples / cherry-picking de résultats significatifs
• Look-ahead bias : Utiliser des informations futures pour expliquer les événements passés
• Plages de temps cherry-picked qui favorisent un narrative particulier

Vérification de plausibilité des résultats

Vérifications de magnitude

Pour tout nombre clé dans votre analyse, vérifiez qu'il passe le « test olfactif » :

Techniques de validation croisée

1. Calculez la même métrique de deux façons différentes et vérifiez qu'elles correspondent
2. Vérifiez par sondage les enregistrements individuels -- choisissez quelques entités spécifiques et tracez leurs données manuellement
3. Comparez à des benchmarks connus -- appariez contre les tableaux de bord publiés, rapports financiers ou analyses précédentes
4. Ingénierie inverse -- si le revenu total est X, le revenu par utilisateur fois le comptage d'utilisateurs approxime-t-il X ?
5. Vérifications de limites -- que se passe-t-il quand vous filtrez à un seul jour, un seul utilisateur ou une seule catégorie ? Ces micro-résultats sont-ils sensés ?

Drapeaux rouges qui justifient une enquête

• Toute métrique qui a changé de plus de 50 % d'une période à l'autre sans cause évidente
• Les comptages ou sommes qui sont des nombres ronds exacts (suggère un problème de filtre ou valeur par défaut)
• Les taux exactement à 0 % ou 100 % (peut indiquer des données incomplètes)
• Les résultats qui confirment parfaitement l'hypothèse (la réalité est généralement plus désordonnée)
• Les valeurs identiques sur les périodes ou segments temporels (suggère que la requête ignore une dimension)

Standards de documentation pour la reproductibilité

Modèle de documentation d'analyse

Toute analyse non triviale devrait inclure :

## Analysis: [Title]

### Question
[La question spécifique à laquelle on répond]

### 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]

Documentation du code

Pour tout code (SQL, Python) qui pourrait être réutilisé :

"""
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%).
"""

Contrôle de version pour les analyses

• Sauvegardez les requêtes et le code dans le contrôle de version (git) ou un système de docs partagé
• Notez la date du snapshot de données utilisé
• Si une analyse est réexécutée avec des données mises à jour, documentez ce qui a changé et pourquoi
• Liez à des versions précédentes des analyses récurrentes pour la comparaison de tendances

Exemples

/validate-data Examinez cette analyse de revenu trimestriel avant que je l'envoie à l'équipe de direction : [analysis]

/validate-data Vérifiez mon analyse de churn -- Je compare les taux de churn Q4 à Q3 mais Q4 a une fenêtre de mesure plus courte

/validate-data Voici une requête SQL et ses résultats pour notre funnel de conversion. La logique semble-t-elle correcte ? [query + results]

Conseils

• Exécutez /validate-data avant toute présentation ou décision à enjeux élevés
• Même les analyses rapides bénéficient d'une vérification de plausibilité -- cela prend une minute et peut sauver votre crédibilité
• Si la validation trouve des problèmes, corrigez-les et re-validez
• Partagez la sortie de validation avec votre analyse pour renforcer la confiance des parties prenantes