Response Tags

Response tags are optional metadata that travel with every quiz answer. They let you surface the same signal in completion copy, dashboards, or downstream automations without relying on raw option labels.

This guide will walk you through:

• Where to assign tags inside the builder
• How tags are resolved and stored as submissions are collected
• Where to reference them for personalization, reporting, and automation

Where tags live in the builder

Every Multiple Choice or Choice Button option includes a Tag (optional) dropdown in its settings card. Choose an existing tag (they are just custom variables behind the scenes) or pick + Create new tag... to open the custom variable form. New tags need a lowercase key, a type, and an optional description so you can reuse them across other questions.

Yes/No blocks expose a Response tags card with separate Yes tag and No tag dropdowns. The same custom variables are available there, and leaving either selector blank keeps the ordinary "Yes" or "No" label as the fallback value.

Prebuilt tag placeholders

Use these built-in placeholders to read response tags without wiring up any custom variables. Every placeholder resolves automatically in completion copy, thank-you messaging, and any field that supports tag insertion.

Placeholder	Description	Example
{{tag:<questionId>}}	Returns a single tag for the referenced question. Yes/No responses use the configured tag (or the literal label, if empty), and single-select Multiple Choice or Choice Buttons return the tag (falling back to the option label).	{{tag:skin_type}} renders dry when the respondent picked the option tagged dry.
{{tags:<questionId>}}	Combines every unique tag from the selected options into a comma-separated list. Multi-select answers retain the selection order so deduped values stay predictable.	{{tags:preferred_features}} might output fast,secure when two tagged options are selected.
{{variable.key}}	When a question saves to a custom variable, the runtime writes the tag value first, keeping downstream placeholders aligned with the normalized taxonomy.	Saving the skin_type question to {{customer.skin}} renders the tag (dry) instead of the raw option label.

How tags behave at runtime

Single-select answers store one tag per question, multiple-select answers push every unique tag into a tags array, and Yes/No answers write either the configured yes/no tag or "Yes"/"No" when the fields are empty. Every tag is sanitized the same way the placeholder renderer does, so the values you get back from the API or dashboard match what you see in the completion copy.

The completion step, thank-you message, and any text field that supports variables can render these values using the {{tag:<questionId>}} and {{tags:<questionId>}} placeholders. The tags variant returns a comma-separated list, even when there is only one value. Use the Insert Tag button (the VariablePicker) to browse both built-in and your custom tag variables when editing copy.

Submissions record both the tag and tags fields inside the answers JSON payload, so the same metadata flows into exports, analytics, and any tooling that reads the submissions API.

Where to use response tags

• Completion copy: Echo the respondent's tag to personalize the headline or CTA.
• Derived variables: When you save a question to a custom variable, the runtime uses the tag value before falling back to the raw answer, so every downstream placeholder shows the normalized tag text.
• Reporting: Filter dashboards or exports by tag to slice your results by the internal taxonomy you defined in the builder.

Custom tags & derived variables

Custom variables act as reusable tags that you can assign to any option or Yes/No response. When you pick + Create new tag..., you are defining a new variable key (lowercase_with_underscores) and optionally giving it a description or default value. Once created, the picker shows every custom tag alongside the built-in placeholders so you can drop it straight into completion copy.

• Use custom tags when you want a consistent taxonomy (e.g., marketing_ready, high_intent, returning_customer) across multiple questions.
• Save a question to a variable via the Save to variable setting so the runtime writes the response tag into {{variable.key}}, making it available in emails, automations, or other placeholders without extra logic.
• Updating a custom tag later affects every future submission while keeping historical data intact because stored tags are normalized when the answer is saved.

Keep this table handy when mapping tags to automations:

Custom tag scenario	Description	Why it helps
{{persona_segment}}	Save a Multiple Choice question to this variable and tag each option with the persona slug.	Use in completion copy or webhooks to dynamically adjust messaging or route respondents.
{{follow_up_tier}}	Multi-select tags map to phases like dry, acne, or sensitive.	Build segments or dashboards that filter submissions by the stored tag array.
{{survey_intent}}	Yes/No tag pairs (e.g., ready_for_pitch vs. needs_more_info).	Control downstream automations (like send a nurture email only for ready_for_pitch).

Tips / Gotchas

• Pick descriptive, machine-friendly keys (lowercase with underscores) because tags double as variable names when inserted into copy.
• Reuse the same tag variable across options that belong to the same persona or segment so your analytics views stay consistent.
• Because Yes/No tags rely on the configurable dropdowns, updating the tag text later also updates every subsequent submission without touching the historical data.