A Third-party Import source lets you load survey responses that were collected outside MX8 Labs and report on them inside the platform. Use it when a partner or panel fields the survey on their own system and hands you a results file, or when you want to combine historical data with a current study. Once imported, the responses behave like any other source: they appear in crosstabs, reports, and data exports.
This is a reporting-only source. It does not field a survey or launch respondents. It ingests responses you already have.
Before you start
- Advanced respondent sources must be enabled in your account.
- You need a response file in
.csv,.csv.gz, or.xlsxformat whose columns map to the questions in your survey.
Step 1: Create a new Third-party Import source
Go to Sources, click Add Respondent Source, and select Third-party Import.
Fill in the base fields. Target completes does not apply here. It is set automatically from the number of responses you successfully import.
| Field (UX label) | What to enter | Required |
|---|---|---|
| Name | A descriptive name for this source | Yes |
| Market | The market the responses come from | Yes |
| Language | The language of the responses | Yes |
| Days in field | How long the responses were collected over | Optional |
Step 2: Prepare your import file
The import file is a long file: one row per respondent per answer, the same shape as the Long Excel Format export. A single respondent has many rows, one for each question they answered. The easiest way to produce a correctly structured file is to start from a Long format export of a comparable study and map your data into the same columns.
Supported file types are .csv, .csv.gz, and .xlsx. For .xlsx, the platform reads the workbook's active sheet. You do not need to format the data as an Excel table.
Required columns
Every file must contain these six columns. Header names are case-sensitive and must be spelled exactly as shown.
| Column | What it holds |
|---|---|
respondent_id | A unique identifier for the respondent, repeated on every row belonging to that respondent. Required on each row. |
reporting_id | The reporting ID of the question being answered. Must match a reportable question in your survey. |
type | The question type, which must match that question's type in your survey (e.g. NumericQuestion, MultiChoiceQuestion, MultiSelectQuestion, RatingQuestion, TextQuestion). |
raw_response | The raw stored answer value. This has the same meaning as raw_response in the Long export. |
timestamp | When the answer was submitted. Any format the platform can parse; ISO 8601 is recommended (e.g. 2025-07-30 16:27:06). |
status | The respondent's final status. One of: New, In Progress, Complete, Terminated, Refused Consent, Quota Screenout, Quota Overquota, Poor Quality, Duplicate Respondent. |
Optional topic columns
Any column beyond the six required ones is treated as a topic: extra first-party or segmentation data attached to the response and made available in reporting. Two rules apply:
- A topic column cannot reuse a reserved/internal column name (such as
question,line_number,response,weight, or any of the required column names). A reserved name is a header error and blocks the whole import. - A populated topic column that your survey schema does not declare is still imported, but each affected respondent is flagged with a warning.
Step 3: Upload and review the validation result
Use Upload import file. The platform runs a validation pass (a dry run) before importing anything, and reports back per-respondent counts:
- Total respondents: distinct
respondent_idvalues found in the file. - Imported respondents: respondents that validated cleanly and will be loaded.
- Not imported respondents: respondents excluded because at least one of their rows failed validation.
- Respondents with warnings: respondents that imported but had non-blocking issues.
Validation works at three levels:
- Header errors block the entire import. Examples include a missing required column or a topic column that reuses a reserved name. Fix the header and upload again.
- Row errors exclude the whole respondent (all of their rows). A row errors when
respondent_idis missing,reporting_idis not a question in the survey,typedoesn't match the question,statusisn't one of the supported labels,timestampcan't be parsed, orraw_responseisn't a valid, recodable answer for that question. - Warnings don't exclude anyone. One example is a populated topic column the schema doesn't declare.
A downloadable import report is produced alongside these counts so you can see, respondent by respondent, what was accepted, excluded, or flagged, and why. If validation fails outright, the report explains the reason. Fix the file and upload again.
Step 4: Go live and import
- If any rows were marked as not imported, you must accept that those rows will be excluded before you can proceed.
- Use the Status action Go Live.
Going live runs the import for real. The successfully imported responses are loaded into the survey, the source's Target completes is set to the imported count, and the source is marked complete. There is no ongoing fielding for an import source. If you need to start over, reset the import, correct your file, and upload again.
Reporting
Once the import completes, standard reports, crosstabs, and data exports include the imported source.