Définit un tableau de bord comme un produit de mesure versionné avec des décisions nommées, un grain métrique, des dimensions, des filtres, des règles de comparaison, de la fraîcheur, des tests de qualité, des contrôles d’accès et un forage traçable.
Statut du package : contexte de référence prêt pour revue humaine. Le contrat et les scénarios de test sont complets, mais aucune affirmation n’est faite qu’une implémentation adoptante les ait validés.
Décision
Commencer par les décisions que le tableau de bord supporte, puis définir chaque métrique à partir de données gouvernées à un grain explicite. Afficher le fuseau horaire, la couverture, la fraîcheur, les filtres, la période de comparaison et l’état de qualité sur le tableau de bord lui-même.
Portée
- Public, décisions, définitions métriques, grain, dimensions, filtres, temps, comparaisons, objectifs, forage, fraîcheur, qualité, accès et propriété.
- Tableaux de bord opérationnels ou produits soutenus par des modèles analytiques gouvernés.
- Mise en œuvre et preuves d’acceptation.
Hors de ce bloc
- Utiliser une collection de graphiques comme substitut à une question décisionnelle.
- Combiner des métriques définies différemment parce que leurs étiquettes se ressemblent.
Contrat
- Chaque tableau de bord nomme le public, les décisions, le propriétaire, le propriétaire des données, l’objectif de rafraîchissement et le dernier rafraîchissement réussi.
- Chaque métrique spécifie numérateur, dénominateur, inclusion/exclusion, unité, grain, agrégation, champ temporel, fuseau horaire et version.
- Les dimensions définissent le comportement null/inconnu et si les filtres modifient numérateur, dénominateur ou cohorte.
- Les comparaisons utilisent des périodes équivalentes complètes sauf indication explicite de période partielle.
- Les tuiles exposent l’état qualité/fraîcheur et n’affichent jamais de données périmées comme actuelles sans avertissement.
- Le forage conserve le contrôle d’accès et le contexte des filtres et se réconcilie avec l’agrégé dans la latence documentée.
Guide de mise en œuvre
- Construire les modèles sémantiques et les tests avant les calculs spécifiques à la visualisation.
- Utiliser une table calendrier pour la logique des périodes et étiqueter clairement les grains utilisateur, événement, compte et transaction.
- Garder la configuration du tableau de bord et les définitions métriques sous contrôle de version.
- Fournir une annotation en langage clair pour toute modification de définition de matériel ou de source.
Gestion des échecs et protections
- Si un test qualité critique échoue, cacher ou marquer les métriques affectées plutôt que de publier des chiffres plausibles.
- En cas de retard de rafraîchissement, conserver les dernières données valides avec leur horodatage et un avertissement visible.
- Si un utilisateur n’a pas accès aux lignes, les filtres, comptages, exports et forage appliquent tous la même politique.
Vérification et exploitation
- Mesurer la durée/échec du rafraîchissement, le retard source, le résultat des tests qualité, le delta de réconciliation, la latence des requêtes, l’usage par chemin décisionnel et les liens de forage cassés.
- Tester les combinaisons de filtres, les frontières de fuseau horaire, les périodes partielles, les cohortes vides et l’accès au niveau ligne.
- Revoir avec les propriétaires de tableau de bord les tuiles inutilisées ou non actionnables.
Les exemples à l’apparence exécutable dans ce package sont des fixtures et contrats d’acceptation. Exécutez
python tools/validate.py depuis la racine de la collection pour vérifier la structure et les métadonnées du package ; puis
implémentez et exécutez les scénarios dans le dépôt cible.
Hypothèses d’adoption
- Les noms et valeurs numériques dans
example.yamlsont un profil d’adoption, pas des valeurs par défaut universelles. - L’équipe adoptante doit mapper acteurs, classes de données, vocabulaire d’erreur et propriété à son système.
Références
- Aucune source normative externe n’est requise ; ce package définit une décision de projet.