In many projects, software is opened before the researcher has answered three basic questions: which decision needs support, what evidence can answer it, and which operations are permitted on the data. When those questions have not been recorded, even an attractive output table can be hard to interpret. The problem is not a lack of technique; it is that small choices have become detached from the research question.
An analysis decision log is a short working document, updated throughout a project. Each entry need only record the issue or hypothesis being handled; the relevant variables or data source; the choice made; the rationale; the decision maker; the date; and the consequence to be checked. It does not replace a protocol or analysis code. Its role is to connect those materials so a later reader can understand why the results were produced in the chosen way.
Start the log before data cleaning
Open the log when the research question and sampling plan are agreed. For example, a team studying customers’ intention to return might record that the unit of analysis is an individual who used the service in the past three months; responses missing the entire experience section will be excluded; and isolated blanks will be retained while the extent of missingness is assessed. These notes may look administrative, but they determine who the analytic sample is and whom the findings may describe.
Once data arrive, the log continues to capture changes that affect interpretation: whether respondent groups are combined; the rule for identifying implausibly rapid responses; reverse-item coding; treatment of outliers; and the reason for stopping or adding a test. It need not record every click. It should record choices that could change the conclusion if they were made differently.
Use the log as a checkpoint before reporting
Before writing results, reconcile each table with the log through three questions. Which question does this table answer? Do the sample, variables, and calculation match the recorded decision? Did anything change after seeing the data that a reader needs to know to assess the conclusion? If the third answer is yes, report that change and its rationale rather than hiding it in a technical operation.
The log also helps a team work together. The questionnaire designer, data cleaner, and manuscript writer no longer rely on memory or ambiguously named files. A brief weekly review of new decisions is often more valuable than hours spent repairing tables at the end, because it exposes early misalignment between the question, data, and analysis.
The point is not to add procedure for its own sake. For many academic and business projects, a one-page, versioned log linked to the data file or codebook is enough. When a result is questioned, the team can return to the evidence, rule, and rationale it used. That is the basis for results that are clear to readers and can be revised responsibly when the data or question changes.
