What Meta-Analysis Support Actually Covers
On this page
- Feasibility assessment comes first
- Choosing the effect measure
- Model selection
- Heterogeneity assessment
- Building the actual figures
- Sensitivity and subgroup analysis
- Publication bias assessment
- Interpreting and writing up the result
- Reproducibility
- Common statistical software for meta-analysis
- When meta-analysis support means saying no to pooling
- Communicating uncertainty in your written results
Meta-analysis support is often reduced, in people's expectations, to "running the statistics." In practice, the consulting work that most affects whether your pooled estimate holds up under peer review happens before you touch a statistical package, and continues well after you have a result.
Feasibility assessment comes first
Not every set of included studies should be pooled. Before running anything, meta-analysis support starts with assessing whether your studies are similar enough in population, intervention, comparator, and outcome definition to produce a meaningful pooled estimate, or whether the honest answer is a narrative synthesis instead. This judgment call, made explicitly and early, prevents the far more damaging outcome of publishing a misleading pooled number that averages over genuinely different effects.
Choosing the effect measure
The right effect size metric depends on your outcome type and how it was measured across studies -- risk ratio or odds ratio for dichotomous outcomes, mean difference or standardized mean difference for continuous ones, with the choice between mean difference and standardized mean difference itself depending on whether studies used the same measurement scale. Getting this choice wrong at the start creates problems that surface much later in the process.
Model selection
Fixed-effect and random-effects models rest on different assumptions about your included studies, and the choice should be justified against your actual heterogeneity, not defaulted to whichever produces a tighter confidence interval. This decision should be specified in your protocol before you see the pooled result, for the same reason your eligibility criteria are pre-specified.
Heterogeneity assessment
Beyond just reporting an I-squared value, meaningful heterogeneity assessment means investigating what's driving it -- through subgroup analysis, meta-regression for continuous moderators, or a close read of which specific studies are producing outlier estimates. This is often the single most consulting-intensive part of the entire process, since it requires genuine judgment rather than a mechanical calculation.
Building the actual figures
Forest plots and funnel plots need to be built correctly and read clearly -- proper weighting displayed, axis labels correctly oriented, and a diamond that accurately reflects your chosen model. This sounds mechanical but is a common source of avoidable errors, particularly axis direction mistakes that invert the apparent direction of effect.
Sensitivity and subgroup analysis
Testing how robust your pooled estimate is to specific decisions -- excluding a particular study, using an alternative model, restricting to studies at low risk of bias -- is expected in a rigorous meta-analysis and should be planned rather than run ad hoc after seeing an unexpected result.
Publication bias assessment
With a sufficient number of included studies, this means a funnel plot alongside a formal asymmetry test, honestly interpreted rather than run as a box-ticking exercise.
Interpreting and writing up the result
The final piece of meta-analysis support is translating a statistical output into a clearly written results and discussion section -- stating the pooled effect size in terms a non-statistician reader can interpret, connecting the heterogeneity findings to a genuine explanation where one exists, and calibrating the confidence of your conclusions to what your GRADE certainty rating actually supports.
Reproducibility
Good meta-analysis support delivers not just a number but the underlying statistical code -- R, Stata, or another package -- documented well enough that you, your committee, or a journal's statistical reviewer could rerun the analysis and get the same result. This reproducibility is increasingly expected rather than optional, and building it in from the start is far easier than reconstructing it after the fact.
Common statistical software for meta-analysis
R, using packages like metafor or meta, has become the most widely used environment for meta-analysis given its flexibility and the transparency of sharing actual analysis code alongside a manuscript. Stata's meta suite offers similar core functionality with a different syntax and is common in fields where Stata is already the standard analytical tool. RevMan remains standard specifically for Cochrane-methodology reviews, integrated directly into Cochrane's broader review production workflow. The choice often comes down to what your target journal, institution, or collaborators are already using, more than any strict technical superiority of one over another for standard pairwise meta-analysis.
When meta-analysis support means saying no to pooling
Part of genuine meta-analysis support is being willing to recommend against pooling when the underlying studies don't support it, even when a client arrives expecting a single pooled number as the deliverable. Very high heterogeneity without a clear, identifiable source, a small number of studies with markedly different populations, or outcome measures too inconsistent to standardize meaningfully are all legitimate reasons to recommend a narrative synthesis instead. This is sometimes an uncomfortable conversation, but presenting a misleading pooled estimate because it was the expected output does more harm to a review's credibility than an honest narrative synthesis ever would, and a consultant who won't have that conversation isn't serving the review's actual scientific integrity.
Communicating uncertainty in your written results
Even a well-executed meta-analysis often produces a result with real uncertainty attached, and part of good statistical support is helping translate that uncertainty into plain language a non-statistician reader can actually use -- distinguishing clearly between "we found no effect" and "we did not have enough evidence to detect an effect," two conclusions that sound similar but mean genuinely different things for how a reader should act on your findings. Getting this distinction right in your own writing, and not just understanding it internally, is part of what separates a genuinely useful statistical write-up from one that technically reports the right numbers but leaves readers to draw the wrong practical conclusion from them. A pooled estimate with a wide confidence interval spanning both a meaningful benefit and a meaningful harm is genuinely informative -- it tells you the current evidence cannot yet support a confident decision either way -- and communicating that honestly is more useful to a reader than quietly downplaying the width of the interval to make the finding sound more settled than it actually is. This same discipline extends to how you frame a null result -- reporting the actual confidence interval rather than a bare non-significant statement gives readers the information they need to judge for themselves whether the evidence genuinely rules out a meaningful effect or simply hasn't yet accumulated enough precision to say either way.