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 before anything can fill it, and there are two places to declare one:

• In the survey editor, for a field only that survey uses: the Embedded Data card, where one dialog creates either source.
• In Settings → Workspace → Embedded Data, for a field the whole workspace shares. A field declared there can be linked from any survey, and editing it once changes it for every survey using it. The same page lists which surveys use each field, and refuses to delete one that is still in use. See Field library.

Reserved fields are never declared, they are always available. A passed-in field carries two things you type, and they do different jobs. Its name is what you call it — what the response table, the summary and your exports show, renameable at any time. Its key is the address the value lives under: the URL parameter, the SDK key, and what recall and logic resolve. The key fills itself in from the name, and cannot change once the field exists, because responses are already stored under it. A calculated field added on a survey has a name only; one in the library also takes a key, because that is how other surveys find it. Either way its storage address is generated. Keys 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:

• Passed-in fields can be string, number, boolean or date, wherever they are declared, and incoming values are coerced to the declared type.
• Calculated fields are text or number — the types survey logic can produce — and the initial value you set 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