Données analytics
Statut
Document de cadrage data — version initiale.
Objectif
Les données analytics doivent mesurer la valeur produit sans devenir intrusives.
Elles doivent aider à comprendre l'usage de DMV, des acteurs, communes, publications, favoris, PlayLoop, AssoSuite, Mairie et futures fonctionnalités IA.
État actuel visible
Une migration Supabase stats_events existe dans dmv-public/supabase/migrations.
Elle crée une table partitionnée mensuellement et des index par acteur, commune, type d'événement et session.
Le backend Laravel contient aussi un module Analytics avec routes et services visibles.
Types d'événements cibles
| Domaine | Exemples |
|---|---|
| DMV public | vues, clics, recherche, favoris. |
| Acteurs | consultation mini-site, contact, publication vue. |
| Communes | consultation services, alertes, mur de la ville. |
| PlayLoop | diffusion playlist, ping device, campagne. |
| AssoSuite | usage interne, publication associative. |
| Mairie | publication, alerte, service mis à jour. |
| IA | usage assistant, coût, résultat, refus quota. |
Principes RGPD et sobriété
- Collecter le minimum utile.
- Éviter l'identification personnelle si non nécessaire.
- Agréger quand l'analyse individuelle n'est pas utile.
- Conserver une durée limitée.
- Documenter les finalités.
- Séparer analytics produit et données opérationnelles.
Partitionnement
Le partitionnement mensuel est adapté aux événements analytics :
- volume important ;
- requêtes par période ;
- purge facilitée ;
- archivage possible.
Vision cible
La cible est un système analytics cohérent :
- source applicative ;
- commune ;
- acteur ;
- type d'événement ;
- session ou identifiant anonyme ;
- métadonnées limitées ;
- agrégats utilisables par backoffice et offres premium.
Points à clarifier
- Table canonique analytics : Supabase ou Laravel.
- Politique de rétention.
- Consentement et anonymisation.
- Dashboards backoffice.
- Analytics IA et coûts.