An outcome that counts things: absences, citations, incidents, visits. Why counts need their own model, the single assumption that most count data violates, and how to report it in APA 7.
A count outcome is a non-negative whole number: how many absences, how many incidents, how many publications. Ordinary regression is a poor fit because it will predict negative counts and fractional events, and because count data is almost always right-skewed with a pile-up at zero.
Poisson regression models the log of the expected count as a linear function of the predictors. Exponentiating a coefficient gives an incidence rate ratio: the multiplicative change in the expected count for a one-unit change in the predictor. An IRR of 1.30 means the expected count is 30% higher.
That interpretation is more intuitive than an odds ratio, which is one of the reasons this model is worth using rather than logging the outcome and running OLS.
The Poisson distribution carries one strong constraint: the variance equals the mean. A process with an average of 3 events is assumed to have a variance of 3.
Real count data rarely obliges. Human behavior clusters. A few people account for most of the absences, most of the incidents, most of the citations, so the variance runs well above the mean. This is overdispersion, and it is the normal case rather than the exception.
The consequence is specific and serious: coefficients stay roughly unbiased, but standard errors come out too small. Confidence intervals are too narrow and p values are too small, so an overdispersed Poisson model manufactures significance.
Check it before interpreting anything. The usual diagnostic is the ratio of residual deviance to residual degrees of freedom; a value near 1 is consistent with Poisson, and much above 1 indicates overdispersion. The standard remedies are a negative binomial model, which adds a dispersion parameter, or quasi-Poisson standard errors. Reporting an overdispersed Poisson model as though the assumption held is the main failure mode of this analysis.
Excess zeros are a related problem. Where far more zeros appear than the model expects, often because part of the sample was never at risk of the event, a zero-inflated model addresses it and a plain Poisson does not.
Counts usually accumulate over unequal opportunity. Ten incidents in a ward of 200 patients is not ten incidents in a ward of 20. Comparing raw counts across units with different exposure produces a finding about size rather than about rate.
The correct handling is an offset: the log of the exposure variable, entered with its coefficient fixed at 1. That converts the model from one about counts to one about rates, which is nearly always the question of interest.
The alternative that looks reasonable and is not: dividing the count by exposure and running linear regression on the resulting rate. That discards the count structure and reintroduces the problems the Poisson model exists to solve.
Lay the data out one row per unit, with the count in one column, predictors in others, and an exposure column where opportunity varies.
Keep the outcome as a raw count. Do not pre-convert it to a rate or a proportion.
Configure the outcome and predictors in the Setup panel on the right and the result appears in the center panel.
Look at the mean and variance of the outcome before you model it. If the variance is several times the mean, you already know a plain Poisson model will understate the uncertainty.
Report incidence rate ratios with confidence intervals, and state that dispersion was checked.
Each additional year of tenure was associated with a lower expected absence count, IRR = 0.94, 95% CI [0.90, 0.98], p = .003, with exposure modelled as an offset for days employed. The dispersion ratio was 1.08, consistent with the Poisson assumption.
Report the dispersion check with its value. It is the single most informative diagnostic for this model and its absence is the first thing a methods reviewer will look for.
State the offset explicitly, including which variable represented exposure.
Where you moved to a negative binomial model, say why. The overdispersion that prompted it is a substantive fact about your outcome, not a technical footnote.
Every result carries a ReliCheck Intelligence card with one action: explain this result in plain language. It runs entirely on your Mac with Apple Intelligence. No upload, no API key, nothing to configure. The model only explains the result Quanta has already computed and validated. It never computes a statistic, and it never applies a decision on your behalf.
From the action bar you can add the result to a report, copy the table, or copy the APA text. Exported reports carry the APA table, its note, and a caution specific to that analysis beneath it.
Quanta's logistic, Poisson, and ordinal regressions are validated against R's glm and MASS::polr, with coefficients matched to 1e-3. The engine is pure Swift with no R or Python at runtime. Full record on the validation page.
Regression is part of every Quanta subscription, $9.99 a month or $79.99 a year after the 30-day trial. One price for everyone. See pricing.
The analysis, the report builder, and the on-device explanations all work with the network off. Your dataset is never uploaded.
Logistic regression for a binary outcome · Multiple linear regression for a continuous outcome · Ordinal regression for ordered categories · the complete list on the analyses page.