# How to Combine Survey Exports Without Losing What Changed

Combine survey exports without confusing append with joins, different questions, duplicates, cohorts, or denominators.

- Canonical URL: https://www.harmate.com/en/blog/combine-survey-exports-without-losing-differences
- Author: Harmate Team
- Published: 2026-10-28
- Updated: 2026-10-28T17:01:54.695927+00:00
- Language: en

## Content

# How to Combine Survey Exports Without Losing What Changed

You have two survey files and want to analyze them together. Before stacking rows, check that each row represents the same unit, that the columns really measure the same thing, and that identifiers can be interpreted safely. A combined file can be technically tidy while mixing questions, respondents, or periods that are not equivalent.

This guide offers a practical workflow for exports from multiple waves, teams, or tools. It does not make unlike populations comparable or merge files automatically.

## Start with the decision and the unit of analysis

Write down the decision the analysis should inform, such as: “Which registration difficulties should we investigate across these two cohorts?” Then define a row. Does one row represent a submission, a person, an enrollment, or an answer to one question? One person may submit twice; an export may already have multiple rows per submission if choices were expanded.

For each file, retain its source, export date, questionnaire version, collection period, and intended population. Do not replace these details with a vague field such as “year.” If the files came from different audiences, placing them together does not create one shared sample.

## Append and join do different jobs

**Append** adds rows. The columns should represent the same variables, and each new row should represent a comparable unit. This is often appropriate for waves of the same questionnaire. Add provenance fields such as `source_file`, `cohort`, and `collection_period`.

**Join** adds columns by matching rows through a shared key, for example a response file joined to a follow-up file using the same pseudonymous ID. Check that the key is unique on each side and count the matches. A many-to-many join can multiply rows and inflate totals. Do not join on first name, team name, or similar-looking text alone.

## Fictional example: two training exports

A consultant evaluates two cohorts after training on a workplace tool. `april_cohort.csv` contains a submission ID, team, and the question “Which step slows you down most?” `june_cohort.xlsx` contains a different ID, team, and “What prevented you from completing the task?”

Both questions concern difficulty, but they ask different things: one asks about a slow step; the other asks about an obstacle to completion. Do not merge them into one `barrier` field. Analyze the answers separately, then compare findings while keeping the wording difference visible.

| Original file | Source field | Harmonized field | Decision |
|---|---|---|---|
| April | `submission_id` | `response_id` | keep the source-specific key; do not treat it as a person ID |
| April | `team_name` | `team_label` | harmonize only documented variants; retain the original value |
| April | `slow_step` | `slow_step_text` | question A; analyze separately |
| June | `entry_id` | `response_id` | retain with `source_file` to prevent collisions between IDs |
| June | `team` | `team_label` | documented mapping; preserve the raw value |
| June | `task_blocker` | `task_blocker_text` | question B; do not merge with question A |

A mapping table records a preparation decision; it does not prove two variables are equivalent. Record exact wording, response options, export rules, transformations, and fields deliberately kept separate. Even identical wording may not be comparable if instructions, timing, or audience changed.

## Keep values, labels, and missingness interpretable

Tools may export numeric codes, display labels, or both. Preserve the untouched source file. If you recode, document the value map; never assume code `1` means the same answer in every file. [Qualtrics’ guidance on combining responses](https://www.qualtrics.com/support/survey-platform/data-and-analysis-module/data/combining-responses/) emphasizes aligning columns, checking values, and preserving questions that are not shared.

Distinguish a question that was not asked, one that was asked but left blank, “don’t know,” “not applicable,” and a survey break-off. A blank after appending can mean the question did not exist in that version; it is not necessarily a nonresponse. Do not fill missing answers without a justified method.

## Check duplicates and denominators before comparing

Count rows, unique IDs, and repeated submissions in each source before and after appending. For example, 12 April submissions plus 8 June submissions produce 20 submissions in the combined file; they do not necessarily represent 20 people. Without an authorized, stable key linking the waves, the number of unique people is unknown. Choose a duplicate rule based on the research purpose and collection documentation; do not silently delete a second submission. Check join multiplicity too: if a key occurs twice in the response file and three times in the follow-up file, a many-to-many join produces 2 × 3 = 6 rows for that key. Inspect multiplicity before joining, or reduce each side to the intended unit using a documented rule. State the denominator that matches the metric: for example, a response rate uses eligible people invited, while a rate meeting a criterion uses valid responses actually assessed. For a person count, use unique people linked under an explicit rule; for a multiple-response question, distinguish respondents from selections. For [multiple-response questions](/en/blog/multiple-response-analysis), the denominator differs depending on whether you report the share of people or the share of selections.

A cohort is context; it does not prove that the same person answered before and after. Individual-level comparison requires an authorized, stable, documented key and an appropriate privacy rule. Without it, compare groups or distributions and say that you are not measuring individual change.

## A short pre-analysis checklist

- Are the source files preserved unchanged and dated?
- Does each row represent the same unit?
- Is append or join explicit, including its key?
- Are labels, codes, options, and versions documented?
- Are non-equivalent questions kept separate?
- Are missingness, duplicates, and populations defined?
- Does each result state its denominator and cohort?

After these checks, create a derived dataset and keep it linked to its sources. When a question changes meaning, two contextualized results are more useful than a misleading shared metric. Our [survey response preparation guide](/en/blog/prepare-survey-responses-before-analysis-a-practical-method-and-example) covers provenance and file corrections; the [Qualtrics export guide](/en/blog/qualtrics-export-data-analysis) explains its specific export options.

To continue with responses already collected, you can manually import CSV, JSON, or XLSX files into [Harmate](/en/product/response-import). An account is required. Column review helps you check the imported file; it does not decide which questions are equivalent. Keep your mapping and review the result before analysis.