Construire un dashboard

Un dashboard est une collection de tuiles d'insights sur une seule page. Ton rôle est de déterminer quels insights y appartiennent, réutiliser ce qui existe déjà, créer ce qui manque, et les organiser intelligemment — pas de générer aveuglément des graphiques.

Créer ou mettre à jour

Commence par déterminer si tu crées un nouveau dashboard ou tu modifies un existant.

• Cherche les dashboards existants avec dashboards-get-all (son paramètre search fait un fuzzy matching sur le nom/description). Si l'utilisateur décrit clairement quelque chose qui existe déjà, il demande probablement une mise à jour.
• Lis un candidat avec dashboard-get pour voir ses tuiles actuelles avant de rien changer.
• Si la demande est ambiguë — « réunis mes métriques financières » pourrait signifier construire du neuf ou ajouter à un existant — pose une courte question de clarification plutôt que de deviner.

Utilise les templates comme référence

PostHog fournit des templates de dashboard vérifiés pour les sujets courants, et les organisations peuvent partager les leurs. Consulte-les avant de construire — ils sont un signal fort de quels insights fonctionnent bien ensemble sur un sujet.

1. dashboard-templates-list — parcourt les templates (utilise search pour un sujet, scope pour te limiter à global / team / organization). Cela retourne seulement les noms, descriptions, et tags.
2. dashboard-templates-retrieve — ouvre le template le plus proche pour voir ses tiles : quels insights il groupe ensemble et comment chacun est interrogé.

Traite les templates comme des exemples, pas une spécification. Inspire-toi des insights et de leurs groupements, mais adapte chaque insight aux propres événements, propriétés, et intentions de l'utilisateur. Ne copie pas un template à la lettre, et ne force pas un template sur une demande qui ne le justifie pas — un bon dashboard sur mesure vaut mieux qu'un template mal adapté.

Sélectionne les insights

Préfère réutiliser les insights existants plutôt que de les recréer.

• Cherche avec insights-list et lis les prometteurs avec insight-get pour vérifier qu'ils correspondent à l'intention de l'utilisateur et qu'ils ont vraiment des données. La recherche full-text rate les choses nommées différemment, alors liste largement avant de conclure qu'un insight n'existe pas.
• Pour tout ce qui manque, crée-le avec insight-create (vois les skills d'insights product-analytics pour la forme de la requête).
• Garde l'ensemble minimal — seulement les insights que la demande nécessite. Un dashboard focalisé est plus utile qu'un exhaustif.

Assemble le dashboard

• Nouveau dashboard : dashboard-create avec un nom court (3–7 mots) et une description concise, puis ajoute les tuiles d'insights.
• Dashboard existant : dashboard-update. Ajouter, remplacer, ou supprimer des insights signifie envoyer l'ensemble complet des tuiles prévues — les insights que tu omets sont supprimés, donc inclus ceux que tu veux garder.
• Layout : par défaut préserve le placement des tuiles existantes. Reflow (dashboard-reorder-tiles) seulement quand l'utilisateur te demande explicitement de réarranger, réordonner, ou déplacer des tuiles.
• Vérifie avec dashboard-insights-run pour confirmer que les tuiles retournent des données, puis résume ce que tu as construit et invite l'utilisateur à l'affiner.

Quand ne pas utiliser cela

• Sauvegarder un seul insight — crée juste l'insight ; il n'a pas besoin de dashboard.
• Ajouter des tuiles widget non-insight (cartes de texte, widgets) — vois plutôt les outils widget (dashboard-widget-catalog-list, dashboard-widgets-batch-add).

Skills associés

• managing-subscriptions — livre le dashboard terminé par email ou Slack selon un planning
• creating-ai-subscription — un rapport écrit par IA récurrent, quand la prose vaut mieux qu'un mur de graphiques