Whympr Data Warehouse - Plateforme Analytics Engineering pour KPIs produit et business

Conception et industrialisation d’un Data Warehouse multi-sources avec dbt, DuckDB et Superset pour piloter conversion, rétention, usage et monétisation.
Auteur·rice

Nicolas Decoopman

Mots clés

Data Warehouse, Analytics Engineering, dbt, DuckDB, Superset, Docker, CI/CD, GA4, RevenueCat, SQL, tests de données

1 Introduction

FIABILISER LES KPI PRODUIT ET MONÉTISATION DANS UN PIPELINE QUOTIDIEN TESTÉ DE BOUT EN BOUT.

Impact & reconnaissance
  • Le projet a livré 3 dashboards Superset (Performance, Utilisation, Conversion), alimentés par des modèles dbt versionnés et testés.
  • L’exploitation tourne chaque jour à 05:00 (Europe/Paris) : extraction, transformation, puis mise à jour des éléments opérationnels.
  • Un runbook VM documente les procédures de démarrage, vérification et gestion d’incident pour rendre la maintenance reproductible.
Pilier Synthèse factuelle
Big Data Le pipeline consolide trois sources hétérogènes : GA4 (comportement), RevenueCat (transactions) et Whympr (données applicatives), avec une progression lisible sources -> staging -> clean -> build -> marts.
Ingénierie Un orchestrateur Python exécute 4 extractions successives, puis lance dbt build. Les jeux de données finaux sont ensuite exploités dans Superset et documentés via Quarto.
Statistiques Les KPI sont encadrés par des règles métier testées : fenêtres lifecycle à 30 jours, logique churn, et contrôles de cohérence sur rétention/monétisation.
Industrialisation La qualité est sécurisée par des contrôles automatisés (sqlfluff, ruff, pytest, dbt parse, dbt-checkpoint) et un pipeline Docker (build, smoke tests Superset, scans sécurité/secrets) avant production.

Le challenge technique

  • Unifier des sources hétérogènes avec des contraintes réelles de disponibilité et de conformité (GA4/BigQuery, RGPD, flux RevenueCat).
  • Maintenir un niveau de qualité exploitable métier avec des tests data systématiques et des conventions de grain dbt.
  • Garantir une exécution quotidienne stable en environnement conteneurisé, avec observabilité opérationnelle et documentation de runbook.

2 Contexte et problématique

Le besoin était de passer d’indicateurs dispersés à une couche analytique fiable pour les décisions Produit et Business : conversion, rétention, usage et monétisation. Le dépôt formalise ce périmètre comme objectif principal du Data Warehouse et impose une définition partagée des métriques entre équipes.

L’enjeu réel est double :

  • réduire les écarts d’interprétation entre équipes sur les mêmes KPI,
  • industrialiser le calcul de ces KPI pour qu’ils soient reproductibles et auditables à chaque exécution.

3 Données

Sources intégrées dans le pipeline :

  • Google Analytics 4 : événements comportementaux et parcours utilisateur.
  • RevenueCat S3 + RevenueCat API mapping : transactions et référentiels d’abonnement.
  • Base applicative Whympr : données produit et identité applicative.

Caractéristiques techniques clés :

  • Pipeline déclaré : sources -> staging -> clean -> build -> marts.
  • Exécution extraction orchestrée en 4 étapes (python -m src.extract).
  • Transformation centralisée via dbt (dbt build) sur DuckDB.
  • Standardisation des schémas en staging (cast typés, normalisation timezone Europe/Paris, harmonisation des clés techniques).
  • Contrat de grain explicite par modèle (1 ligne = 1 utilisateur/jour, 1 ligne = 1 transaction) pour éviter les duplications silencieuses en aval.

4 Approche et méthodologie

4.1 Workflow

  1. Extraction orchestrée des 4 flux sources (GA4, RevenueCat S3, Whympr, mapping RevenueCat API).
  2. Transformation et tests via dbt build / dbt test selon conventions de modélisation.
  3. Publication des marts vers Superset (dashboards D1/D2/D3) et documentation Quarto.
  4. Exécution planifiée quotidienne (cron à 05:00 Europe/Paris) avec journalisation opérationnelle.

4.2 Design technique des modèles

  • Pattern de modélisation : séparation stg_* (renommage + typage), int_* (règles métier intermédiaires), fct_* / dim_* (consommation BI).
  • Clés et jointures : usage de clés substituts stables (hash) quand l’identifiant source n’est pas globalement fiable, puis jointures sur clés documentées.
  • Fenêtres analytiques SQL : window functions (lag, lead, row_number, sum() over (...)) pour churn, lifecycle et cohortes sans logique imperative.
  • Qualité embarquée : tests not_null, unique, relationships, accepted_values + tests SQL custom sur bornes KPI.
  • Documentation vivante : description des colonnes critiques et exposition des dépendances via le DAG dbt pour auditabilité.

4.3 Performance et exploitation

  • Incrémentalisation ciblée des modèles volumineux pour limiter les temps de run et conserver un refresh quotidien soutenable.
  • Partitionnement logique temporel (jour/semaine/mois selon use case) pour réduire le scan et améliorer la latence des dashboards.
  • Observabilité pipeline : logs structurés par étape d’extraction/transformation, check de complétude (volumétrie attendue vs observée), et alerting de base sur échec de run.
  • Idempotence opérationnelle : relance d’un run possible sans corruption des marts grâce aux règles de chargement déterministes.

4.4 Justification de l’architecture (frugalité et scalabilité)

  • Frugalité : stack locale/VM sur Docker Compose, base analytique DuckDB, coûts d’infrastructure limités sans complexifier l’exploitation.
  • Scalabilité : séparation claire des couches dbt (staging/clean/build/marts), industrialisation CI/CD, et possibilité d’extension des connecteurs (ex. Stripe Web) sans casser la chaîne existante.
  • Fiabilité : tests de qualité multi-niveaux (lint SQL/Python, tests unitaires, tests data dbt, smoke tests BI, scans sécurité).

4.5 Expertise technique et impact

4.5.1 Data Engineer

  • Orchestration pipeline : implémentation d’un orchestrateur Python modulaire pour les 4 flux d’extraction, réduisant la dette opérationnelle sur les runs quotidiens.
  • Modélisation analytique dbt : structuration en couches avec conventions de nommage et contrôle explicite du grain avant jointures.
  • Engineering SQL avancé : implémentation de modèles analytiques reposant sur CTE multi-étages, fonctions de fenêtre et règles de déduplication déterministes.
  • Industrialisation CI/CD : mise en place de quality gates complets (deptry, sqlfluff, ruff, pytest, dbt parse, dbt-checkpoint) + pipeline Docker de validation runtime.
  • Ops & runbook : documentation VM, scheduler, contrôle de santé et gestion des secrets pour un passage en exploitation robuste.

4.5.2 Data Scientist / Analytics Scientist

  • Cadre de mesure KPI : formalisation des indicateurs acquisition/engagement/rétention/monétisation avec définitions réutilisables.
  • Rigueur statistique appliquée : tests métier explicites sur fenêtres temporelles (30 jours lifecycle, 90 jours churn) et bornes de cohérence des métriques.
  • Fiabilisation des métriques : vérification systématique de la sensibilité des KPI aux changements de périmètre, aux retards de collecte et aux artefacts de tracking.
  • Analyse des limites de validité : documentation des biais structurels (GA4 thresholding, RGPD, Stripe Web incomplet) pour éviter les décisions sur indicateurs hors périmètre.
  • Activation décisionnelle : traduction des modèles en dashboards opérationnels utilisés par les fonctions marketing, produit et analytics engineering.

5 Technologies utilisées

  • Backbone : dbt, DuckDB, SQL, YAML
  • Compute : Python 3.12+, Pytest, Ruff, SQLFluff
  • Modeling : dbt-utils, tests de données SQL, règles de grain et contrôles de cohérence KPI
  • Infrastructure : Docker, Docker Compose, GitHub Actions, Trivy, Grype, scheduler cron VM
  • Vision / BI : Apache Superset, Quarto

6 Lien vers le projet

Projet réalisé en environnement privé/propriétaire. La démonstration s’appuie sur la documentation technique et les livrables KPI décrits dans ce portfolio.

7 Illustrations

Accueil du dashboard Data Warehouse

Accueil dashboard

Dashboard 1 Data Warehouse

Dashboard 1

8 Cas d’usage et perspectives

Cas d’usage actuels :

  • pilotage hebdomadaire de la conversion funnel (installation -> compte -> essai -> abonnement),
  • suivi de la rétention (J1/J7/J30, cohortes, win-back),
  • analyse produit par segments d’usage et fonctionnalités,
  • suivi monétisation (MRR, ARR, ARPU, ARPPU) sur le périmètre couvert.