Statistical Analysis Using Stata: A Reproducible Do-File Workflow

1. How Does a Reproducible Workflow Differ from a Long Do-File?

A do-file is necessary, but a long command file alone does not guarantee reproducibility. A workflow also includes directory structure, data sources, execution order, software versions, extensions, logs, and output-generation rules. Long (2009) treats planning, documentation, cleaning, analysis, presentation, and archiving as parts of one data-analysis workflow.

A practical standard is that another person can start from a shareable copy of the input data, run the master do-file in a clean Stata session, and recreate analysis files and results tables. Opening Data Editor to edit cells, repeating menu actions from memory, or copying coefficients from Results to Word indicates a step that remains unautomated.

Reproducibility does not establish correct conclusions. A workflow may run perfectly while using an incorrect estimator, weights, or dependence structure. Technical procedures require methodological reasoning and assumption checks.

2. Design the Project Structure Before Analysis

Stata Project Manager organizes do-files, datasets, graphs, and related files and accepts relative paths so projects can move between computers (StataCorp, n.d.-a). Ordinary directories are also suitable if the team does not use Project Manager.

Treat the raw-data directory as read-only by convention. Variable renaming, missing-value coding, merges, and variable creation must occur through commands and be saved to data/derived. This separation allows a return to the source when a cleaning decision changes.

3. Write the Master Do-File as an Execution Map

Stata’s User’s Guide describes do-files as rerunnable command files that can call other do-files and log output. The version command at the top requests syntax interpretation under the specified version, reducing the risk that software changes alter command behavior (StataCorp, 2025c).

Keep the master do-file short. It configures the environment, opens a log, sets a seed for random components, calls modules, and closes the log. Detailed cleaning and estimation belong in subsidiary files so errors are easier to locate.

version 19.0
clear all
set more off
capture log close _all

log using "output/logs/master.log", text replace
set seed 20261025

do "do/10_import_clean.do"
do "do/20_derive.do"
do "do/30_analysis.do"
do "do/40_report.do"

log close
exit

4. Import Data While Preserving Source Traceability

Each raw file needs a source, receipt date, version, and initial row count. After importing, use describe, codebook, and range checks to confirm variable types, labels, missing codes, and units. Save derived data under a new name rather than overwriting the source.

datasignature creates a signature from values, variable names, and storage types. datasignature confirm can stop a do-file when data no longer match the saved signature, making it useful for detecting source-file changes outside the workflow (StataCorp, 2025b). A signature does not replace access management or backups.

For Excel, CSV, or database sources, retain the original export and import commands. A manually edited .dta file does not reveal which columns changed or which cases were excluded.

use "data/raw/survey_original.dta", clear
describe
codebook respondent_id age income
isid respondent_id
assert inrange(age, 18, 100) if !missing(age)
assert income >= 0 if !missing(income)
datasignature

save "data/derived/survey_stage01.dta", replace

5. Turn Expectations into Checks That Can Stop the Do-File

Data checks are most valuable when violations produce error codes and halt the workflow. assert verifies a condition for observations within scope; isid verifies that a variable or combination uniquely identifies observations. These commands make implicit assumptions auditable (StataCorp, 2025b).

Stata numeric missing values exceed every finite number. Thus age >= 18 accepts a period-valued age unless !missing(age) is added. Range checks must explicitly handle missing data for this reason.

Checks should follow the codebook: valid categorical values, scale ranges, relationships among variables, and expected observation counts. Do not remove outliers merely because coefficients change; first distinguish entry errors, different units, genuine subgroups, and valid extreme values.

6. Safe Merging Begins with Key Checks

merge combines observations using one or more keys and creates _merge to identify rows present only in master, only in using, or in both files (StataCorp, 2025b). Before merging, check key uniqueness on each side according to the intended 1:1, 1:m, or m:1 relationship.

Do not use merge m:m to repair duplicate-key errors. Many-to-many merging may pair observations according to their order rather than the intended research relationship. Redefine the unit of analysis, add key variables, or aggregate at the correct level before merging.

After merging, tabulate _merge and investigate unmatched cases. Drop _merge only after saving checking evidence. assert() and keep() are useful when accepted statuses have been prespecified; unexpected statuses then trigger errors rather than being ignored.

use "data/derived/respondents.dta", clear
isid respondent_id

preserve
use "data/derived/province_lookup.dta", clear
isid province_code
restore

merge m:1 province_code using "data/derived/province_lookup.dta"
tabulate _merge
assert inlist(_merge, 1, 3)
count if _merge == 1

drop _merge
save "data/derived/analysis_ready.dta", replace

7. Select Estimators from the Data Design Rather Than Familiar Commands

Estimation commands must suit the outcome, dependence structure, and sampling design. regress may suit continuous cross-sectional outcomes when relevant assumptions are assessed. logit or probit handle binary outcomes. Panel data may require xtset and panel models; hierarchical data may require mixed or meglm; complex surveys must be declared using svyset before the svy prefix is used (StataCorp, 2025a).

Robust standard errors do not repair incorrect functional forms, endogeneity, measurement error, or sampling problems. Clustered standard errors do not automatically turn data into a valid panel either. Report the clustering unit, cluster count, and rationale for the variance structure.

Define weights according to their design and meaning. Do not interchange pweight, fweight, aweight, or iweight merely because a command accepts them. For complex surveys, strata, primary sampling units, and weights belong to the same inferential design.

8. Fix Random Components, Versions, and Extensions

set seed determines the pseudorandom generator’s starting point. The same seed and command sequence reproduce the same sequence for the corresponding generator; repeatedly resetting seeds inside loops may create unintended repetition (StataCorp, 2025a).

Place version at the start of the master do-file and save c(returned) or about in the log to identify the Stata build used. For community commands, record package names, versions or installation dates, and sources. A do-file calling undeclared commands is difficult to run on a new computer.

Numerical reproducibility also depends on data and command order. Unstable sorting with duplicate sort keys can change position-based selections; add a unique key before using _n or retaining rows by order.

9. Separate Primary Estimation, Postestimation Checks, and Sensitivity Analyses

The analysis file should first define the primary model, save estimates, and generate reporting quantities using margins, contrast, lincom, or nlcom where appropriate. Results depend on model scale; logit coefficients, odds ratios, and predicted probabilities are different quantities.

Match postestimation checks to the estimator. OLS residual checks cannot be copied unchanged to binary, panel, or multilevel models. A good workflow saves checking commands and interpretive criteria without turning diagnostic p-values into automatic deletion instructions.

Place sensitivity analyses in a separate block: justified alternative specifications, coding, SEs, or sample structures. Trying many models and retaining only favorable results undermines transparency even when all operations are coded.

10. Generate Tables and Figures Directly from Stata

Copying numbers from Results into Word creates a manual branch Stata cannot verify. collect, etable, putdocx, putexcel, dyndoc, and markdown generate tables or documents from saved results; rerunning commands updates documents when data change (StataCorp, n.d.-b).

Report files should state model titles, dependent variables, SE types, observation counts, clustering units, weights, and coefficient-scale notes. Round only for presentation. Full-precision data in memory remain available for subsequent calculations.

An attractive table is insufficient for auditing. Save text logs, do-files, version lists, and a mapping between manuscript table names and output files. If a published result cannot be traced to executed commands, a workflow link is missing.

11. Hypothetical Example: From Survey Data to a Clustered Model

This example illustrates a workflow rather than actual research results. Suppose data contain 1.200 people in 60 schools, a continuous wellbeing outcome, and individual-level predictors. respondent_id must be unique; school_id identifies standard-error clusters.

The clean file checks IDs, age ranges, and missing codes, then saves analysis_ready.dta. The analysis file loads the correct derived version, describes the sample, estimates the primary model using vce(cluster school_id), saves estimates, and calculates predictions. State explicitly that there are 60 clusters, because individual observation counts do not replace independent school-level unit counts.

If hypotheses require school-level random effects, clustered SEs do not replace a mixed model. Choosing a marginal model with clustered SEs or a multilevel model requires the research question and data-generating structure.

use "data/derived/analysis_ready.dta", clear
isid respondent_id
assert !missing(school_id)

misstable summarize wellbeing age female exposure
summarize wellbeing age exposure
tabulate female

regress wellbeing c.exposure c.age i.female, vce(cluster school_id)
estimates store main_ols
margins, at(exposure=(0 1 2 3 4))
marginsplot, name(fig_margins, replace)
graph export "output/figures/margins.svg", replace

12. Describing the Workflow in a Thesis or Article

Describe software and workflow sufficiently for readers to understand how results were generated. Do not reproduce the entire do-file in methods, but provide versions, major processing steps, estimators, SEs or survey design, and code locations where possible.

Replace the following template with actual study information. Do not retain bracketed alternatives if only one option was used.

13. Pre-Handover Checklist for Stata Projects

• The master do-file runs in a clean Stata session without manual actions.
• Raw data are not overwritten and include sources and receipt dates.
• Every data/derived file is generated by commands.
• Keys are checked with isid before merging.
• _merge statuses are inspected and unmatched cases explained.
• Commands check missing codes, value ranges, and logical variable relationships.
• version, seed, Stata version, and extensions are recorded.
• The estimator, weights, survey design, or clustering match the data design.
• Primary models are separated from sensitivity analyses.
• Tables and figures are generated by commands rather than copied manually.
• Logs contain no unnecessary paths, personal information, or sensitive data.
• README states execution order, required inputs, and expected outputs.