High Dashboards system

Conversion Reporting Model

A defined, repeatable conversion model that fixes the full funnel math once — visitor/lead -> qualified -> booked -> completed -> won — with each stage's denominator, numerator, and conversion % pinned down so every report uses the same definitions. It is delivered as a documented SQL model (views) plus a report panel, not an ad-hoc chart someone rebuilds each month with different math. The model is the contract; the chart just renders it.

Start a Project All Systems

5 to 10 days: timeline
High: complexity
4: tools
4: steps

Built with real HMX dashboard tool paths

Supabase PostgresLayered SQL viewsNext.js 16 server componentsKPI definition docSupabase PostgresLayered SQL viewsNext.js 16 server componentsKPI definition doc

01 // System facts

System facts

Conversion Reporting Model uses a reporting model and review layer for Dashboards. A defined, repeatable conversion model that fixes the full funnel math once — visitor/lead -> qualified -> booked -> completed -> won — with each s... The architecture connects each funnel stage and its, supabase postgres, layered sql views, and reporting view with an explicit control path.

Outcome

Everyone reports the same conversion numbers from one source of truth — ending the 'your booking rate doesn't match mine' problem and making month-over-month comparisons actually valid.

Main risk

Definition drift: stages get interpreted differently over time (or excluded buckets shift), so 'conversion rate' silently means different things in different reports.

Prevention

Lock definitions in the model layer (views) and a written sheet, exclude buckets explicitly and visibly, and reconcile each stage as a subset so inconsistent math is caught automatically.

Fallback

If full-funnel signal is incomplete (e.g. no reliable 'won'), ship the model for the stages that are reliably tracked (lead->booked->completed) and mark later stages as 'not yet modeled' rather than faking them.

System architecture

Conversion Reporting Model Architecture

6 nodes

each funnel stage and its

Encode the model as layered

Supabase Postgres

Layered SQL views

Review Queue

Reporting View

01each funnel stage and its
A defined, repeatable conversion model that fixes the full funnel math once — visitor/lead -> qualified -> booked -> completed -> won — with each s...
02Encode the model as layered
Encode the model as layered SQL views: one stage-classification view over leads/bookings, one rates view computing stage-to-stage and overall conversion with the agreed denominators.
03Supabase Postgres
Supabase Postgres contributes the trusted model for Conversion Reporting Model so metrics are defined before they are visualized.
04Layered SQL views
Render a conversion report (server component) with the funnel, each stage rate, and prior-period comparison, all reading the same views so numbers can't diverge between screens.
05Review Queue
If full-funnel signal is incomplete (e.g.
06Reporting View
Everyone reports the same conversion numbers from one source of truth — ending the 'your booking rate doesn't match mine' problem and making month-...

How it is built

Build steps

01Define each funnel stage and its exact rule with the owner (what counts as 'qualified', does a reschedule still count as booked, are spam/partial excluded) and write it down as the canonical definition sheet.
02Encode the model as layered SQL views: one stage-classification view over leads/bookings, one rates view computing stage-to-stage and overall conversion with the agreed denominators.
03Render a conversion report (server component) with the funnel, each stage rate, and prior-period comparison, all reading the same views so numbers can't diverge between screens.
04Add a self-check row that reconciles stage counts (each stage subset of the prior) and exposes excluded buckets (spam/partial/unknown) so the math is auditable.

Tools

Workflow surface

Supabase Postgres
Layered SQL views
Next.js 16 server components
KPI definition doc

Inputs layer: Define each funnel stage and its exact rule with the owner (what counts as 'qualified', does a reschedule still count as booked, are spam/partial excluded) and write it down as the canonical definition sheet.
Transform layer: Encode the model as layered SQL views: one stage-classification view over leads/bookings, one rates view computing stage-to-stage and overall conversion with the agreed denominators.
Metrics layer: Supabase Postgres contributes the trusted model for Conversion Reporting Model so metrics are defined before they are visualized.
Visualization layer: Layered SQL views handles refresh, review, or reporting delivery while lock definitions in the model layer (views) and a written sheet, exclude buckets explicitly and visibly, and reconcile each stage as a subset so in...
Action layer: Everyone reports the same conversion numbers from one source of truth — ending the 'your booking rate doesn't match mine' problem and making month-...

Data flow

01Define each funnel stage and its exact rule with the owner (what counts as 'qualified', does a reschedule still count as booked, are spam/partial excluded) and write it down as the canonical definition sheet.
02Encode the model as layered SQL views: one stage-classification view over leads/bookings, one rates view computing stage-to-stage and overall conversion with the agreed denominators.
03Render a conversion report (server component) with the funnel, each stage rate, and prior-period comparison, all reading the same views so numbers can't diverge between screens.
04Add a self-check row that reconciles stage counts (each stage subset of the prior) and exposes excluded buckets (spam/partial/unknown) so the math is auditable.

Controls and fallbacks

Definition drift: stages get interpreted differently over time (or excluded buckets shift), so 'conversion rate' silently means different things in...
Lock definitions in the model layer (views) and a written sheet, exclude buckets explicitly and visibly, and reconcile each stage as a subset so in...
If full-funnel signal is incomplete (e.g.

Research basis