Hi everyone. I've been reading about Meta's new open-source attribution model, the "Marketing Mix Model" (MMM) library they released. As someone who mostly works with deterministic last-touch attribution in our pipelines, this is a bit out of my comfort zone, but I'm curious.
I'm nervous about introducing a complex statistical model into our production data workflows. The example code I saw uses PyStan and Bayesian inference. My team's stack is Airflow for orchestration, pulling data from various platforms into BigQuery, and then dbt for transformation. The thought of running MCMC sampling in a production DAG is a bit scary.
Has anyone started integrating something like this? My main questions are:
* How do you handle the **compute cost and time** for these models in a scheduled pipeline? Is it feasible, or do you run it offline?
* What does the **input data preparation** look like? Our current fact tables are at the click/impression level. The Meta example needs aggregated time series data like weekly spend and conversions. Does that mean building a separate, highly aggregated pipeline?
* How do you **version and monitor** the model's output? If the model suddenly attributes 70% of conversions to a new channel, how do we sanity-check that it's the model and not a data pipeline bug?
Here's a snippet from their documentation that shows the data structure they expect. It's very different from our granular event streams.
```python
import pandas as pd
# Example of the expected input format
data = {
'date': pd.date_range(start='2023-01-01', periods=52, freq='W'),
'sales': [...], # Total conversions per week
'tv_spend': [...],
'search_spend': [...],
'social_spend': [...]
}
# ... model fitting with Stan
```
I'm interested in moving beyond last-touch, but I need patterns that are safe and reliable in a production environment. Are there simpler incremental steps, or is diving into a full Bayesian MMM the way to go? Any war stories or best practices would be really helpful.
Your nerves are the most rational part of this. Let's address your actual questions.
> How do you handle the compute cost and time for these models in a scheduled pipeline?
Feasible? Technically. Sensible? Almost never. You're signing up to run a statistical simulation as a cron job. The compute time for a decent MCMC run isn't predictable, and that's before you account for the cost of a beefy machine idling in Airflow. Every team I've seen try this ends up running it offline in a notebook, manually, because putting a non-deterministic, long-running process into a DAG is a reliability nightmare. Your DBT runs are seconds, this is hours.
On the aggregated pipeline question - yes, you'll need a completely separate pipeline. That's the hidden cost everyone glosses over. You're not transforming your existing granular data; you're building a parallel, summarized dataset that loses all the detail your current fact tables hold. So now you're managing two truths: your operational data and your model's curated input.
Versioning and monitoring? If the model flips attribution 30% week over week, you won't know if it's because of the data, the sampling randomness, or an actual market shift. You're trading a simple, wrong answer for a sophisticated, unexplainable one.
Maybe ask what business decision actually requires this complexity.
Test the migration.