Skip to main content
A Feedback Record is one piece of feedback expressed in a normalized schema. Whether it came from a survey response, a CSV row, or an API push, it lands in the same shape so you can query everything together.

​
The Feedback Record schema

Every record has the following fields. Required fields must be mapped by every source. The right value_* field is set based on field_type. For example a nps field uses value_number, an open-text comment uses value_text.

​
Metadata on survey records

Records created from a survey response carry the context of that response on every record of the submission, so you can group and segment by it later:
  • Flat keys for the response itself: source, url, browser, os, device, country, action, finished, duration_seconds, ending_id and survey_type.
  • A nested embedded_data object holding the response’s Embedded Data, keyed by field name.
Embedded Data values keep their declared type — text stays text, numbers stay numbers, dates are ISO 8601 strings. A locked field publishes its default value rather than anything supplied with the response, and text values longer than 256 characters are truncated. Four things can leave a declared field out of embedded_data, so do not assume every field appears on every record:
  • The value is missing on that response, or does not match the field’s type, and the field has no default value. A field with a default falls back to it rather than going missing.
  • Two fields share a name. Only one is published: an ingested field wins over a computed one, and between two of the same source, the one declared first. The winner keeps the name even when it has no value on that response, so the other field does not take its place.
  • embedded_data is capped at 8 KiB, measured as its serialized JSON. Once a response’s fields reach it, any further field that does not fit is skipped while smaller ones still publish — so a field may be present on some responses and absent on others.
  • The field is named __proto__. Readers of the record, the record drawer among them, cannot keep a key with that name, so it is not published.
metadata is returned with a record but is not filterable or searchable through the API, so narrowing by a metadata value means fetching and filtering on your side.

​
Viewing and managing records

Inside a workspace, navigate to Analyze → Feedback Data → Feedback Records. You’ll see the latest records across every dataset the workspace has access to, sorted by collected_at. From the table you can:
  • Filter by dataset, source, field type, or date range.
  • Open a record drawer to see the full field set and metadata.
  • Edit values inline for cleanup (e.g. relabel a categorical answer).
  • Delete a record.
  • Add a record manually via the ”+ Add” button.

​
Idempotent imports

Sources that re-ingest data (CSV uploads, API ingestions) use submission_id as the dedup key. Re-importing the same submission_id updates the existing record instead of creating a duplicate.