Modéliser les métriques de revenu

Transformez vos données de paiement/abonnement en modèles de revenu durables. Lisez d'abord modeling-warehouse-foundations pour la décision view-vs-dbt, le workflow view-*, et convertCurrency() ; cette compétence est la couche spécifique au revenu qui s'ajoute. Les définitions des métriques se trouvent dans references/revenue-metric-definitions.md ; les recettes copier-coller dans references/posthog/ et references/dbt/.

Étape 1 — trouvez où vit le revenu

Le revenu atteint PostHog de deux manières ; les deux alimentent les mêmes *vues gérées `revenueanalytics`** :

• Une plateforme de paiement comme source d'entrepôt — Stripe actuellement (Chargebee/Polar/RevenueCat en cours). Idéal quand l'entreprise fonctionne sur une plateforme de facturation. Connectez via setting-up-a-data-warehouse-source.
• Événements de revenu personnalisés — vous envoyez des événements (ex. purchase_completed) avec une propriété de revenu. Idéal quand il n'y a pas de plateforme prise en charge ou que vous suivez déjà le revenu dans le produit.

Si aucun n'existe encore, utilisez suggesting-data-imports pour recommander une source. Dans dbt, l'équivalent est de préparer les tables de facturation qui se trouvent dans l'entrepôt.

Étape 2 — modélisez sur les vues gérées, pas les tables brutes

PostHog génère automatiquement un ensemble de vues organisées par source. Ne pas redériver le revenu à partir des tables Stripe brutes — les vues gérées gèrent déjà la reconnaissance du revenu différé, la devise, et un schéma stable.

Découvrez les noms exacts (ils sont préfixés par source, ex. stripe.<prefix>.…, plus un revenue_analytics.all.… multi-sources) :

SELECT table_name FROM system.information_schema.tables WHERE table_name ILIKE '%revenue_analytics%'

Colonnes clés de revenue_item : amount (déjà convertie en devise de base du projet), currency (cette devise de base), original_amount / original_currency (tels que facturés), is_recurring, customer_id, subscription_id, product_id, group_0_key…group_4_key (clés de compte B2B), timestamp.

Règles avant de modéliser (pièges du revenu)

1. MRR est vide sans une config d'abonnement. Pour le revenu basé sur les événements, MRR se remplit uniquement quand une propriété d'abonnement est configurée. Un MRR vide + un revenu brut rempli est un comportement attendu, pas un bug — dites-le au lieu de le « corriger ».
2. La vue gérée mrr est un snapshot actuel, pas historique (« MRR au moment actuel »). Pour le MRR au fil du temps, somme le amount récurrent par mois depuis revenue_item (voir la recette), ou matérialisez un snapshot mensuel de la vue mrr selon un calendrier.
3. amount est déjà en devise de base. Utilisez-le directement pour les rapports. N'appelez convertCurrency(original_currency, 'XXX', original_amount, timestamp) que quand vous avez besoin d'une devise cible différente, ou en travaillant à partir d'événements bruts.
4. Liez le revenu aux personnes via métadonnées. Le revenu au niveau personne/groupe a besoin de métadonnées posthog_person_distinct_id sur le client Stripe (ou la jointure personne). Sans cela, le revenu est au niveau client uniquement.
5. Ne construisez pas sur le tableau de bord Revenue — il sera retiré (~2026-06-30). Modélisez contre les vues revenue_analytics_* et les propriétés de revenu personne/groupe.
6. Excluez les comptes de test. Confirmez le comportement de filter_test_accounts afin que les charges d'assurance qualité/internes ne gonflent pas le revenu.

Étape 3 — construisez le modèle

PostHog : écrivez le HogQL (aliasez chaque colonne), view-create, vérifiez avec view-get, puis view-materialize les rollups mensuels coûteux (une sync_frequency quotidienne est généralement appropriée pour le revenu). Recettes : references/posthog/ — mrr_and_arr.sql, gross_revenue_by_month.sql, revenue_by_customer.sql.

dbt : préparez la source de facturation → fct_revenue_item, fct_mrr, dim_customer marts avec tests. Recettes : references/dbt/. Notez que dbt n'a pas de convertCurrency() — fournissez une graine de taux.

Ensuite, enregistrez le modèle (references/governance.md dans foundations) : annotez les colonnes et, si MRR/ARR est un nombre clé, proposez-le à la couche sémantique.

Plan des fichiers

Complémentaires

modeling-warehouse-foundations (mécaniques), setting-up-a-data-warehouse-source + suggesting-data-imports (faire entrer les données Stripe/revenu), modeling-dimension-tables (dimensions devise/plan), querying-posthog-data (HogQL + vérification des métriques de la couche sémantique).