Stage 2: Model and Priors

Objective

Specify a model that is explicit enough to be audited and simple enough to be defended.

For most DSAMbayes users, this stage is where the biggest conceptual shift happens. In classical MMM, the common instinct is to choose variables, run the regression, and worry about coefficient stability afterwards. In DSAMbayes, priors and boundaries are part of the specification from the start.

The operating rule

Use a default-first workflow unless there is a strong reason not to.

That means:

1. start with the package defaults
2. add sparse sign constraints only where the business logic is structural
3. add sparse prior overrides only where the prior story is stable and defensible
4. fit the model
5. inspect whether the posterior is still dominated by weak design rather than by a sensible prior choice

This is the same operating stance documented in Minimal-Prior Policy, but framed here as part of the modelling workflow rather than as a standalone policy page.

Prior specification pathways

This is the short answer to “where should priors come from?” Defaults are the starting point. Boundaries and overrides are additive, sparse, and justified by business or structural reasoning. The blm(lm_object, data) path is the empirical-Bayes-like option when a credible legacy model already exists.

Where priors should come from

In DSAMbayes, priors should usually come from one of four sources.

1. Structural sign knowledge

Examples:

• additional media exposure should not reduce KPI
• competitor discount should not increase our sales

This is usually best expressed as a boundary, not as an aggressive mean-shifting prior.

2. Stable business knowledge about magnitude

Examples:

• price elasticity is probably negative and modest
• distribution is probably positive and not enormous

This is where a sparse override like normal(-0.2, 0.1) may be justified.

3. Historical learning from previous analyses

If the same brand, market, or response has been analysed repeatedly under a similar data-generating regime, you may have enough evidence to justify informative priors on a small number of terms.

4. Explicit regularisation when the data are weak

Sometimes priors are primarily there to stabilise a short, collinear MMM. That is acceptable, but it should be acknowledged honestly as regularisation rather than presented as deep subject-matter certainty.

Where priors should not come from

Do not set priors mainly because:

• one previous run looked better with them
• they remove a warning without improving model design
• they force a preferred channel ranking
• they make weak data look more certain than it really is

That is specification-hunting, not principled prior design.

Practical DSAMbayes policy

Step 1: start with defaults

For most first-pass BLM and hierarchical work, the package defaults are the right starting point.

• default coefficient priors are weakly informative
• default boundaries are unconstrained
• you should not feel obliged to invent bespoke priors on every term

Step 2: add selective boundaries

Use set_boundary() or YAML boundaries.overrides when the sign is structural and defensible.

Good examples:

• media terms constrained positive
• competitor discount constrained non-positive

Poor examples:

• constraining every control just to reduce posterior variance
• forcing signs on variables whose mechanism is genuinely ambiguous

Step 3: add sparse prior overrides only where conviction is real

Typical candidates:

• price
• distribution
• a small number of strategically important baseline controls

Typical non-candidates:

• every media term
• every generated seasonal component
• every term simply because the data are noisy

Step 4: keep the reasoning on the original outcome scale

DSAMbayes can scale internally when scale = TRUE, but your reasoning about priors should still happen on the original business scale. Ask:

• what outcome change would this prior imply?
• would that be plausible for this KPI?
• would I be comfortable defending it in a model review?

Prior predictive discipline in DSAMbayes

The Bayesian workflow ideal is to inspect prior implications before posterior fitting. In practical DSAMbayes use today, that discipline is still partly analyst-driven.

v1.3.3 does not yet provide a fully productised, first-class prior-predictive runner stage with its own public gate contract. So the current disciplined approach is:

1. keep the prior design simple
2. reason on the original outcome scale
3. avoid over-confident overrides unless they are well supported
4. fit the model and then inspect whether the posterior behavior is compatible with the prior story and the data

That makes the lack of a first-class prior-predictive stage a reason to be more conservative, not less.

Prior calibration and sensitivity loop

For DSAMbayes users, a prior grid is a robustness tool, not a scoring contest. Use it to check whether the substantive conclusion survives plausible prior choices. Do not use it to hunt for the prior that makes one run look best.

How to know whether the priors are doing sensible work

After fitting, ask:

Are the intervals still wide?

If yes, the data may simply be weak. Do not respond automatically by tightening priors.

Are signs unstable without a clear design reason?

Check the baseline structure, controls, collinearity, and response-scale choice before strengthening priors.

Are coefficients pinned to hard bounds?

That can indicate that the boundary is too strong, or that the model is trying to express a structure the current formula does not support well.

A simple prior-setting decision table

Cross-references

• Priors and Boundaries for the technical contract
• Minimal-Prior Policy for the concise governance rule set
• Your First BLM Model for concrete R API examples