Pipe Text From Variables and Previous Answers

Text piping lets a later part of a survey reuse information the respondent already gave, or a variable created by the survey. Use it to make prompts feel specific without asking the same question twice.

Type a token in double curly braces. The engine matches {{ ... }} and replaces each token with the live answer or variable value. Spaces next to the braces are optional, so {{answer:name}} and {{ answer:name }} behave the same.

Pipe a previous answer

Use the answer prefix and the question's Question Name (set on the question card in Block Builder):

{{answer:respondent_name}}

Equivalent prefixes Domandata also accepts: ans:, q:, or question: instead of answer:.

Pipe a survey variable

Use the var prefix and the variable name (for example from custom question JavaScript or other logic that writes into the survey's variable map):

{{var:treatment_label}}

For nested objects, use dot paths inside the token:

{{var:profile.segment}}

Equivalent prefixes: vars: or js: instead of var:.

Full sentence example

If an earlier Text Response question is named respondent_name, a later prompt can say:

Thanks, {{answer:respondent_name}}. Now think about your most recent purchase.

During the survey, Domandata replaces the token with the respondent's answer.

Use this format to insert an answer from an earlier question:

{{answer:question_name}}

The most reliable reference is the question's Question Name. You can set it from the small name field on the question card in Block Builder. Good names are short and stable, such as respondent_name, favorite_brand, or party_id.

Examples

• {{answer:respondent_name}} inserts the answer to the question named respondent_name.
• {{answer:favorite_brand}} inserts the selected or typed favorite brand.
• {{answer:Ask2}} can work for the displayed question label, but a custom question name is safer.

Use this format to insert a survey variable:

{{var:variable_name}}

Variables can come from advanced question JavaScript or other survey logic that creates variables. For nested variable objects, use dot notation:

{{var:profile.segment}}

Example

If a question's JavaScript declares a variable named treatment_label, later text can use:

You were shown the {{var:treatment_label}} version.

Domandata can pipe an estimate of how long the survey takes, so an intro screen or consent text can say something like “this survey takes about 8 minutes.” Unlike answer: and var:, this token needs no setup — it works in any survey with no source question to name:

{{surveytime}}

Before a survey has collected enough responses, the estimate comes from the survey's own structure — question count, question type and complexity (for example, a 5×5 grid takes longer than a single Text Response), and the flow: branches are weighted by their assignment percentages, and Skip Rules that can end the survey or jump ahead discount the time of whatever they route around. Once a survey has at least 5 responses with a recorded completion time, Domandata switches to the actual median time from real respondents, and keeps that up to date as more responses arrive.

Formats

By itself, {{surveytime}} renders as a plain number of minutes (for example, 8). Add modifiers, separated by dots, to change the unit or the style. Modifiers can appear in either order:

minsec displays as minutes and seconds together, such as 8:24 — the token name uses minsec instead of a literal colon because a colon inside a token already means something else to Domandata's piping engine (as in answer: or var:).

Examples

Capitalization commands (see below) also work on this token, for example {{upperfirst.written.minutes.surveytime}} renders Eight minutes at the start of a sentence.

Example

This survey takes about {{surveytime}} minutes to complete.

Note the estimate is unitless on its own — write “minutes” yourself when using the plain numeric form, or use a written token, which includes the unit word automatically.

Use the conjoint prefix to reuse what a participant saw or picked in a conjoint question — useful for a recap on a later question or a thank-you screen. Unlike answer: and var:, this token has no bare form; it always needs the explicit conjoint: prefix, followed by the conjoint's Question Name:

{{conjoint:question_name}}

On its own, that pipes everything shown in task 1, formatted the same way the question itself is (Table or Vignette). Add a path after the question name to reference something more specific:

See Conjoint Survey Questions for the full grammar, including referencing multiple alternatives at once (col1+3) and matching attributes by position (row2). A capitalization command (below) can prefix a conjoint: token the same as any other.

Add a capitalization command before any token to control how the piped value is cased. The command comes first, followed by a dot, then the normal token:

{{upper.answer:respondent_name}}

Available commands

Examples

• {{upper.answer:respondent_name}} — pipes the answer to respondent_name in all caps.
• {{titlecase.var:treatment_label}} — pipes the variable treatment_label in Title Case.
• {{upperfirst.answer:city}} — pipes the answer to city with only the first letter uppercased.
• {{lower.var:profile.segment}} — pipes a nested variable value in all lowercase.

The command is case-insensitive, so {{UPPER.answer:name}} and {{upper.answer:name}} behave the same.

Add | followed by fallback text at the end of any token to control what shows when there is nothing to pipe — either because the reference doesn't resolve at all (a misspelled question name), or because it resolves but is currently empty (a question the respondent hasn't reached or answered yet):

{{answer:favorite_brand|your brand}}

If favorite_brand has an answer, that answer is piped in as usual. If it doesn't — whatever the reason — the text reads “your brand” instead of leaving an awkward gap or, without a fallback at all, the raw {{...}} token itself.

A fallback works after every prefix — answer:, var:, conjoint:, loop:, and bare references — and after a capitalization command, which applies only to the real value, never to the fallback text itself:

{{upper.answer:favorite_brand|YOUR BRAND}}

Examples

• {{answer:city|your city}} — falls back to “your city” if that question hasn't been answered yet.
• {{var:treatment_label|the control condition}} — falls back if that variable was never set.
• {{conjoint:vignette_q.selected|no choice yet}} — falls back before the respondent has picked an alternative.
• {{answer:city|}} — an empty fallback: always show nothing rather than the literal token, with no placeholder text.

Only the first | in a token is the fallback separator, so the fallback text itself can safely contain more | characters (for example, “not sure | prefer not to say”) without any special escaping. There is no way to escape a literal | meant as part of the reference itself — in practice this never collides with a real question name or variable name.

Piped text is rendered in the participant-facing survey. Current supported places include:

• Question prompt text.
• Custom HTML in a question.
• Multiple Choice answer labels.
• Dropdown options and placeholder text.
• Ranking item labels.
• Grid Matrix row, column, and slider endpoint labels.
• Conjoint row, column, and cell labels.
• Slider endpoint labels.

That list is about piping into a conjoint question's own labels. To pipe what a conjoint showed a participant back out into a later question, use the conjoint: prefix described above — see “Pipe What A Participant Saw In A Conjoint.”

1. Step 1: Create the source question. In Block Builder, add the question that collects the value you want to reuse.

   Step 1: Create the source question

2. Step 2: Name the source question. Use the question name field and choose a stable name such as first_name, favorite_brand, or party_id.

   Step 2: Name the source question

3. Step 3: Add the later prompt. In a later block or question label, type the token, such as {{answer:first_name}}.

   Step 3: Add the later prompt

4. Step 4: Check the order. Make sure the source question appears earlier on every respondent path that uses the piped text.

   Step 4: Check the order

5. Step 5: Preview the path. Open Preview, answer the source question, and confirm the later text resolves correctly.

   Step 5: Preview the path

6. Step 6: Inspect export if needed. Submit a test response and review Export when the piped value matters for analysis or auditing.

   Step 6: Inspect export if needed

If Domandata cannot find a referenced answer or variable, it leaves the token in place — unless it has a fallback (see above), in which case the fallback text shows instead. Seeing a raw token like {{answer:first_name}} in preview usually means the referenced question has not been answered yet, the name is misspelled, or the question appears later in the survey.

{{conjoint:...}} tokens for “what was picked” (such as .selected) are the one exception even without a fallback: they resolve to an empty string, not the literal token, while the referenced task is still unanswered — that's an expected, temporary state rather than a broken reference. A misspelled question name or attribute in a conjoint: token still leaves the literal token in place, the same as any other prefix.

If a piped reference points at a question appearing at the same position or later in the survey — a common cause of an empty or stuck-literal token — Instrument Review on the Deploy tab flags it automatically as “Piped text references a question that hasn't been asked yet.” Instrument Review separately flags an answer:/ans:/q:/question:/conjoint: token whose reference does not match any question in the survey at all, as “Piped text references a question that no longer exists” — typically the target question was renamed or deleted after the token was written. Respondents see such a token as written (or its fallback text, if it has one), so check Preview.

Instrument Review also checks every other place a survey points at a question or block: piped text, skip and display logic, follow-ups, pulled-in answers, cross-question checks, loops, randomization pins and anchors, Flow values, branching and routes, quotas, quality rules, and translations. Any of these that points at a question or block that isn't in the survey — common after pulling a block or question from the Library, a community, or another survey without everything it refers to, or after deleting a question — is listed with what holds the reference, and Go opens it: the question, the block, Flow, the quota on Deploy, or the quality rule on Export. These are warnings; leftover translations and privacy choices are informational. While a reference is missing, a follow-up whose parent is gone is shown to everyone as an ordinary question, a skip-rule or quota condition on a missing question never matches (whatever its operator), and piped text shows the token as written. A reference to a question in the trash is flagged too. The references are kept, so restoring or pulling in the missing question fixes them.

• Use question names instead of full prompt text so edits do not break references.
• Keep names lowercase and readable, such as city, condition_label, or baseline_trust.
• Only pipe from questions that appear earlier on the respondent's path.
• For randomized or branched surveys, preview each relevant path.
• Avoid piping sensitive identifiers into places where participants do not need to see them.
• Use {{surveytime}} on an intro or consent screen so the stated completion time updates itself as real response data comes in, instead of going stale.

• Survey Variable Names and Recodes
• Custom Code in Survey Questions
• Preview and Pilot Test a Survey
• Branching and Skip Logic for Research Surveys
• Conjoint Survey Questions