River
Y CombinatorBacked by Y Combinator

Research & PolicyFree tool

Statistical Methods Section From Your Code

A statistical methods section written from your analysis script: every model it fitted, the rows each one used, and the standard errors it requested.

Helpful to include

Free to start · Opens in your River workspace, ready to edit and share

How to write a statistical methods section

A statistical methods section, often headed "Statistical analysis," explains how you got from your data to the numbers in your results. A good one names the sample each analysis used and how you reached it, and describes each model: its outcome, covariates, estimator and standard errors. It also says how missing data were handled, which sensitivity or subgroup analyses you ran, and which software and versions you used.

The International Committee of Medical Journal Editors (ICMJE) sets a clear test: enough detail that a knowledgeable reader with access to the original data could verify the reported results1. The surest way to pass it is to write from the code that produced your tables. Your plan and your memory describe the analysis you meant to run; the code records the one that ran.

A bioinformatician at the National Cancer Institute works at a monitor showing a branching data analysis pipeline
Describe the analysis that actually ran, step by step, not the plan. Photo: National Cancer Institute on Unsplash

What goes in a statistical methods section

Start from the reporting guideline for your study design, and check whether your journal wants the completed checklist with your submission. Observational studies use STROBE, whose item 12 asks you to describe all statistical methods, explain how missing data were addressed and describe any sensitivity analyses2. Randomized trials use CONSORT 20253, which replaced the 2010 checklist and now asks who is included in each analysis.

The parts of a statistical methods section

PartWhat to reportExample
Analytic sampleWho was analyzed, how many, and how you got there"Of 4,102 respondents, 3,465 employees met the inclusion criteria."
ModelsFor each analysis, the outcome, covariates and estimator, as fitted"Job satisfaction was regressed on job demand, adjusting for tenure."
Standard errorsThe variance estimator and, if clustered, the grouping and number of clusters"Standard errors were clustered by employer (64 employers)."
Missing dataThe rule the software applied, and how many rows each model lost"Models used complete cases; Table S2 gives each model's sample size."
Other analysesSensitivity and subgroup analyses, each labeled prespecified or post hoc"A post hoc sensitivity analysis excluded part-time staff."
SoftwareThe language and every package that changed the numbers, with versions"Analyses used R 4.4.1 with the sandwich package (version 3.1-1)."

The example sentences are illustrative.

Say which method produced each result rather than listing every technique in one block. Then follow your journal's headings and order: the guideline says what to include, not where.

Work from the code, not the plan

Analyses drift while you work. A covariate gets added late, a filter moves into a cleaning script, and defaults settle questions you never asked. So before you write a sentence, list what the script actually does.

  1. List every model

    Give each model the script fits a row, in run order, whether or not it reached the paper.

  2. Copy the specification

    Record the outcome and covariates exactly as written, the estimator, and every option changed from its default.

  3. Count the rows each model used

    Read the number from the fitted model (nobs() in R, e(N) in Stata, .nobs in statsmodels), not from the dataset.

  4. Match tables to models

    Trace each table to the fitted object that produced it, and note any you can't trace.

Account for every missing row

Check what your software does with missing values before you describe it. R's lm() drops any row with a missing value in the model's variables, because its documented "factory-fresh" default is na.omit4. So every covariate you add can shrink the sample again, and two models in the same table can rest on different people.

In the BMJ, Jonathan Sterne and colleagues note that the cumulative effect of missing data in several variables often leads to exclusion of a substantial proportion of the original sample5. They ask for the number of missing values in each variable, or of complete cases in each important part of the analysis. If you imputed, name the method and its assumptions (for example, missing at random).

How a complete-case sample shrinks, one variable at a time

Variable addedRows lostRows left
Analytic sample03,465
Job demand633,402
Supervisor support543,348
Tenure2103,138
Contract type153,123
Overtime hours1,3941,729

Illustrative numbers. A row missing two variables is lost only once, so a step can lose fewer rows than that variable's own missing count.

Ask who the missing rows are

If a question was put only to some people, a model that uses it describes only them. Losing rows costs precision and can add bias; losing a whole group changes the question your estimate answers.

ExampleA missing-data paragraph that matches the codeAn illustrative example written for this guide

Of 3,465 employees in the analytic sample, 1,729 (49.9%) had complete data on every variable in the full model, which was fitted to complete cases (the default in R's lm()).

Most exclusions (1,422 of 1,736) were employees with no overtime in their contracts, who were not asked about overtime hours. Full-model estimates therefore apply only to employees with an overtime provision. Table S2 gives each model's sample size.

  • Both sample sizes. It gives the analytic sample and the rows the model used.
  • The rule that ran. It names the deletion rule the software applied, not a vague "cases with missing data were excluded."
  • Who it describes. It says which employees the estimate covers.

Report the standard errors your tables use

Observations often come in groups whose members resemble each other, such as employees within firms or patients within clinics. In that setting, economists A. Colin Cameron and Douglas Miller warn in the Journal of Human Resources that default standard errors can greatly overstate estimator precision6. Cluster-robust errors correct for this, but only if the code requests them, for example with vce(cluster) in Stata.

Confirm which version each table shows. In R, clustered errors often live in a second object, and a table built from the original fit still prints the classical ones.

Report the clustering variable and the number of clusters. With few clusters, unadjusted cluster-robust tests produce too many false positives. Cameron and Miller say "few" can mean anything from under 20 to under 50 equal-sized clusters, and more when sizes vary. Say whether and how you corrected for it.

Sort and label the extra analyses

Your list will often hold more models than the paper reports. Sort the extras: sensitivity analyses, subgroup or interaction models, superseded build-up steps, mis-specified fits you abandoned, and duplicates. The first two belong in the methods section, since STROBE asks you to describe any methods used to examine subgroups and interactions2 and any sensitivity analyses.

Then label each analysis as planned or not. ICMJE asks authors to distinguish prespecified from exploratory analyses, including subgroup analyses1, and CONSORT 2025 asks trials to describe any additional analyses, distinguishing prespecified from post hoc3.

Mis-specified fits and exact duplicates usually need no mention. Keep the list anyway: it answers the reviewer who asks how you reached the final model, and it makes a response to reviewers quicker to write.

Name the software and versions

ICMJE also asks you to specify the statistical software package(s) and versions used1. Versions matter because defaults change between releases. R 3.6.0 changed how sample() draws random numbers, and R's release notes say the old method can be requested if necessary for reproduction of old results7. A bootstrap rerun with the same seed can give different intervals on either side of that release.

Read versions from the session, not from memory: sessionInfo() in R, the about command in Stata, or a lock file or pip freeze in Python. Name every package that changed the numbers, such as the one that computed clustered errors. Keep that record with the code and data, wherever your research data management plan says they will live.

Before you submit the methods section

  • The analytic sample, and how you reached it
  • Each model's outcome, covariates, estimator and sample size
  • The missing-data rule the software applied, and who it dropped
  • Standard errors as the tables report them, with cluster counts
  • Sensitivity and subgroup analyses, labeled prespecified or post hoc
  • Software and package versions, read from the session

Write the introduction after this section, so it promises only what these analyses can support. To draft the methods from your own script, start with the tool at the top of this page.

How it works

Paste or attach your analysis script, with any draft, tables or output you have, and pick your reporting guideline if you know it. River reads the code first and builds a register of every model it fits: the outcome and covariates, the estimator, the standard errors requested and the rows each model used. Then it writes the methods section from that register into your workspace.

Anything the code can't settle, such as why a covariate was chosen or which package version ran, comes back as a numbered question for you, never a guessed sentence. If you paste a draft, River first checks it sentence by sentence against the code and marks each claim supported, incomplete or contradicted.

  1. Paste your script

    Add the analysis code, plus any draft, tables or output, and pick your reporting guideline if one applies.

  2. River registers each model

    It lists every model the script fits, with its covariates, estimator, standard errors and the rows it used.

  3. Get your methods section

    A draft written from that register, organized around your guideline, with each model's sample traced and explained.

  4. Settle the open questions

    Answer what the code couldn't settle, edit the draft, or ask River to cut it to a word limit.

What you get

  • A sentence-by-sentence check of any draft you paste: supported, incomplete or contradicted by the code
  • A sheet listing every model the script fits, reported or not, with its estimator and covariates
  • The rows each model actually used, traced back to your analytic sample with a reason for each loss
  • The standard errors each table really reports, flagged wherever your draft says something different
  • Software and package versions taken from any session log or lock file you include, never guessed
  • An editable methods section in your workspace, with open questions listed instead of invented sentences

Common questions

What should a statistical methods section include?

A statistical methods section should include the analytic sample and how you reached it, plus each model's outcome, covariates, estimator and type of standard errors. Add how missing data were handled, any sensitivity or subgroup analyses, and the software with versions. Your reporting guideline, such as STROBE for observational studies or CONSORT for trials, adds items specific to your design.

How long should a statistical methods section be?

There is no fixed length. A statistical methods section needs enough detail for someone with your data to repeat each analysis, within your journal's word limit. When space is tight, cut wording rather than facts. Keep every sample size, standard error type, missing-data rule and software version, and move longer detail into supplementary methods.

Should I report analyses that aren't in my results?

Yes, if they are sensitivity or subgroup analyses. Describe them even when they barely change the answer, and label each one prespecified or post hoc, as ICMJE and CONSORT 2025 ask. Corrected mistakes and identical refits can stay out, but keep a record of every model in case a reviewer asks how you reached the final one.

How do I write a statistical methods section with River?

Paste or attach your analysis script in the box at the top of this page, along with any draft or tables, and pick your reporting guideline. River lists every model the code fits and traces the sample behind each one, then writes the section into your free River workspace.

Do I need to send River my data?

No. River works from the code, plus any output, tables or draft you include, to see what each model did, so confidential records can stay with you. Output that prints each model's sample size helps most. If nothing you send shows how many rows a model used, River lists it as an open question rather than guessing a number.

Which reporting guideline does River follow?

The one you pick: STROBE, CONSORT, PRISMA, APA's JARS or your journal's own instructions. If you don't pick one, River chooses the usual guideline for your design, such as STROBE for an observational study, tells you which it chose and offers to switch. It also reports which checklist items the code satisfies and which still need your input.

Is the statistical methods section writer free?

Yes, it is free to start. Your methods section opens in a River workspace, where you can edit it, share it or ask River to change it. Paid plans add more AI use and access to the most advanced models.

Sources

  1. International Committee of Medical Journal Editors. “Preparing a Manuscript for Submission to a Medical Journal.” icmje.org (opens in a new tab)

  2. STROBE. “STROBE Statement—checklist of items that should be included in reports of observational studies.” strobe-statement.org (opens in a new tab)

  3. PLOS Medicine. “CONSORT 2025 statement: Updated guideline for reporting randomised trials.” journals.plos.org (opens in a new tab)

  4. The R Project. “Fitting Linear Models.” search.r-project.org (opens in a new tab)

  5. The BMJ. “Multiple imputation for missing data in epidemiological and clinical research: potential and pitfalls.” pmc.ncbi.nlm.nih.gov (opens in a new tab)

  6. Journal of Human Resources. “A Practitioner’s Guide to Cluster-Robust Inference.” cameron.econ.ucdavis.edu (opens in a new tab)

  7. The R Project. “R News.” cran.r-project.org (opens in a new tab)

Built by

Chandler Supple

Co-founder & CEO, River

Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.

Reviewed by

Brian Joseff, Co-founder, River