Opérations et Bureau → Dashbord métriques et rapports

Dashboard métriques et rapports

1) Objet et portée

• une image instantanée de la santé des systèmes et de P&L,
• détection précoce des anomalies,
• transparence pour la direction et les équipes,
• l'unification des indicateurs pour les produits, les marchés et les régions.

Couverture : métriques opérationnelles (SLA, incidents), produits (activité, conversion), financières (GGR/NGR, ARPPU, LTV), marketing (CAC, ROMI), risques et conformité (KYC/AML, chargeback, fraude), support (SLA tickets).

2) Rôles et consommateurs

C-level/Direction : KPI consolidés, tendances par objectifs OKR, P&L, risques.
Opérations/AC : aptyme des services, alertes, files d'attente des tâches, incidents.
Produit/Croissance : entonnoirs, A/B, analyse de cohorte, rétention.
Finances : rapports journaliers/hebdomadaires sur les recettes et les dépenses, tranches d'impôt.
Conformité/Risque : Statuts KYC, modèles suspects, rapports pour le régulateur.
Support : SLA des réponses, NPS/CSAT, typologie des appels.

• Comptable : Propriétaire de Dashbord (Head of Ops/Analytics).
• Responsible : Commande de données/BI.
• Consulté : Produit, Finance, Risque, SRE.
• Informed : Chefs de direction.

3) Architecture de données et mises à jour

Sources : événements (stream), bases de données OLTP, logs, fournisseurs de paiement, CRM/Helpdesk, plateforme A/B.
Couche de traitement : ETL/ELT, streaming (pour T-15-T + 5 minutes), déduplication, validation de circuit, SCD.
Modèle : en forme d'étoile (fait du tableau par événements/transactions + mesures : temps, région, produit, canal).

• Temps réel : 1-5 minutes (bloc, alertes).
• Batch incrémental : 15-60 minutes (marketing/produit).
• Batch de clôture journalier : 01 : 00-03 : 00 (finances/conformité).
• Qualité des données : règles de validation (exhaustivité, unicité, fourchettes admissibles), surveillance des retards de pipline, contrôle de la dérive.

4) Catalogue KPI et formules (modèle)

4. 1 Opérations/SRE

Aptyme (%) = 1 − (temps d'arrêt/temps total) × 100

MTTR (Mean Time To Restore)

MTTA / MTTD (Mean Time To Acknowledge / Detect)

Erreur de requête (%) = erreur _ 5xx/toutes les _ requêtes

4. 2 Produit/Comportement

DAU/WAU/MAU

Retention D1/D7/D30

Conversion Funnel: Visit → Sign-up → KYC → Deposit → First Action

ARPPU = revenus/utilisateurs payants

LTV (t) = Σ (marge moyenne de la période × probabilité de rétention)

4. 3 Marketing/Croissance

CAC = dépenses de commercialisation/nombre de nouveaux payeurs

ROMI = (marge additionnelle − dépenses )/dépenses

CR par canal (SEO/ASO/Ads/Affiliates), Cohorts par date d'engagement

4. 4 Finances

GGR (chiffre d'affaires brut)

NGR = GGR − bonus − commissions de fournisseurs − taxes sur les jeux

Net Margin = (NGR − OPEX − CAPEX − traitement )/NGR

4. 5 Risque/Conformité

KYC Completion (%) = enregistrements vérifiés/nouveaux enregistrements

Taux de SAR (activités suspectes)

Taux de charge = chargbecky/transactions réussies

Fraud Score moyen/percentile

4. 6 Soutien

SLA ответов (P1/P2/P3), First Response Time, CSAT/NPS, Backlog Size

5) Dashboard Information Architecture

Accueil (Exécutif) : 8-12 cartes clés + sparklines, cartes thermiques par région, tendances YTD/MTD/WoW.
Panneau d'exploitation (Command Center) : Aptyme, alertes, files d'attente, incidents, performances API, retards ETL.
Produit/Croissance : Entonnoirs, grilles de cohortes, segments, A/B-MU (métriques d'effet).
Finances : GGR/NGR, marge sur les fournisseurs/marchés, paiements, traitement, taxes.
Risque/conformité : KYC, anomalies, drapeaux frod, rapports pour le régulateur.
Support : SLA, volume des appels, typologie, tickets répétés, VOC.

Navigation : filtres globaux (période, région, produit, plateforme, canal), presets rapides (Aujourd'hui/Hier/MTD/QTD/YTD), bouton « Drill-through » sur les détails.

6) Widgets et modèles de visualisation

Carte KPI : valeur actuelle, Δ à la période précédente, mini-sparkline, statut (vert/amber/rouge).
Entonnoir de conversion : tableau de bord par étapes, conversion entre les étapes, écart (%).
Matrice de cohorte : rétention par semaine/mois, échelle thermique.
Séries temporelles : valeurs journalières/horaires avec limites de contrôle (± 2 σ, ± 3 σ).
Tableau N : fournisseurs/canaux/régions avec une contribution à KPI, cliquable drill-down.
Carte thermique des incidents : densité par service × temps.
Sankei/Flow : flux d'utilisateurs/argent entre les étapes.
Geo-map : KPI par pays/région, couche de contraintes de conformité.

7) Signaux, alertes et seuils

Types : information, avertissement, critique.
Seuils : statiques (rigides) + dynamiques (en fonction de la saisonnalité et des variations historiques).
Modèles de notification : bref « ce qui s'est passé », contexte (gamme, tendance), hypothèses de cause, lien vers le panneau de détail, propriétaire de l'incident.
Déduplication des alerts : suppression des « burst », regroupement des signaux liés.
SLO par alerting : MTTA ≤ 5 min (critic.) , MTTR ≤ 30-60 min.

8) Accès et sécurité

RLS/CLS (Row/Column Level Security) : filtres par région et par juridiction.
PII/finaux : masquage et tokenization, accès minimum nécessaire.
Audit : qui regardait ce qu'il déchargeait, quels filtres il appliquait.
Versioning artefacts : Git pour SQL/visualisations et dictionnaire de métriques.

9) Règles de notification

Quotidien (D-reports) : coupe opérationnelle, incidents, RGG/RGG, deltas clés.
Chaque semaine : Retensh, canaux d'attraction, ROMI, frod-digest.
Mensuel : P&L, rapports de cohorte, KPI par rapport aux objectifs de l'OKR, rapports de conformité.
Sur demande : rapports pour les régulateurs/vérificateurs, A/B-résultats, post-mortems.

Tous les rapports sont générés à partir d'un seul dictionnaire de métriques et d'un seul modèle de données - pas de « Excel manuel avec une vérité alternative ».

10) Mise en œuvre : plan étape par étape

1. Inventaire des métriques : recueillir les indicateurs clés actuels, éliminer les prises/conflits.
2. Dictionnaire de métriques : ID, formule, propriétaire, sources, périodicité, seuils.
3. Modèle de données : faits/mesures, DCS, unités de mesure, chronologie.
4. Traitement slim : streaming pour les métriques « chaudes », batch pour la finance.
5. Les maquettes дашбордов : low-fi → high-fi, la coordination avec les rôles.
6. RLS/CLS et vie privée : accès, masquage, audit.
7. Alerting : règles, seuils, canaux (chat, courrier, PagerDuty, etc.).
8. Pilote et bêta : 2 à 4 semaines par verticale (p. ex. Opérations), collecte de fidback.
9. Formation et playbook : vidéos courtes/hyde, modèles de recherche.
10. Amélioration continue : améliorations backlog, sortie des notes de sortie.

11) Anti-modèles

« Dashboard Zoo » : des dizaines de versions d'un seul KPI sans un seul dictionnaire.
Rapports manuels : instabilité, risques d'erreurs et fuites de PII.
Détails excessifs sur l'écran d'accueil : « bruit d'information ».
Alert-spam : pas de priorité et de déduplication.
Sans propriétaire de métrique : une responsabilité floue → une « vérité » controversée.

12) Chèques-feuilles

Avant la sortie du dashboard

• Les KPI sont harmonisés, décrits et ont des propriétaires
• Unités de mesure et zones temporelles unifiées
• RLS/CLS configurés, PII masqué
• Seuils d'alertes vérifiés pour les données historiques
• Charge et mises à jour SLA testées
• Ongoarding-hyde et changelog publiés

Service mensuel

• Revoyez le dictionnaire des métriques (modifications, nouvelles métriques)
• Validation des sources et retards des pipelines
• Rétrospective des alertes (fausses/manquées)
• Améliorations UX : vitesse, filtres, presets

13) Exemples SQL/logique (simplifié)

ARPPU (diurne)

sql
SELECT d::date AS day,
SUM(revenue) / NULLIF(COUNT(DISTINCT CASE WHEN pay_count > 0 THEN user_id END), 0) AS arppu
FROM daily_user_finance
GROUP BY 1;

Cohorte par inscription (M1 MAU Retentation)

sql
WITH cohorts AS (
SELECT user_id, date_trunc('month', signup_at) AS cohort_month
FROM users
),
activity AS (
SELECT user_id, date_trunc('month', activity_at) AS active_month
FROM user_activity
)
SELECT cohort_month,
COUNT(DISTINCT user_id) FILTER (WHERE active_month = cohort_month) AS m0,
COUNT(DISTINCT user_id) FILTER (WHERE active_month = cohort_month + INTERVAL '1 month') AS m1,
ROUND(100. 0 COUNT(DISTINCT user_id) FILTER (WHERE active_month = cohort_month + INTERVAL '1 month')
/ NULLIF(COUNT(DISTINCT user_id) FILTER (WHERE active_month = cohort_month),0), 2) AS m1_retention_pct
FROM cohorts c
LEFT JOIN activity a USING (user_id)
GROUP BY 1
ORDER BY 1;

Alert sur les anomalies GGR (jour-à-jour)

sql
SELECT today. ggr,
yesterday. ggr,
(today. ggr - yesterday. ggr) / NULLIF(yesterday. ggr,0) AS delta
FROM revenue_daily today
JOIN revenue_daily yesterday ON yesterday. day = today. day - INTERVAL '1 day'
WHERE today. day = CURRENT_DATE
AND ABS((today. ggr - yesterday. ggr) / NULLIF(yesterday. ggr,0)) > 0. 25;

14) Localisation et multi-région

Taxonomie unique des pays/juridictions, devises, TVA/taxes de jeu.
Conversion de devises selon les règles fixées (end-of-day vs average).
Fuseaux horaires : stocker UTC, visualiser dans les localités de l'utilisateur.
Rapports réglementaires : modèles + paramétrage par pays.

15) Indicateurs de qualité du dashboard lui-même

Coverage : proportion des KPI clés disponibles dans le panneau.
SLA freshness : proportion de mises à jour dans la fenêtre déclarée.
Option : MAU dashboard, profondeur des sessions, préréglages enregistrés.
Décision Lag : temps moyen d'alerte à l'action prise.
Accuracy : proportion des écarts convenus <seuil admissible.

16) Résultat

Dashboard Metrics and Reporting n'est pas un ensemble de beaux graphiques, mais un outil de gestion avec un seul dictionnaire de métriques, un modèle de données durable, des SLA et des responsabilités claires. Son objectif est d'accélérer la prise de décisions, de réduire les risques opérationnels et d'améliorer la prévisibilité des résultats.