hzy24/validate-data

/validate-data - Valider l'analyse avant de la partager

Si vous voyez des espaces réservés inconnus ou devez vérifier quels outils sont connectés, consultez CONNECTORS.md.

Examiner une analyse pour vérifier sa précision, sa méthodologie et ses 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 <analyse à examiner>

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

Examiner :

• Cadrage 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/ensembles de données sont-ils utilisés ? La plage temporelle est-elle appropriée ?
• Définition de la population : La population analysée 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 de manière cohérente ? Correspondent-elles à la façon dont les parties prenantes les comprennent ?
• Référence et comparaison : La comparaison est-elle équitable ? Les périodes, les tailles de cohorte et les contextes sont-ils comparables ?

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

Parcourez la liste de contrôle ci-dessous — qualité des données, calcul, plausibilité et vérifications 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 jointures, biais de survie, comparaison de période incomplète, déplacement du dénominateur, moyenne des moyennes, décalages de fuseaux horaires, biais de sélection).

4. Vérifier les calculs et les agrégations

Dans la mesure du possible, vérifiez par sondage :

• Recalculez indépendamment quelques chiffres clés
• Vérifiez que les sous-totaux totalisent les totaux
• Vérifiez que les pourcentages totalisent 100 % (ou presque) là où c'est prévu
• Confirmez que les comparaisons YoY/MoM utilisent les bonnes périodes de base
• Validez que les filtres sont appliqués de manière cohérente à toutes les métriques

Appliquez les techniques de vérification de plausibilité des résultats ci-dessous (contrôles de magnitude, validation croisée, détection de signaux d'alarme).

5. Évaluer les visualisations

Si l'analyse comprend des graphiques :

• Les axes commencent-ils à des valeurs appropriées (zéro pour les diagrammes à barres) ?
• Les échelles sont-elles cohérentes entre les graphiques de comparaison ?
• Les titres des graphiques décrivent-ils avec précision ce qui est montré ?
• La visualisation pourrait-elle induire en erreur un lecteur pressé ?
• Y a-t-il des axes tronqués, des intervalles incohérents ou des effets 3D qui déforment la perception ?

6. Évaluer le récit et les conclusions

Examiner si :

• Les conclusions sont étayées par les données présentées
• Les explications alternatives sont reconnues
• L'incertitude est communiquée de manière appropriée
• Les recommandations découlent logiquement des résultats
• Le niveau de confiance correspond à la force des preuves

7. Suggérer des améliorations

Fournir des suggestions spécifiques et exploitables :

• Des analyses supplémentaires qui renforceraient les conclusions
• Des mises en garde ou limitations à noter
• De meilleures visualisations ou cadrages pour les points clés
• Un contexte manquant que les parties prenantes souhaiteraient connaître

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

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

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

Partager avec des réserves notées -- L'analyse est en grande partie correcte mais présente des limitations ou hypothèses spécifiques qui doivent être communiquées aux parties prenantes. Lister les réserves nécessaires.

Nécessite une révision -- Des erreurs spécifiques, des problèmes méthodologiques ou des analyses manquantes ont été trouvés et doivent être résolus avant le partage. Lister les changements requis par ordre de priorité.

Format de sortie

## Rapport de validation

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

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

### Problèmes trouvés
1. [Gravité : Élevée/Moyenne/Faible] [Description du problème et impact]
2. ...

### Vérifications par sondage des calculs
- [Métrique] : [Vérifié / Écart trouvé]
- ...

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

### Réserves nécessaires pour les parties prenantes
- [Réserve qui doit être communiquée]
- ...

---

Liste de contrôle de qualité pré-livraison

Parcourez cette liste de contrôle avant de partager toute analyse avec les parties prenantes.

Vérifications de qualité des données

• Vérification de la source : Confirmé quelles tables/sources de données ont été utilisées. Sont-elles les bonnes pour cette question ?
• Actualité : Les données sont suffisamment récentes pour l'analyse. Date "en date du" notée.
• Exhaustivité : Aucun écart inattendu dans les séries temporelles ou segments manquants.
• Gestion des valeurs nulles : Taux de valeurs nulles vérifiés dans les colonnes clés. Les valeurs nulles sont traitées de manière appropriée (exclues, imputées ou signalées).
• Déduplication : Confirmé l'absence de double comptage dû à des jointures défectueuses ou à des enregistrements source en double.
• Vérification des filtres : Toutes les clauses WHERE et tous les filtres sont corrects. Pas d'exclusions involontaires.

Vérifications des calculs

• 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 de pourcentage utilisent le bon dénominateur. Les dénominateurs sont non nuls.
• Alignement des dates : Les comparaisons utilisent la même longueur de période. Les périodes partielles sont exclues ou notées.
• Exactitude des jointures : Les types de JOIN sont appropriés (INNER vs LEFT). Les jointures plusieurs-à-plusieurs 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. Tout écart est noté.
• Somme des sous-totaux : Les parties totalisent le tout là où c'est prévu. Si ce n'est pas le cas, expliquez pourquoi (par exemple, chevauchement).

Vérifications de plausibilité

• Magnitude : Les nombres se situent dans une plage plausible. Les revenus ne sont pas négatifs. Les pourcentages sont entre 0 et 100 %.
• Continuité des tendances : Aucun saut ou chute inexpliqué dans les séries temporelles.
• Référence croisée : Les chiffres clés correspondent à d'autres sources connues (tableaux de bord, rapports précédents, données financières).
• Ordre de grandeur : Le chiffre d'affaires total est dans la bonne fourchette. Les décomptes d'utilisateurs correspondent aux chiffres connus.
• Cas limites : Que se passe-t-il aux limites ? Segments vides, périodes sans activité, nouvelles entités.

Vérifications de présentation

• Exactitude des graphiques : Les diagrammes à barres commencent à zéro. Les axes sont étiquetés. Les échelles sont cohérentes entre les panneaux.
• Formatage des nombres : Précision appropriée. Formatage cohérent des devises/pourcentages. Séparateurs de milliers si nécessaire.
• Clarté des titres : Les titres énoncent l'information clé, pas seulement la métrique. Les plages de dates sont spécifiées.
• Transparence des réserves : 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 jointures

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

Comment détecter :

-- Vérifier le nombre 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 (oups)

Comment prévenir :

• Toujours vérifier le nombre de lignes après les jointures
• Si les comptages augmentent, examinez la relation de jointure (est-ce vraiment 1:1 ou 1:plusieurs ?)
• Utilisez COUNT(DISTINCT a.id) au lieu de COUNT(*) lors du comptage d'entités via des jointures

Biais de survie

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 actuels" omet les utilisateurs désabonnés
• Regarder les "entreprises utilisant notre produit" ignore celles qui ont évalué et sont parties
• Étudier les propriétés des résultats "réussis" sans les résultats "infructueux"

Comment prévenir : Demandez "QUI n'est PAS dans cet ensemble de données ?" 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 :

• "Les revenus de janvier sont de 500 K€ contre 800 K€ en décembre" -- mais janvier n'est pas encore terminé
• "Les inscriptions de cette semaine sont en baisse" -- vérifié mercredi, en comparant à une semaine complète précédente

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

Déplacement du dénominateur

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é la façon de compter les utilisateurs "éligibles"
• Le taux de désabonnement change parce que la définition de "actif" a été mise à jour

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

Moyenne des moyennes

Le problème : La moyenne de moyennes pré-calculées donne des résultats erronés lorsque les tailles de groupe diffèrent.

Exemple :

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

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

Décalages de fuseaux horaires

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

Exemples :

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

Comment prévenir : Normalisez tous les horodatages à 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 terminé l'intégration ont une meilleure rétention" -- évidemment, ils se sont auto-sélectionnés
• "Les utilisateurs expérimentés génèrent plus de revenus" -- ils sont devenus expérimentés EN générant des revenus

Comment prévenir : Définissez les segments en fonction des caractéristiques antérieures au traitement, pas des résultats.

Autres pièges statistiques

• Paradoxe de Simpson : La tendance s'inverse lorsque les données sont agrégées par rapport à segmentées
• Corrélation présentée comme causalité sans preuve à l'appui
• Petites tailles d'échantillon conduisant à des conclusions peu fiables
• Valeurs aberrantes affectant démesurément les moyennes (les médianes devraient-elles être utilisées à la place ?)
• Tests multiples / cherry-picking de résultats significatifs
• Biais de regard vers l'avant : Utiliser des informations futures pour expliquer des événements passés
• Plages temporelles choisies qui favorisent un récit particulier

Vérification de plausibilité des résultats

Contrôles de magnitude

Pour tout chiffre clé de votre analyse, vérifiez qu'il passe le "test d'odeur" :

Type de métrique	Vérification de plausibilité
Décomptes d'utilisateurs	Cela correspond-il aux chiffres connus de MAU/DAU ?
Revenus	Cela se situe-t-il dans le bon ordre de grandeur par rapport au ARR connu ?
Taux de conversion	Est-ce entre 0 % et 100 % ? Cela correspond-il aux chiffres du tableau de bord ?
Taux de croissance	Une croissance MoM de 50 %+ est-elle réaliste, ou y a-t-il un problème de données ?
Moyennes	La moyenne est-elle raisonnable compte tenu de ce que vous savez de la distribution ?
Pourcentages	Les pourcentages de segments totalisent-ils environ 100 % ?

Techniques de validation croisée

1. Calculez la même métrique de deux manières différentes et vérifiez qu'elles correspondent
2. Vérifiez ponctuellement des enregistrements individuels -- choisissez quelques entités spécifiques et tracez leurs données manuellement
3. Comparez à des références connues -- recoupez avec des tableaux de bord publiés, des rapports financiers ou des analyses antérieures
4. Rétro-ingénierie -- si le revenu total est X, est-ce que le revenu par utilisateur multiplié par le nombre d'utilisateurs est approximativement égal à X ?
5. Vérifications aux limites -- que se passe-t-il lorsque vous filtrez sur un seul jour, un seul utilisateur ou une seule catégorie ? Ces micro-résultats sont-ils sensés ?

Signaux d'alarme justifiant une enquête

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

Normes de documentation pour la reproductibilité

Modèle de documentation d'analyse

Chaque analyse non triviale devrait inclure :

## Analyse : [Titre]

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

### Sources de données
- Table : [schéma.nom_table] (en date du [date])
- Table : [schéma.autre_table] (en date du [date])
- Fichier : [nom_fichier] (source : [d'où il vient])

### Définitions
- [Métrique A] : [Exactement comment elle est calculée]
- [Segment X] : [Exactement comment l'appartenance est déterminée]
- [Période] : [Date de début] à [date de fin], [fuseau horaire]

### Méthodologie
1. [Étape 1 de l'approche d'analyse]
2. [Étape 2]
3. [Étape 3]

### Hypothèses et limitations
- [Hypothèse 1 et pourquoi elle est raisonnable]
- [Limitation 1 et son impact potentiel sur les conclusions]

### Principaux résultats
1. [Résultat 1 avec preuves à l'appui]
2. [Résultat 2 avec preuves à l'appui]

### Requêtes SQL
[Toutes les requêtes utilisées, avec commentaires]

### Réserves
- [Ce que le lecteur doit savoir avant d'agir sur ceci]

Documentation du code

Pour tout code (SQL, Python) susceptible d'être réutilisé :

"""
Analyse : Cohortes de rétention mensuelles
Auteur : [Nom]
Date : [Date]
Source de données : table events, table users
Dernière validation : [Date] -- les résultats correspondaient au tableau de bord à 2 % près

Objectif :
    Calculer les cohortes de rétention mensuelles des utilisateurs en fonction de la date
    de première activité.

Hypothèses :
    - "Actif" signifie au moins un événement dans le mois
    - Exclut les comptes de test/internes (user_type != 'internal')
    - Utilise les dates UTC tout au long

Sortie :
    Matrice de rétention des cohortes avec des lignes cohort_month et des colonnes
    months_since_signup. Les valeurs sont des taux de rétention (0-100 %).
"""

Contrôle de version pour les analyses

• Sauvegardez les requêtes et le code dans un système de contrôle de version (git) ou un système de documentation partagé
• Notez la date de l'instantané des 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 les versions antérieures des analyses récurrentes pour la comparaison des tendances

Exemples

/validate-data Examinez cette analyse trimestrielle des revenus avant que je l'envoie à l'équipe de direction : [analyse]

/validate-data