Skip to content

Preparing your data file

Before a project starts, n-Infinite reads your survey file and works out its structure on its own: which columns belong to the same question, what each code means, which questions are only shown after another answer, and so on. It does not require one single format — any consistent coding works.

This page explains what the system can figure out by itself, what it genuinely cannot, and a short checklist to make your file as unambiguous as possible before you upload it.

Coming in a future release

The confirmation step described below — a screen where you answer the handful of questions the system could not resolve on its own, right inside the platform — is available in the next release. Until then, following this guide still helps: the cleaner your file, the more reliable the system's own default reading will be.

What the system infers automatically

From the column names and the data itself, n-Infinite works out:

  • Which columns form a single question — a multi-select battery, a grid of related columns, a single-choice question, a numeric field, or open text — from the shared prefix in their names.
  • The separator joining a question's name to its option code (for example, the _ in Q7_1, Q7_2, Q7_3).
  • How each battery is coded, for example:
    • 1 = selected, 0 = not selected, blank = not shown
    • 1 = selected, blank = not selected (everyone was shown this question)
    • 1 = selected (yes), 2 = not selected (no), blank = not shown
    • the cell carries the answer code directly (a scale or grid question)
  • Mutually exclusive options inside a battery (for example, an "Only this one applies" choice that can't be ticked alongside anything else).
  • Skip logic — questions that only appear once another answer meets some condition — mined directly from which rows are blank and which aren't.
  • Columns that are not answers at all — respondent ID, token, start date, IP address, referral URL — recognized by name and excluded from modeling.

When the evidence is clear, the system proceeds on its own. It only stops to ask when two readings are genuinely equally plausible — so no real answer is lost, and nothing gets invented from a wrong guess.

The four things it cannot decide alone

Some signals cannot be resolved from the data alone, no matter how much of it there is. If your file has one of these, you will be asked before anything is generated:

  1. What a blank cell means. Blank can mean "this person was never shown the question" or "they were shown it and selected nothing." A whole battery coded only with 1/blank, with no explicit zeros anywhere, is always asked about — even when everything else in the file looks confident — because both readings fit the data equally well.
  2. Escape codes inside a multi-select (an "Other", "None of the above" or "Don't know" option, usually a high code like 98 or 99). Without being told what it means and whether it was shown to everyone, the system cannot know whether to treat it as an ordinary option or as an exception with its own visibility rule.
  3. Columns that aren't recognizably metadata. ID, token, timestamp and similar columns are excluded automatically when their names say so. A column that is unique per respondent but isn't named like the usual metadata (an internal panel code, a custom tracking field) can be mistaken for a real question.
  4. The separator used inside column names, when it's inconsistent or collides with a question's own name — for example, a column named BRAND_COD existing alongside BRAND_COD_1…BRAND_COD_7, where it's unclear whether BRAND_COD is a combined answer for the same question or an unrelated field.

A related case: with a small sample (under 250 real responses), an apparent skip-logic rule is confirmed before being applied even at reasonably high confidence — at that size, a handful of coincidental blanks can look exactly like real routing.

In every case above, the system does not proceed on a guess. It asks one short, specific question — and only once.

Checklist before you upload your file

  1. Use a single, consistent separator to build option column names (e.g. always _), and don't reuse that character inside the question's own name.
  2. Don't give a question the same name as the prefix of its own option group (avoid having both BRAND_COD and BRAND_COD_1).
  3. Mark "not selected" explicitly with a value (e.g. 0) whenever you can; leave a cell truly blank only for "not shown to this respondent."
  4. If a multi-select question has escape codes (Other, None, Don't know), tell us what they mean and whether they were shown to everyone.
  5. Use the same coding across every column of the same battery — don't mix 1/0 with 1/2 inside one group of questions.
  6. Don't mix 1 and 1.0 for the same answer within the file — keep the data type consistent for a given column.
  7. If a question repeats across waves (e.g. 2023 and 2024), name the columns so the wave is distinguishable from an answer option — not just a trailing number.
  8. Keep columns that are purely respondent metadata (ID, token, date, IP, referral URL) clearly named as such, separate from answer columns.
  9. Keep the same suffix vocabulary across similar questions, so the system recognizes they form the same kind of group.
  10. When in doubt, send a short codebook along with the file — it settles in one message what would otherwise take several rounds of questions.

Three quick examples

1. Ambiguous blank

Before: Q5_1 is blank both for people who never saw the question and for people who saw it and selected nothing.

After: Q5_1 = 0 when not selected; blank only when the question wasn't shown.

2. Unflagged escape code

Before: Q7_98 sits alongside Q7_1…Q7_20 with nothing indicating that 98 means "None of the above."

After: a short note (or codebook line) stating "Q7_98 = None of the above (exclusive, shown to everyone)."

3. Separator colliding with a real column

Before: both BRAND_COD (a single combined-answer column) and BRAND_COD_1…BRAND_COD_7 (the same options, split out) exist, using _ as the separator.

After: rename the combined column (BRAND_COD_TOTAL) or use a separator that doesn't collide with the question's own name.

4. Unflagged metadata

Before: a column like panel_uid or entry_ts is unique per respondent but isn't named id, token or timestamp, so it risks being treated as a real question.

After: name it recognizably as metadata, or flag it when asked.

What you may be asked, and why

If your file triggers one of the cases above, the confirmation screen asks something like this:

What we might ask Why we ask it
"Your option columns look like they use _, but the project is set up with a different separator — which one is right?" More than one separator could explain your column names equally well, or the one configured doesn't match any column.
"These columns look like the options of one question, but that question's own name also exists as a column — are they the same question, or two different ones?" An option group's shared prefix is also the name of a real column in your file.
"This option — only a few respondents ticked it, the rest are blank — was it shown to everyone, or only to some?" An escape option never carries an explicit "not selected" value while its siblings do, and nothing else in the file explains the blanks.
"These questions only ever show a tick or a blank, never an explicit zero. Does blank mean 'not selected', or 'not shown to this person'?" A whole battery coded only tick/blank has no way to tell these two cases apart from the data alone.
"These option suffixes aren't plain numbers — are they separate options of one question, or unrelated columns?" Non-numeric suffixes (a brand code, a written tag) don't fit the usual "question + number" pattern the system relies on.
"Are these two small numeric suffixes answer options, or two waves of the same question (e.g. two survey years)?" A short list of numeric suffixes can look like response codes or like a repeated wave — both fit the data.
"This question only ever shows two values, never a zero — is one of them 'yes' and the other 'no', or are they two separate options?" Without a "not selected" value to anchor it, a two-value coding could be either a yes/no answer or two selectable options.
"This looks like both a single combined-answer column and a set of separate option columns for the same question — one question, or two?" The same multi-select question appears to be represented twice in the file, and the two versions don't fully agree.
"This question seems to appear only for a small group who answered something specific earlier — is that real skip logic, or a coincidence?" The apparent rule is based on very few respondents, so it needs a human to confirm it's a real pattern and not noise.

If you don't answer, the system always falls back to the safest default it can — it never silently assumes the reading that would invent or discard real data.