Differential expression analysis is a foundational computational method in genomics that applies statistical hypothesis testing to high-throughput transcriptomic data—such as RNA-seq or microarray counts—to determine which genes are up-regulated or down-regulated between conditions. The process models raw count data using distributions like the negative binomial distribution to account for biological overdispersion, then applies tests such as the Wald test to estimate the significance of the observed log2 fold change for each gene.
Glossary
Differential Expression Analysis
What is Differential Expression Analysis?
Differential expression analysis is the statistical process of identifying genes whose expression levels show a significant quantitative change between two or more experimental conditions or biological groups.
The workflow requires rigorous normalization to remove technical biases from sequencing depth and library composition, followed by multiple testing correction—typically the Benjamini-Hochberg procedure—to control the False Discovery Rate (FDR) across tens of thousands of simultaneous tests. Tools like DESeq2, edgeR, and limma-voom implement empirical Bayes shrinkage to stabilize variance estimates, producing ranked gene lists that serve as the input for downstream pathway enrichment and biomarker discovery pipelines.
Core Statistical Components
The statistical engine of differential expression analysis relies on a precise interplay of probability distributions, hypothesis testing, and error control. These components transform raw count data into biologically meaningful lists of regulated genes.
The Negative Binomial Model
RNA-seq produces discrete count data with overdispersion—the variance exceeds the mean due to biological and technical noise. The Negative Binomial distribution models this explicitly with two parameters: the mean and the dispersion. Unlike the Poisson distribution, which assumes variance equals the mean, the Negative Binomial accommodates the extra variability inherent in biological replicates. Tools like DESeq2 and edgeR are built on this foundation, using it to calculate the probability of observing a given count under the null hypothesis.
Dispersion Estimation & Shrinkage
Accurately estimating the dispersion parameter for each gene is critical but challenging, especially for genes with low counts where estimates are noisy. Empirical Bayes shrinkage solves this by borrowing information across all genes. It shrinks individual gene dispersion estimates toward a common trend, stabilizing values and preventing false positives from inflated variability. This is a core differentiator of DESeq2 and edgeR and is essential for experiments with small sample sizes.
Hypothesis Testing: The Wald Test
Once dispersion is modeled, the question becomes: is the observed change statistically significant? The Wald test is a parametric test that divides the estimated log2 fold change by its standard error to produce a test statistic. This statistic is then compared to a standard normal distribution to generate a raw p-value. The test evaluates the null hypothesis that the log2 fold change is exactly zero for each gene individually.
Multiple Testing Correction
Testing 20,000 genes simultaneously at a standard p < 0.05 threshold guarantees hundreds of false positives. Multiple testing correction is mandatory. The Benjamini-Hochberg procedure controls the False Discovery Rate (FDR)—the expected proportion of false positives among all discoveries. An FDR cutoff of 0.05 means that, on average, 5% of the genes on your significant list are expected to be false leads, a far more interpretable metric than a corrected p-value.
The Design Matrix
The design matrix is the mathematical blueprint of your experiment. It encodes which samples belong to which conditions and includes any known covariates like batch or patient age. This matrix is fed into the generalized linear model, instructing the algorithm on how to partition the variance. A correctly specified design matrix is the single most important defense against confounding; a flawed design will produce statistically significant but biologically meaningless results.
Normalization for Compositional Bias
Raw counts cannot be compared directly between samples because of differences in sequencing depth and library composition. A few highly expressed genes can skew the apparent expression of all others. Methods like the Trimmed Mean of M-values (TMM) in edgeR and the median-of-ratios approach in DESeq2 calculate sample-specific size factors. These factors act as scaling constants to make samples comparable, effectively removing technical artifacts before differential testing begins.
Frequently Asked Questions
Clear, technically precise answers to the most common questions about the statistical methods and computational workflows used to identify genes with altered activity between experimental conditions.
Differential expression analysis is the statistical process of identifying genes whose expression levels show a significant quantitative change between two or more experimental conditions or biological groups. The workflow begins with a matrix of raw read counts from RNA-seq or microarray experiments, where rows represent genes and columns represent samples. After normalization to correct for technical biases like sequencing depth and library composition, a statistical model—typically based on the negative binomial distribution for count data—is fit to estimate the magnitude of change (log2 fold change) and its associated uncertainty for each gene. A hypothesis test, such as the Wald test or likelihood ratio test, then determines whether the observed change is statistically significant, followed by a multiple testing correction procedure like the Benjamini-Hochberg method to control the False Discovery Rate (FDR) across thousands of simultaneous tests. The final output is a ranked list of genes with adjusted p-values and fold changes, which researchers use to prioritize candidates for downstream functional validation.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Master the statistical and computational foundations that underpin differential expression analysis workflows.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us