Embedded Data

Embedded Data is data about this response. A page type, a plan, a campaign, a quiz score, the device the survey was answered on. It rides along with the answers, shows up in the response table and in exports, and can be used in recall, logic and redirect URLs. That makes it the counterpart to contact attributes, which are data about this person and persist across every response they ever give.

​

The Three Sources

Every Embedded Data field has exactly one source, and the source decides who is allowed to write it. Ingested fields are the only ones anything outside the survey can write. Computed fields are set by logic while the respondent answers, and reserved fields are read-only auto-capture, so a URL param or an SDK call naming one of them is dropped and logged rather than stored.

​

Where Values Come From

Which capture channel is available depends on the survey type, and this is the part worth reading twice, because a URL param does nothing for an app survey and setEmbeddedData() does nothing for a link survey. A field does not care which channel filled it. plan is declared the same way, filled by ?plan=pro on a link survey and by setEmbeddedData({ plan: "pro" }) on an app survey, and reads back identically in recall, logic, filters and exports.

​

Declaring a Field

An ingested or computed field has to exist on the survey before anything can fill it. Add it in the survey editor: Hidden Fields for ingested, Variables for computed. Reserved fields are never declared, they are always available. A field’s name is the key you use everywhere: in a URL parameter, in setEmbeddedData(), in recall tokens, in logic operands and as the export column header. Field names follow one rule everywhere, and reserved names are refused for new fields in any casing. The full rule and the refused list live on the Hidden Fields page. A field also carries a type that decides how its value is read back and compared. In this release:

• Hidden fields are string. Anything you pass is stored as text.
• Variables are text or number, and the initial value you set in the editor is the default the field falls back to.
• Reserved fields are typed by Formbricks, and several of them are genuinely numeric: viewportWidth < 768 is a numeric comparison in logic, not a comparison of digit strings.

​

What Happens to an Incoming Value

The same contract runs in the browser when the survey is displayed, and again on the server when the response is saved, so what the client accepts is never taken on trust.

​

Precedence

When two sources offer the same field on the same response, the more explicit one wins:

1. a question’s answer, always, for its own key;
2. an explicit formbricks.track("action", { hiddenFields: { plan: "pro" } }) value;
3. the ambient bag set with setEmbeddedData(), or the URL parameter on a link survey;
4. the field’s default value;
5. otherwise the field is unset.

Reserved fields sit outside this list because they are never written from outside. The one interaction is shadowing: if a survey declares its own field named url or country, that name resolves to the declared field everywhere, and the reserved field of the same name is not offered, listed or exported for that survey.

​

Reading the Values Back

Once a value is on a response it behaves like any other response data:

• Recall it into question copy, ending cards and redirect URLs with #recall:<name>/fallback:<text>#.
• Use it as a logic operand to branch the survey.
• Filter and group responses by it.
• Export it as a stable, typed column in CSV and Excel.

Mid-survey surfaces (recall inside a running survey, logic conditions) can only use values that exist while the respondent is still answering. Server-derived reserved fields such as country or durationSeconds are only known once the response reaches Formbricks, so they are available on the response but not offered to a running survey. The Reserved Fields page marks which is which.

​

Next Steps