Entrepôt de Données

Les entrepôts de données SaaS modernes utilisent une architecture ELT (Extract, Load, Transform) cloud-native. Les données brutes sont extraites des systèmes sources (Salesforce, Zendesk, Stripe, Amplitude, base de données d'application PostgreSQL) via des connecteurs dédiés (Fivetran, Airbyte, Stitch), chargées dans l'entrepôt sous forme brute (Snowflake, BigQuery ou Redshift fournissent l'entrepôt cloud), puis transformées en modèles analytiques structurés à l'aide d'une couche de transformation (dbt — data build tool — est dominant). Les données propres et modélisées qui en résultent sont servies aux outils de BI (Looker, Metabase, Tableau) pour une analyse en libre-service. Les Product Ops et Support Ops y accèdent via des tableaux de bord pré-construits, tandis que les analystes interrogent directement en SQL. L'entrepôt permet de répondre à des questions qu'aucun système opérationnel seul ne peut résoudre : "Quel est le score CSAT pour les clients ayant plus de 5 tickets au cours de leurs 30 premiers jours, ventilé par niveau de forfait ?"

L'entrepôt de données débloque des cas d'utilisation analytiques transversaux que les outils opérationnels ne peuvent pas prendre en charge. Principaux cas d'utilisation pour les Support Ops : prévision du volume de tickets (combinant les données historiques du helpdesk avec le calendrier de sortie des produits et les tendances saisonnières), suivi des performances des agents (CSAT et AHT au fil du temps avec une signification statistique), et modélisation de la déviation (corrélation des lectures d'articles du centre d'aide avec l'évitement ultérieur de tickets). Principaux cas d'utilisation pour les Product Ops : analyse de la rétention de cohorte (combinant les données d'événements produit avec les données de facturation pour étudier comment l'adoption des fonctionnalités affecte les taux de renouvellement), analyse de l'entonnoir d'activation (entonnoir complet du clic d'e-mail à l'activation et à la conversion), et mesure de l'impact des fonctionnalités (comparaison des métriques comportementales avant et après une expérience). Le thème unificateur : ces analyses nécessitent de combiner des données provenant de plus de 3 systèmes sources, ce qui n'est possible qu'à travers un entrepôt centralisé.

La gouvernance des données garantit que l'entrepôt fournit des métriques fiables et cohérentes plutôt que des chiffres contradictoires provenant de différentes équipes utilisant différentes définitions. Les pratiques de gouvernance essentielles : un registre des définitions de métriques (une définition documentée et convenue pour chaque métrique clé — "CSAT" signifie exactement ce champ de cette table, calculé de cette manière) ; un catalogue de données (index consultable de toutes les tables et de leur objectif, avec des descriptions au niveau des champs maintenues par les propriétaires de tables) ; la surveillance de la qualité des données (alertes automatisées lorsque les valeurs des métriques clés s'écartent anormalement des tendances historiques) ; les contrôles d'accès (sécurité au niveau des lignes et des colonnes pour les données sensibles) ; et un processus de contrat de données (les équipes qui consomment des données d'un système source sont informées avant les changements de schéma qui briseraient leurs modèles). Les Product Ops co-gèrent généralement la gouvernance des données avec l'équipe Data Engineering.