Minimal-Prior Policy
This page is the short operating rule for prior-setting in DSAMbayes. Use it when you want a compact default policy. For the full workflow logic, see Stage 2: Model and Priors. For the mechanics of YAML and API prior specification, see Priors and Boundaries.
Purpose
Use a principled but low-friction prior setup that avoids specification-hunting while preserving identifiability in short, collinear MMM datasets.
Policy
- Default-first: keep
priors.use_defaults: true. - Sparse overrides: only add
priors.overridesfor high-conviction terms. - Selective bounds: add
boundaries.overridesonly for structural signs. - No blanket constraints: do not force all controls/media to one sign by default.
- Diagnose before tightening: use pre-flight and diagnostics gates first, then add priors/bounds if uncertainty is still unstable.
YAML mapping
When to override defaults
- Do override when domain mechanism is stable and defensible.
- Do not override only to improve one run’s fit metrics.
- Do not add bounds if sign can plausibly flip under promotion, pricing, or substitution effects.
Review checklist
- Are overrides fewer than the number of major business assumptions?
- Is each bound tied to a concrete causal rationale?
- Did diagnostics indicate a real identifiability problem before tightening?
When to use this page
- Use this page when you need a concise prior-setting policy for routine MMM work.
- Use Stage 2: Model and Priors when you need the reasoning behind that policy.
- Use Priors and Boundaries when you need exact DSAMbayes syntax, scaling rules, or boundary mechanics.