Principled Bayesian Workflow

Purpose

Give DSAMbayes users a workflow-shaped mental model for Bayesian MMM. This section is the methodological spine of the docs: it explains the sequence of decisions, assumptions, and diagnostic gates that should sit behind any DSAMbayes run.

Audience

  • Econometricians moving from OLS or other frequentist MMM workflows into Bayesian modelling.
  • Analysts who know how to run DSAMbayes but want a more defensible modelling process.
  • Reviewers who need to understand what a “good” DSAMbayes run should have passed before interpretation.

Why this section exists

DSAMbayes already documents its runner, model classes, priors, and diagnostics in detail. What most users still need is a clear answer to:

  1. What is the modelling workflow?
  2. Where do priors come from?
  3. Which diagnostics matter most?
  4. When is interpretation allowed, and when should it stop?

This section answers those questions directly. Use it before reading the lower-level reference pages.

Workflow vectors

DSAMbayes workflow vectors DSAMbayes workflow vectors

Different operational entry points in DSAMbayes still converge on the same workflow contract. Whether you work interactively in R, use runme.R, or run the YAML / CLI path, the result should still pass the same prior, computation, and adequacy gates before interpretation.

Page Use it when…
What Principled Means You want the high-level contract for a Bayesian MMM workflow
Frequentist to Bayesian Translation You are used to OLS-style modelling and want a practical translation layer
Stage 2: Model and Priors You need guidance on priors, boundaries, and default-vs-override decisions
Stage 4: Computation and Sampler You need to know which post-fit diagnostics are non-negotiable
Stage 5: Model Adequacy You need to decide whether decomposition, model comparison, or optimisation outputs are trustworthy

Workflow contract

The workflow is easiest to remember as a sequence of questions:

Stage Core question Typical DSAMbayes surface What happens if it fails?
Problem framing What decision is the model supposed to support? Analyst design choice before code Re-specify the business question or estimand
Data and identifiability Is the data rich enough to support the claim? formula design, controls, pre-flight, design checks Rework data or narrow the modelling ambition
Model and priors Are the assumptions and priors defensible? blm(), set_prior(), set_boundary(), YAML priors/boundaries Re-specify assumptions before fitting
Computation and sampler Are the posterior draws numerically trustworthy? fit(), chain_diagnostics(), 40_diagnostics/ Do not interpret downstream outputs
Model adequacy Does the fitted model describe the data credibly? fit plots, PPC, residual diagnostics, LOO/Pareto-k Do not use decomposition or optimisation for decisions
Interpretation and decision Are we reporting uncertainty and caveats honestly? decomposition, response curves, optimisation Restrict or block business use

Two rules to remember

1. Passing sampler diagnostics is necessary, not sufficient

Good Rhat, ESS, and zero divergences mean the posterior draws are numerically credible. They do not prove the model is a good description of the data, and they do not prove causal validity.

2. Good fit is not causal proof

A model can fit well, calibrate well, and still estimate the wrong media effects if the identifying assumptions are weak. DSAMbayes can make the workflow more disciplined; it cannot remove the need for analyst judgment.

How this section relates to the rest of the docs

  • Workflow pages answer “what should I do and why?”
  • How-to pages answer “how do I perform this task right now?”
  • Reference pages answer “what exactly does this field, function, or plot mean?”