Across dbt-nexus, we treat proportions as the default way to represent fractional amounts in the data warehouse, and percentages as a presentation concern in BI tools, apps, and formatted exports.

Best practice: store proportions

• A proportion is a number on [0, 1] (or unbounded in edge cases, but still a ratio), e.g. 0.25 for one quarter.
• A percentage in everyday language is the same value scaled to [0, 100] (e.g. 25), or shown with a “%” suffix. That scaling belongs in the display layer, not in the warehouse as the canonical numeric type.

Why prefer proportions in the database?

• They behave correctly under addition, averaging, and SQL math without carrying an implicit “divide by 100” everywhere.
• They align with how many APIs and statistics libraries represent rates.
• You avoid mixed conventions (some models in 0–100, some in 0–1) when joining or aggregating.

Ingestion and modeling

• When a source delivers values on a 0–100 scale, convert to a proportion as early as possible in the pipeline (e.g. in staging, base, or normalized models: divide by 100) and use clear column names.
• Name stored columns to reflect the semantics, e.g. *_proportion (or allocation_proportion, drift_proportion), not *_percent or *_pct for warehouse fields.

Presentation

• In SQL for human-readable strings, in spreadsheets, and in app UI, multiply by 100 (and apply labels like “%” or “pp” where appropriate) at read time.
• Do not store “percent” as the primary numeric form unless a downstream contract explicitly requires it and the tradeoff is documented.

In short: proportions in the warehouse, percentages at the point of display.