Variables & Panel Redirects

A complete guide to the four variable Source options (Static, URL parameter, Panel, and Logic): what each one does, when to use it, and how panel values like transaction_id are captured and passed back to your provider.

In short. A variable's Source decides where its value comes from. To capture a value from the survey link (like transaction_id), set its Source to URL parameter.

---

What "Source" means#

Every survey variable has a Source that controls where its value comes from. Choosing the right Source is the single most important step for capturing data passed on the survey link. All four options store their value as text on each response.

Four variables you already have. Every survey carries Panel Name, Language, Device Type and Panel User ID without you creating anything. See The built-in variables.

Examples throughout use a link like https://app.intuify.com/s/PANTRY.

The info button beside Source#

To change a variable's Source, open the Global Variables panel in the builder, open the variable's More actions menu and choose Edit details. The dialog that opens is headed by the variable's name and reads "Edit how this variable resolves and where it can be referenced."

Beside the Source label there is a small info button, About variable sources. It opens a popover rather than a tooltip, so it stays open until you click away. Under the heading Where the value comes from it lists the four sources you can choose, each with a one line description, and a Learn more link at the bottom opens this page in a new tab.

The dropdown itself offers exactly four options: Static value, URL parameter, Panel and Logic. (The table above shortens the first to Static; the dropdown label is Static value.) Language and Device are not in the list, because the platform assigns those two and you never pick them for a variable of your own. That is also why the four built-in variables below have their Source dropdown disabled: their source is fixed. You can still rename a built-in, and the dialog says so under the greyed-out dropdown.

Renaming a variable#

Change the name in the same Edit details dialog. The new name is applied when you leave the field (click elsewhere, press Enter, or close the dialog with Done), and renaming carries every reference to the variable along with it, as one change you can undo in one step:

• every piped ${gv://Field/<name>} token, in question text and descriptions, answer, row, column and item text, section text, the welcome card, translations, flow blocks (End of Survey messages, Web Service URLs, headers and bodies, assignment values) and anywhere else it is piped;
• the variable name shown on its Set variable assignments, on questions and in flow blocks, and on Web Service response mappings that write to it.

Only the whole name is replaced: renaming score to points leaves ${gv://Field/score2} and ${gv://Field/myscore} alone. A name another variable already uses (letters compared without regard to case) or a blank name is not applied: the field shows why, and the variable and its references keep the old name until you enter one that is free.

When someone else is editing a question that pipes the variable, the rename is saved at once, and the updated token in their question waits until they finish editing it, as with any other change that reaches into something a teammate has open (see Collaboration).

---

Static: a fixed value you type#

The variable holds a constant you set in the builder. It never reads the link, so every respondent gets the same value. The value you type is also the default / fallback other sources use when they have nothing to fill in.

Example: a constant

Watch out. A stray non-blank default on a variable you meant to capture from the link will silently override the link value. If a variable should come from the link, keep its default blank.

Good for: a constant that's the same for everyone (survey version, study tag); a safe default that logic later overwrites. Avoid for: anything passed on the link. It will never be captured.

---

URL parameter: reads the value from the link#

Captures a named query parameter from the survey link and stores it on the response. This is the explicit, reliable way to capture panel IDs and any other value passed on the URL. Recommended for link values.

Example 1: variable name matches the key

Example 2: the display name differs from the key

Create one URL-Parameter variable per key you want to capture (transaction_id, pid, source, RID, …). If the key is absent from the link, the variable falls back to its default.

Good for: panel IDs and any embedded data on the link; when you want capture to be explicit and predictable. Avoid for: values computed during the survey. Use Logic instead.

---

Panel: reads the link value through a Panel you defined#

Binds the variable to a panel you set up in Panels & Quotas. At runtime it reads the link using that panel's URL parameter. Its advantage over URL parameter is that it stays in sync with the panel: rename the panel's parameter and the variable follows automatically.

You usually get this for free. Every survey already carries Panel Name, the name of the provider a respondent came through, and Panel User ID, their panelist ID. There is no second step, and no need to add anything per provider. See The built-in variables below.

Example: bound to a panel

Panel vs URL parameter: which to pick

Pick a panel. A Panel-source variable only captures once you select a panel in the Panel dropdown. Left unselected there is nothing for it to read, and it stays at its default. The builder flags this for you.

Multiple providers. A variable you bind by hand covers exactly one panel. It fills only for respondents who arrive through that provider, and stays at its default otherwise. For attribution across every provider, use the Panel Name / Panel User ID pair instead.

---

The built-in variables#

Every survey has these four from the moment it is created. You do not add them, and they cannot be deleted:

Panel Name, Language and Device Type are pinned to the top of every global-variable dropdown (quota conditions, display and skip logic, flow branches, End-Survey and termination rules, quality-filter rules, and the piping menu), so a rule like "Panel Name is Prodege", "Language is fr" or "Device Type is mobile" takes two clicks and no setup. Panel User ID is always there too, listed with your own variables rather than pinned.

When you build a condition on Panel Name, Language or Device Type, the value box becomes a picker: choose "Prodege" from your configured providers, or "Mobile" from the three device values, rather than typing it. A typo there would produce a rule that silently never matches. The State and Region variables a ZIP Code question's State & Region Lookup creates get the same picker ("NV - Nevada", "West"); see Zip Code.

Showing something to phone respondents only#

Device Type is what gates a section or a randomizer by device. Put a Branch in your survey flow with the condition "Device Type is equal to mobile" and place the sections it protects inside it. Anything behind that branch, including a Randomizer, is skipped entirely for desktop respondents. The same condition works as display logic on a single question.

The value is read from the respondent's browser when they open the survey, so it needs no setup and no URL parameter. A respondent who resumes on a different device is described by the device they are using at that moment.

Neither is tied to a particular provider. Both are filled from whichever panel the respondent actually came through, so one pair covers every provider on the survey: add a second or third provider and nothing further is needed. Every response can then be attributed without adding a variable per panel.

Example: two providers, one pair

A respondent who did not arrive through any configured provider leaves both at their default.

In your data exports

Panel Name and Panel User ID are included in response exports automatically, and you do not add them to anything. A survey with two providers gets one Panel Name column holding the provider each respondent came through, and one Panel User ID column holding their id, so every row can be attributed without a column per provider.

Surveys with no panel providers do not get these two columns at all, so a panel-less export is not padded with empty ones. Surveys created before this existed also export them, filled from the panel recorded on each response, so there is nothing to re-save.

If you built a survey before these were renamed. They used to be called Panel and PanelID. Surveys are updated to the new names automatically when you open them, and any piped text you already wrote against the old names keeps working, so you do not need to re-insert it.

Renaming and deleting are both safe

---

Logic: set during the survey by your flow rules#

The value isn't from the link or a fixed default. It is assigned as the respondent progresses, using variable-assignment actions in your survey flow. It starts at the default and changes when a rule fires.

• Completion flag: Complete, default 0; a rule on the final page sets Complete = 1. Result: 0 if they drop off, 1 if they finish.
• Quality flag from an answer: isCheater, default blank; a rule sets it to 1 when a trap question fails.
• Derive a value: Region, set from the answer to a "which state" question mid-survey.

Good for: completion, quality, and branching flags; values derived from answers. Avoid for: capturing a link value. It stays blank unless a rule sets it.

---

The two variable blocks in the question palette#

Two tiles in the question palette are not questions at all. They sit in the Questions tab of the palette, under Specialized, and neither one asks the respondent anything.

Drag either tile onto the canvas or click its plus, and it lands in the selected section like any other question. Both are answerless: neither takes a question number, neither can be made required, and neither appears in your exported data.

How they differ from setting a variable anywhere else#

Three places touch variables, and they do different jobs.

The block never declares a Source and never captures a link value. It only assigns, exactly like a flow assignment does, so the choice between the two is about where you want the change to be visible while you build. The assignments on a block run as the respondent arrives on the page the block sits on, not when they submit it, so a Display Global Variables block further down the same page already shows the new value. They re-run if an answer on that page changes, and an increment still lands once per visit to the page.

The Settings panel says otherwise. The hint above the editor reads "Its assignments run when the page it sits on is submitted." That line is out of date: the block applies its assignments on page entry.

Setting values with the block#

Select the block and open Settings in the Properties panel. You get the same Set Variables editor the Flow tab uses: click Add, use Select or create variable to pick an existing variable or make a new one on the spot, choose Set (=), Increment (+=), Decrement (-=) or Formula, and type the value. The braces button beside the value box opens Insert Question Answer, which drops a reference to a question's answer in for you, and Add condition (only set when…) attaches a rule so the assignment fires only in the cases you choose.

A block saved with no assignments does nothing, and the builder flags it.

Seeing what a variable currently holds#

A Display Global Variables block lists variables with their values at that point in the survey, in a two column table headed Variable and Value. A variable with nothing in it shows as not set. It is the quickest way to confirm that a URL parameter, a panel binding or an assignment actually landed.

Its Settings hold a Global variables table section. A new block lists every variable in the survey, including ones you add later. Under Variables to show you tick the ones you want instead, or use Select all; once the survey has more than eight variables a search box and a Selected button appear so you can narrow the list. Show variables with no value is on to begin with, so turn it off to leave out the variables that are still empty. Page Break After controls whether the survey moves to a new page after the table.

The table renders wherever the survey runs, including live published links. If you only want it while testing, give it the display-logic rule Mode Is Preview.

Both blocks are covered in more detail in Display blocks & plugins.

The name for these values#

The builder calls them global variables throughout: the Global Variables panel, both palette tiles, the Global Variables group in the piping menu and the Global Variable source in the condition builder. If you have come from another platform and know this idea as "embedded data", that is the same thing. The one place the older term still appears is the response detail view in Analytics, where the values recorded against a response are listed under the heading Embedded Data.

---

The name-match safety net#

As a convenience, if a variable's value is still blank at the start of a session and its name exactly matches a parameter on the link, the platform fills it from that parameter, regardless of the variable's Source. So a blank variable named transaction_id can be captured even if its Source is Static, Panel, or Logic.

Don't rely on it. The safety net only works when the value is blank and the names match exactly, and a later Logic rule can still overwrite it. It's a backstop, not a substitute for the correct Source. For anything important, set URL parameter explicitly.

---

Recommended setup for transaction_id#

1. Create the variable transaction_id.
2. Set Source = URL parameter, URL parameter key = transaction_id.
3. Leave the default value blank.
4. Publish, then test with ?transaction_id=TEST123 and confirm the value on the response.

---

Panel redirect URLs#

When you set a panel's redirect URLs (completion, screen-out, quota return, quality control), the platform automatically appends the panel's URL parameter with the respondent's value on the way back to the provider. You don't add it yourself.

Do

• Enter the provider's return URL without &transaction_id=. The platform adds it.
• Other query parameters are fine; the parameter does not need to be last.

Don't

• Don't hard-code a fixed value like &transaction_id=OLD. The platform respects a non-empty value you put there and won't overwrite it, so a stale value would be sent back.
• A leftover blank &transaction_id= is now safe: the platform fills it with the respondent's value automatically (it no longer sends the blank). It doesn't have to be the last parameter. You still don't need to add the key yourself.
• Watch for typos in the path (e.g. transactnio-completion). They break the redirect.

---

What happens in each case#

Two independent things happen with a link value: it can be stored on the response (driven by your variable) and it can be passed back to the panel on redirect (driven by the panel). Same link, ?transaction_id=ABC123, panel parameter transaction_id.

The redirect works either way because it reads the entry link through the panel. What you lose by skipping the variable (or using the wrong Source) is the clean, named, exportable capture in your data.

---

Where captured values appear#

• Named variable: a clean field under the variable's own name, shown on the response, included in CSV exports, and usable in piped text and logic. This only exists if you defined the variable.
• Panel respondent ID: when a respondent enters through a panel, the panel they matched and their id from it are recorded on the response, independent of any variable.
• Raw link parameters: every parameter on the entry link is kept with the response even when no variable captures it. It is a fallback record, not a named field, and it is not broken out in exports the way a variable is.

If you forget the variable, the value is still kept with the response, but it won't appear as a tidy transaction_id column you can filter and export. Define the variable to get the clean capture.

---

Troubleshooting: "it isn't capturing"#

---

Quick checklist#

• Every link value has a variable with Source = URL parameter (not Static / Logic).
• The URL-parameter key matches what's on the link (e.g. transaction_id).
• The default value is blank.
• Panel redirect URLs do not contain a hard-coded non-empty &transaction_id=value (a blank &transaction_id= is now filled automatically; a fixed value is passed through as-is).
• Redirect URLs have no typos in the path.
• Published, then verified with a real test link (?transaction_id=TEST123).

---

Related guides#

• Distributions & Sharing Links
• Fielding & Respondent Experience
• Analytics & Responses
• Logic, Flow & Conditions