12 Presentation of Results
For Bayesian analysis, we consider that adopting a Bayesian workflow, rather than just Bayesian inference, is central to reducing most of the typical problems found in Bayesian data analysis (Gelman et al. 2020; Martin and Teste 2022). Such workflow is discussed in detail by (Gelman et al. 2020) and we provide a brief summary of it in Chapter 13. A report of the results of a Bayesian analysis should help reflect such workflow.
The presentation of the results will depend on the audience, the context, and the goals of the analysis. For example, a presentation for a scientific paper will be different from a presentation for a business meeting. However, there are some general principles that can be applied to any presentation of results. Additionally, modern Bayesian analysis can be a complex process, and it is important to present the results in a way that is clear and understandable for the audience. This can be achieved by using visualizations, summaries, and explanations that are tailored to the audience’s level of expertise and familiarity with Bayesian analysis. Usually, the results will be split into two parts, one that provides the most important results and a second part that provides more details for those who are interested in the technical aspects of the analysis. For example, for a scientific paper, the first part should be included in the main text, while the second part can be included in the supplementary material. For a business meeting, the first part can be presented in a slide deck, while the second part can be included in a report or a technical document. Additionally, many of the details could be included in the code itself, that is stored in a repository, so that interested readers can access it and reproduce the analysis. For scientific results public repositories like Zenodo, GitHub or GitLab can be used to store the code and data.
12.1 What to report?
Kruschke (Kruschke 2021) provides guidelines on what to report in a Bayesian analysis. These guidelines are based on his experience but also insights from previous recommendations. Here we reproduce a summary of his recommendations with some modifications and additions. Some of the differences reflect our own experience and preferences, for example we usually don’t recommend using Bayes factors, and instead we recommend using PSIS-LOO-CV for model comparison as discussed in Chapter 7.
- Explain the model.
- Explain the variables in your model, for regression models make it clear which are the dependent (predicted) variables and which are the independent (predictor) variables. Clearly distinguish between the parameters that are of direct interest for your analysis and those are solely required for the model to fit the data but not of direct interest. If the model is hierarchical/multilevel, be sure that the hierarchical structure is clearly explained.
- Explain and justify the prior distribution of the parameters in the model.
- Include a formal specification (mathematical or computer code) of the models. A graphical representations like plate-notation, like the ones generated by PyMC or Bambi can also help, especially for nonstandard models and/or more applied audiences.
- Report prior predictive checks (Chapter 5) to demonstrate that the prior generates simulated data consistent with the assumed prior knowledge.
- Report details of the computation
- Report the software used. This helps to ensure that the analysis can be reproduced. But it’s also a way to support the software developers, in particular if the software is open source.
- Report MCMC diagnostics as discussed in Chapter Chapter 4. For non-MCMC methods, Simulation-Based Calibration can be used to assess the quality of the inference (Chapter 11).
- Describe the posterior distribution
- Provide a posterior predictive check to show that the model usefully mimics the data (Chapter 5). Discuss mismatches between the model and the data, if any.
- Summarize posterior of variables. For continuous parameters, derived variables and predicted values, report the central tendency (usually mean or median) and credible intervals. Be clear if you are using HDI or ETI, and make it clear the mass of the credible interval (for example, 94%).
- Report decisions (if any) and their criteria
- Why decisions? Explain why the decisions are theoretically meaningful and which decision procedure is being used. Regardless of which decision procedure is used, if it addresses null values, it should be able to accept the null value not only reject it.
- Loss function. If utilities and a loss function for a decision rule are defined, these should be explained and reported.
- ROPE limits. If using a continuous-parameter posterior distribution as the basis for decision, state and justify the limits of the ROPE and the required probability mass.
- Decision threshold and model probabilities. If using model comparison or hypothesis testing as the basis for a decision, state and justify the decision threshold for the posterior model probability, and the minimum prior model probability that would make the posterior model probability exceed the decision threshold.
- Estimated values too. If deciding about null values, always also report the estimate of the parameter value (central tendency and credible interval).
- Report sensitivity analysis
- Use prior predictive checks and sensitivity analysis like the ones discussed in Chapter 6 to assess the robustness of the results to the choice of priors.
- If making decisions, report whether decisions change under different priors.
- Report alternative models
- Report the results of models that were discarded. This is important to assess the robustness of the results to the choice of model. Explain why these models were discarded and why the final model was chosen.
- If using PSIS-LOO-CV Chapter 7 for model comparison, report the expected log predictive density (ELPD) and the standard error of the ELPD. This is important to assess the robustness of the results to the choice of model. If the model comparison is not relevant, explain why it is not relevant.