Overview
Stata is the working language of much applied economics, epidemiology and public policy research, largely because of its consistent command syntax, strong panel-data and survey tools, and a large library of community-contributed commands from SSC. Its difficulties are also characteristic: merges that quietly create duplicate observations, reshapes that fail on non-unique identifiers, and regression tables that look publishable while the standard errors ignore clustering.
Our Stata support is do-file first. We organize your project so that one master do-file runs cleaning, construction and analysis in order, logs the output and exports tables, which means results can be regenerated after every change. We comment code so you can read it, and we keep community packages listed so a coauthor or replicator can install the same ones.
The work can be delivered as finished do-files with an explanation session, a line-by-line review of code you wrote, or tutoring while you write it yourself.
Who it’s for and the problems it solves
This is for you if you are…
- Economics, finance and public policy students writing an empirical thesis in Stata
- Health and epidemiology researchers working with DHS, NHANES or other complex survey data
- Doctoral researchers and early-career economists preparing a paper or job-market project
- Research assistants inheriting someone else's do-files and log files
Common problems we help with
- merge reports 'variable does not uniquely identify observations' or produces far more rows than expected
- reshape fails with 'values of variable j not unique within i'
- You are unsure whether to use reg, xtreg, areg or reghdfe, and which standard errors to cluster
- Survey estimates ignore weights, strata and clusters because svyset was never run
- Tables are copied by hand from the Results window and no longer match the latest run
- Your code depends on commands a coauthor cannot find or on a different Stata version
What’s included — and what isn’t
Included
- Project setup: folder structure, master do-file, globals for paths, version statement and log files
- Data import from Excel, CSV, SPSS or SAS files, with labeling and value-label definitions
- Cleaning and construction: destring, encode, recode, egen functions, date handling and duplicates checks
- Merges (1:1, m:1, 1:m) and appends with assert checks on the _merge result and on identifiers
- Reshaping between wide and long, and xtset or tsset declarations for panel and time series
- Estimation: OLS with robust or clustered errors, logit/probit, fixed and random effects, high-dimensional fixed effects, IV and survey-weighted models
- Post-estimation: margins and marginsplot, test and lincom, predicted values and diagnostic checks
- Export of regression tables with esttab/estout, etable or collect, and graphs with consistent schemes
- A written list of any SSC or GitHub packages used, with install lines
Not included
- Specification searching to find significant coefficients
- Writing the empirical chapter or paper text you submit as your own
- Providing Stata licenses; you need your own or institutional access
- Working with restricted data we are not authorized to access — we can work on a synthetic or sample file instead
What you receive
- Master do-file and sub-files
- A master script that sets the version and paths, then calls separate do-files for cleaning, construction and analysis.
- Log files
- Text or SMCL logs from a full run, so every number in your tables can be traced to the command that produced it.
- Analysis dataset
- A labeled .dta file built from the raw data by code, never edited by hand.
- Exported tables and graphs
- Regression and descriptive tables in Word, LaTeX or Excel, plus graphs in a consistent style, written directly by the do-files.
- Code walkthrough
- A session explaining the logic of each do-file and the interpretation of the key coefficients.
How it works
Brief and data review
You describe your research question, identification idea and datasets. We check identifiers, time coverage and the unit of observation.
Project skeleton
We set up folders and a master do-file so every later step fits a reproducible structure.
Build the analysis file
Cleaning, merges and reshapes are coded with checks that stop the run if something unexpected happens.
Estimate and test
We run the agreed models, post-estimation tests and robustness checks, and discuss any surprises with you.
Tables, logs and handover
Tables and graphs are exported by code; you receive the full project and a walkthrough.
Stata commands and approaches we use
- Data management
- import, merge, append, reshape, collapse, egen, duplicates and assert for defensive checks.
- Linear and limited dependent models
- regress, logit, probit, ologit, mlogit, poisson and nbreg, with vce(robust) or vce(cluster) chosen to match the sampling and treatment structure.
- Panel estimators
- xtreg fe/re, the Hausman test, reghdfe for multiple fixed effects, and xtabond2 or xtdpdgmm for dynamic panels where justified.
- Causal designs
- ivregress and ivreghdfe, difference-in-differences with modern staggered-adoption estimators, and teffects for matching and weighting.
- Survey data
- svyset with weights, strata and primary sampling units, then svy: prefixes and subpop() for correct subgroup estimates.
- Post-estimation and output
- margins for marginal effects and predicted probabilities, coefplot, esttab/estout and the collect system for tables.
A do-file structure that survives revisions
A single long do-file edited over months becomes hard to trust. We split the work into numbered do-files — import, clean, construct, analyze, export — called from a master file that begins with a version statement, sets the working directory once and opens a log. Intermediate files are saved as .dta by code, so nothing depends on data edited in the Data Editor.
Defensive checks are part of the code, not an afterthought. After a merge we assert that the expected share of observations matched; after constructing an identifier we confirm it is unique with isid. When an assumption breaks, the do-file stops with a clear message instead of carrying an error into your tables.
Getting standard errors and fixed effects right
Many Stata regressions differ only in their vce() option, yet that choice can change conclusions. We cluster at the level at which treatment is assigned or observations are correlated, discuss the problem of very few clusters (and options such as wild cluster bootstrap), and explain the difference between absorbing fixed effects with areg or reghdfe and estimating them with dummy variables.
For panel work we check the panel structure with xtset and xtdescribe, and explain what the within, between and overall R² in xtreg output mean. The econometric choices themselves are covered in more depth on our panel data analysis page.
Errors and warnings we resolve most often
Stata's messages are terse but usually precise. Many problems come from the data structure rather than the model.
- r(459) 'variables do not uniquely identify observations in the using data' — the merge key is not unique where you assumed it was
- r(9) 'variable j not unique within i' in reshape — duplicate person-period rows to find with duplicates report
- 'type mismatch' — a numeric variable stored as text; destring after checking what the non-numeric values are
- 'omitted because of collinearity' — a regressor is absorbed by fixed effects or perfectly predicted by others
- 'command not found' — a community package such as reghdfe or estout is not installed on this machine
Stata versions, editions and StataNow
Stata 19 was released in April 2025 in three editions: BE, SE and MP, which differ mainly in the number of variables allowed and multicore speed. StataNow is the continuous-release version available to annual license holders; it adds new features between major releases and reports itself as 19.5. Code written with StataNow-only features may not run on a coauthor's standard Stata 19, and older releases lack newer commands such as the latest table and difference-in-differences tools.
We write do-files with an explicit version statement, avoid features your edition cannot handle (for example the variable limit in Stata/BE) and record which community packages and versions were used, so the project runs on the machines that matter to you.
What the work can look like
Illustrative example — fictional data
Sample code-review note: a merge that inflated the sample
A master's student merged firm-year financial data with an industry classification file and found 18,400 observations instead of 12,300. The figures are fictional and illustrate our review notes.
Diagnosis
The classification file listed some firms under two industry codes in different years, so a m:1 merge on firm_id alone was invalid. duplicates report firm_id in the using file showed 412 repeated identifiers.
Fix
The merge key was changed to firm_id and year, the classification file was expanded to firm-year level, and the code now runs isid firm_id year before the merge and assert _merge != 2 after it.
Effect on results
After correction, N returned to 12,300 and the coefficient on leverage moved from 0.041 to 0.029 with standard errors clustered by firm. The review note explains why the earlier estimate double-counted multi-industry firms.
Illustrative example with invented data and results. Real reviews are based on your code, data and research design.
What you’ll need to provide
- Raw data files or instructions for obtaining them, plus any documentation or codebooks
- Your research question, main specification and any papers you are following
- Existing do-files and logs, if you have started
- Your Stata version and edition (for example Stata 19/SE or StataNow/MP)
- Required table format (journal, LaTeX, Word) and your deadline
You don’t need everything ready to ask for a quote — tell us what you have and we’ll say what’s missing.
What affects price and turnaround
Price depends on
- Number and size of datasets to clean, merge or reshape
- Complexity of the estimation strategy and number of robustness checks
- Whether survey design, high-dimensional fixed effects or panel GMM is required
- Delivered code versus review of your code versus tutoring sessions
- Table and graph formatting requirements (for example LaTeX journal style)
Turnaround depends on
- Access to the data and documentation at the start of the project
- How settled your specification is before coding begins
- Size of the data and run times for heavy estimations
Every project is quoted individually. How we price our work.
Questions people ask before starting
Do you work with StataNow or older versions of Stata?
Yes. Tell us your version and edition. We set the version statement accordingly and avoid commands your release lacks, or tell you when a newer feature would genuinely help.
Can you work with data I cannot share?
Often. We can write and test do-files on a synthetic or public sample with the same structure, and you run them on the confidential data yourself. Logs you send back let us check the results without seeing the raw records.
Will I understand the code afterwards?
That is the aim. Do-files are commented in plain language, and the walkthrough session covers each step. If you want to write the code yourself, we can work as tutors instead.
Can you produce tables in the format of a specific journal?
Yes. We use esttab, etable or collect to export tables to LaTeX, Word or Excel with the significance stars, standard error labels and notes your target journal expects.
Should I use Stata or R for my thesis?
Use what your supervisor and department support unless a method is only available elsewhere. Both handle standard econometrics well. We can help in either, and translate code between them if a coauthor uses the other.