Variables & Panel Redirects

A complete guide to the four variable Source options — Static, URL Parameter, Panel, and Logic — how each behaves, 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.

---

Static — a fixed value you type#

The variable holds a constant you set in the builder. It never reads the link — 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.

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 — 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 — 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 — 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's 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.

Setting a value from the canvas instead of the Flow tab#

Assignments don't have to live in the Flow tab. Add a Create Global Variable block from the question palette and you get the same Set Variables editor inline, right where you want the value to change. Respondents see nothing — the assignment runs and the survey moves on. See Display blocks & plugins.

Seeing what a variable currently holds#

While you build, a Display Global Variables block shows a table of every variable and its current value at that point in the survey — the quickest way to confirm a URL parameter, panel binding, or assignment actually landed. It renders on live links too, so if you only want it while testing, give it the display-logic rule Mode Is Preview. See Display blocks & plugins.

---

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, 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 (variables.<name>) — the clean field shown in the Data view, 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 matched panel and its value are recorded on the response's panel field, independent of any variable.
• Raw URL parameters — every parameter on the entry link is stored as raw metadata, even with no variable. It's a fallback record, not a clean named field, and isn't broken out in exports the way a variable is.

If you forget the variable, the value still exists in raw metadata (and the panel field) — 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