written by Eric J. Ma on 2026-07-23 | tags: bayesian outliers automation hierarchy statistics reproducibility dose response data analysis
Bayesian modeling with heavy-tailed likelihoods and hierarchical structure automates away manual data analysis tasks like hand-flagging outliers. By using Student-t likelihoods and partial pooling, your pipeline handles messy data points and weird curves in a principled, reproducible way. No clicking through software required. What could your team do with all those afternoons back?
If you've ever spent an afternoon clicking through dose-response curves, flagging outliers by hand, there's a way to make the model do that automatically.
People usually talk about Bayesian modeling in terms of richer uncertainty estimates, prior knowledge, and posterior distributions. All true, and all worth the switch on their own. But there's a benefit almost nobody talks about. Going Bayesian automates away the manual data analysis you'd otherwise do by hand. And once you experience it, you wonder how you ever worked any other way.
Let me show you what I mean.
Picture a cell viability assay lab. Each 96-well plate holds five dose-response curves. An eighteen-plate experiment generates ninety curves in a single run, and your group is already eyeing robotics and 384-well formats to multiply throughput further.
I've seen workflows where a single study generates anywhere from 125 to 375 curves. Each one gets inspected by hand.
For every curve, there's usually a point or two that looks off. The standard workflow goes like this: copy raw data from the instrument output, paste it into Excel to line up sample names with plate positions, then copy again into GraphPad Prism to plot and fit the curve. Spot a deviating point, hit a shortcut key to mark it as an outlier, exclude it, refit. Then look again. Maybe another point looks suspicious now. Repeat. And pray you didn't misalign a paste somewhere along the way.
For one curve, it'll be seconds, but multiply this over dozens of plates and you have an unbounded amount of time spent clicking on a UI (if one's lucky) or switching between two applications, Excel and GraphPad Prism (if one is unlucky).
Are you really going to hire more research assistants to click through curves? That approach collapses under its own weight.
Now, a quick but important distinction. There are two completely different reasons to exclude a data point.
The first is a documented physical cause. You saw a bubble in the well. The pipette tip fell off. The reagent looked cloudy. These are data integrity issues, and you can justify removing them before you look at any numbers; in fact, you should document these in your lab records.
The second reason is that a point is statistically inconvenient. It sits too far from the curve and inflates your error. That second reason is the one I want to talk about, because it's both common and statistically broken.
Excluding a point because it's statistically inconvenient has two deep problems.
The first is reproducibility. What's your rule for calling something an outlier? Two standard deviations from the fit? Three? The classic tools, like Grubbs' test or the ROUT method that Prism builds in, hand you a threshold. But where did that threshold come from? It's a cutoff someone picked, not a principle someone derived. Two analysts staring at the same curve flag different points, because the decision rests on an arbitrary line in the sand. You're eyeballing with extra steps.
Here is curve 11 from the demo above, reviewed by two different analysts. Dilution 4 reads 100%, which looks like it belongs to the upper plateau. But the transition zone expects something closer to 73% at that dilution. Analyst A keeps it; Analyst B removes it. Toggle between them and watch the ID50 shift.
Same data, same software, different ID50. The point at dilution 4 sits right at the inflection of the curve, so keeping or removing it swings the estimate of where the curve crosses 50%. Which analyst is right? Both think they are, and without a principled criterion, neither can prove the other wrong.
The second problem is subtler, and it's the one that actually corrupts your results. When you run a test like Grubbs', the test assumes your data come from a clean normal distribution with at most one contaminating point. But dose-response data violate this assumption doubly. The raw points along a dose-response curve don't come from a single normal distribution at all; they follow a sigmoidal shape. You'd have to apply Grubbs' to residuals after fitting, but those residuals are often heteroscedastic (more variance at certain concentrations than others), which breaks the test's assumptions even further. With only five to eight dilutions per curve, the test has almost no power to distinguish a genuine outlier from noise. So you find the outlier, remove it, then refit your curve as if that contamination never existed. Your uncertainty estimates now lie to you. They don't account for the decision you already made. You've baked the removal into your results without propagating the uncertainty that choice introduced.
This isn't just my opinion. Karch demonstrated in a paper literally titled "Outliers May Not Be Automatically Removed" that automatic removal invalidates confidence intervals and biases your estimates (Karch, 2023). The APA Publication Manual itself states plainly that omitting troublesome observations to present a more convincing story is prohibited (APA, 2020). And the FDA's Bioanalytical Method Validation guidance is even more direct: repeat analysis is acceptable only for assignable causes such as equipment failure, sample processing errors, or poor chromatography. "It looked like an outlier" is conspicuously absent from that list.
Here's where Bayesian modeling changes the game. Instead of fitting a curve and deciding afterward which points to throw away, you choose a likelihood (the part of your model that scores how well the data fits) that handles outliers from the start.
The normal distribution, the bell curve you know, has thin tails. Probability drops off fast as you move away from the center. A single point sitting far from the curve becomes astronomically unlikely under a normal likelihood, and the only way the model can reduce that penalty is to drag the entire fit toward the outlier. One bad point yanks your curve.
The Student-t distribution fixes this. It looks like a normal bell curve, but with heavier tails. More probability spills into the extremes. So when a point sits way off the curve, the likelihood essentially shrugs and says, "that's rare, but not impossible," and the fit barely moves. The further the point drifts from the trend, the less pull it exerts. Its influence fades gradually rather than being a binary in-or-out decision.
Here is the elegant part. The Student-t has a parameter called the degrees of freedom (nu) that controls how heavy the tails are. At nu=1, you get the canonical Student-t distribution with the heaviest tails; outliers barely register. As nu increases, the tails thin out, and the distribution converges toward the Normal. At nu=30 or above, they are nearly indistinguishable. You can put a prior (your belief about the parameter before seeing data) on nu and let the data tell you how much outlier tolerance each dataset needs. The model learns its own robustness.
And critically, the point is never deleted. It still contributes to the fit, just with proportionally less weight. Your data stays intact.
Enough theory. Let me show you what this actually looks like on a dose-response curve with a real outlier.
The blue curve is the Normal likelihood fit; the orange dashed curve is the Student-t. Dotted vertical lines mark each model's ID50 estimate. Shaded bands are 94% credible intervals from 4,000 posterior draws (PyMC/NUTS, 4 chains). The buttons go from nu=1 (the Student-t at its heaviest-tailed, most forgiving of outliers) to nu=30 (nearly indistinguishable from the Normal, least forgiving).
Here is what to watch for. At nu=1, the outlier is absorbed by the heavy tails; the orange curve and its ID50 stay put, right where they belong. At nu=30, the orange and blue curves nearly overlap; the distribution has thinned into a Normal, and the outlier drags the ID50 leftward just like the blue curve does. The interesting territory is nu=3 to nu=5, where the model starts caring about the outlier but doesn't let it dominate. That is the sweet spot for most assay data.
But this demo handles one weird point on one curve. What happens when an entire curve is the outlier?
Heavy tails solve the point-level problem. But some curves are weird all on their own. Maybe one dose-response curve came out noisy across every well, or the shape is off in a way that suggests a systematic issue for that row.
This is where hierarchical modeling earns its keep. Instead of fitting each curve in isolation, a hierarchical model fits all of them together. Each curve borrows strength from the others through a shared population distribution. A noisy curve with a couple of strange wells gets gently pulled toward the behavior of its neighbors. Statisticians call this partial pooling.
The philosophy mirrors the heavy tails, just one level up. Heavy tails down-weight weird points. Hierarchy regularizes weird curves. It's the same idea, merely applied at different scales.
Six curves from the same experiment. Five came out clean; curve 3 had a bad day with noisy wells. Toggle between independent fits (curve 3 flails) and hierarchical fits (curve 3 borrows strength from the population and snaps into shape). The faint dashed line on curve 3 shows where the population says it should sit.
Here's where everything converges. Once you write down your hierarchical model with a heavy-tailed likelihood, you fit it to all eighteen plates at once. The sampler runs. Heavy tails handle the outlier points. Hierarchy handles the outlier curves. The whole thing runs without a single human judgment call.
I built a prototype of exactly this for a cell viability assay workflow.
Thirty-six plates. Four minutes. On a laptop.
How would you feel about that instead of spending your afternoon doing it by hand?
No shortcut keys. No research assistants clicking through Prism. No two-analysts-flag-different-points problem. The model handles the data analysis decisions you used to make by hand, and it makes them in a principled, reproducible, mathematically grounded way.
This is the hidden benefit of going Bayesian. People talk about richer uncertainty, prior knowledge, posterior distributions. All genuine advantages. But the automation of manual data analysis is the one that compounds as your experiments scale. Every new plate, every new study, every new operator, the model just handles it. You get your afternoons back, and your results become reproducible by construction.
If this resonates, find a statistician or data scientist who works with Bayesian tools. Show them your curve-fitting workflow and ask: "Can we use a hierarchical model with a Student-t likelihood for this?" If they know Bayesian modeling, they'll know exactly what you mean.
Going Bayesian isn't just about better statistics. It's about building a data analysis pipeline that scales without breaking, handles messy data without manual intervention, and gives you answers you can trust as your experiments grow. The math does the work so your team can focus on the science.
@article{
ericmjl-2026-going-bayesian-automates-data-analysis,
author = {Eric J. Ma},
title = {Going Bayesian automates your manual data analysis},
year = {2026},
month = {07},
day = {23},
howpublished = {\url{https://ericmjl.github.io}},
journal = {Eric J. Ma's Blog},
url = {https://ericmjl.github.io/blog/2026/7/23/going-bayesian-automates-data-analysis},
}
I send out a newsletter with tips and tools for data scientists. Come check it out at Substack.
If you would like to sponsor the coffee that goes into making my posts, please consider GitHub Sponsors!