Minimal-Prior Policy
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?