What problem does it solve?
Teams repeatedly re-derive the same metrics (MRR, activation, conversion) across dashboards and queries, producing inconsistent numbers. This Skill provides the shared foundations for turning a metric definition into a durable, reusable model on either PostHog-native data-warehouse views or an external dbt project.
Core Features & Use Cases
- Stack selection guidance: Decide between PostHog-native views (HogQL via view-create/view-materialize) and an external dbt project (staging/marts with schema tests), with an honest picture of PostHog's lack of native dbt integration.
- View lifecycle workflow: Write HogQL, create a virtual view, materialize it with a sync_frequency when it earns it, and clean up throwaway views — including the mandatory column-aliasing rule that causes most view-create failures.
- dbt project skeleton: Copy-paste starting files (dbt_project.yml, sources.yml, staging model, mart, schema.yml tests) for modeling PostHog and business data in your own warehouse.
- Joins, dimensions, and currency: Attach dimension tables via saved or person joins, and normalize multi-currency revenue with the built-in convertCurrency() HogQL function.
- Governance: Check the semantic layer for approved canonical metrics before deriving, and register models with column annotations after building.
- Use Case: A data analyst needs a company-wide MRR model. The Skill guides them to check the data catalog for an approved definition, then build it as a materialized PostHog view with aliased columns and convertCurrency() normalization, or as a dbt mart with uniqueness tests.
Quick Start
Ask the AI to help you build a reusable metric model in PostHog, starting by checking whether an approved definition already exists in the data catalog and choosing between a PostHog view and a dbt model.