PyMC-Marketing is excellent in a Jupyter notebook. You can read the data, fit a model, plot the posterior, and inspect every assumption in a single afternoon. For research, prototyping, and ad hoc analysis, that is exactly what you want. The trouble starts when MMM becomes a recurring business process and the notebook is still the only way the model exists.
The notebook honeymoon
Most MMM programs start with one analyst, one notebook, and one quarterly readout. The analyst tunes priors, fits the model, screenshots the response curves, and presents to the team. Decisions get made. Everyone is happy. This is the honeymoon.
Then someone asks: can we run this monthly? Can we add a new channel? Can the agency see the latest output? What happened to last quarter's model? Why did the ROI for paid search change so much between refreshes? At this point the notebook starts to creak, not because PyMC-Marketing is wrong, but because a notebook was never designed to be a long-running business workflow.
Where notebooks break down at scale
- Data preparation is rebuilt from memory each refresh
- Stakeholders cannot read or rerun the notebook themselves
- Model versions, priors, and inputs are not consistently logged
- Charts are exported manually and pasted into slides
- Scenario analysis requires the analyst to be online and available
- New channels mean editing code, not configuration
None of this means the notebook approach is bad. It just means notebooks are a development surface, not a production surface. MMM that drives real budget decisions usually needs both.
The stakeholder access problem
Marketing decision-makers do not generally read Python. CFOs do not run cells. CMOs want to see the response curve and ask what happens if we move 20 percent of TV into paid social. A notebook can answer that, but only with the analyst in the loop. A UI lets that conversation happen synchronously, in a meeting, on a phone if needed.
Reproducibility and audit trail
Bayesian MMM models are sensitive to inputs: different priors, different windows, different channel groupings can move ROI estimates significantly. When the same notebook gets re-run with slightly different code each refresh, it gets very hard to answer the basic question: what changed and why?
- Snapshot of the input dataset for each model run
- Saved configuration: priors, transformations, channel structure
- Diff view between this refresh and the previous one
- Persistent links to results stakeholders can revisit
Standardizing the model is a feature
One of the underrated benefits of a UI is that it constrains choices. In a notebook, an analyst can change anything between runs. In a product, the model has a defined shape, and changes are deliberate. That is exactly what business stakeholders need: the model should not change beneath them every refresh.
Notebook vs UI: which surface for which job
| Job | Notebook | UI like SIMBA |
|---|---|---|
| Initial research | Excellent | Limited |
| One-off custom analysis | Excellent | Limited |
| Recurring quarterly model | Workable | Designed for it |
| Scenario planning with non-technical users | Painful | Native |
| Audit trail and version history | DIY | Built in |
| Multi-brand or multi-market rollouts | Heavy lifting | Configurable |
When to keep notebooks
- You are still figuring out the model design
- You are running a one-off bespoke analysis that does not need to repeat
- You need to extend PyMC-Marketing with a custom transformation or likelihood that is not yet in the platform
- You are publishing research or a case study where the code is part of the artifact
When to add a UI
- MMM is going to be refreshed regularly, not as a one-time project
- More than one stakeholder needs to interact with the results
- Scenario planning needs to happen in real time, not via async requests to the analyst
- Different brands or markets need their own version of the same model
- Compliance, audit, or governance teams need to inspect what was run when
How SIMBA combines both
SIMBA does not replace PyMC-Marketing. The platform is built on top of it. The modeling engine is the same engine your data scientists already trust. What SIMBA adds is the operational layer: dataset management, configurable model structure, results dashboards, scenario planning, budget optimization, and an audit trail. Technical teams can still go deep through our MCP Server, our APIs, and our notebook integrations. Business teams get a UI that does not require a Python REPL to use.
For more on the methodology underneath, see Bayesian MMM, and for the full product workflow visit the marketing mix modeling software page.
If you have an existing PyMC-Marketing notebook and want to see what it looks like once it is wrapped in a real product workflow, book a 30 minute walkthrough.