Metadata
Metadata is extra information, in the form of key-value pairs, that travels with each questionnaire response. A score of 9 out of 10 tells you something; a 9 from a loyalty-card holder who just placed a €200 order in your Athens store tells you far more. Metadata is what adds that context — and it's what lets you segment, filter, route and alert on who answered and what they'd just done, not only on how they answered.
A key like order_id paired with a value like A-10428 is a single piece of metadata. You decide which keys your organization uses, the platform provides a set of its own, and the values arrive with each survey as it's sent or shown. You'll find the full list in the Admin Panel under Data & AI → Metadata.
This page explains how metadata is organized: the two kinds, the four types, the levels it's defined at, and the fields the platform manages for you.
Two kinds of metadata
Metadata is divided by who the information belongs to.
| Kind | Describes | Examples |
|---|---|---|
| Questionnaire metadata | The customer experience itself — the transaction or interaction that prompted the survey. | Order ID, order date, order value, the products ordered, the store or channel. |
| Responder metadata | The person answering — things that stay true about them regardless of this particular interaction. | Email, phone number, gender, age, loyalty-card ID, customer tier. |
A quick way to decide: if the value would change the next time the same customer buys something, it's questionnaire metadata. If it would stay the same, it's responder metadata.
The distinction matters beyond tidiness. Responder metadata builds up the customer's profile in Customers, while questionnaire metadata stays attached to the one response it came with. Throughout the suite — in chart axes and filters, segments, router conditions and follow-up sequences — you pick between Questionnaire metadata and Responder metadata first, then the field.
What makes up a metadata field
Every metadata field, whichever kind it is, is described by the same few properties.
| Property | What it is |
|---|---|
| Title | The friendly label people see across the dashboards — for example Customer Segment. You can change it at any time. |
| Name | The key the value is matched on when metadata is pushed — from your website, the API, queue items and imports. For example customer_segment. |
| Description | An optional note explaining what the field captures, so everyone uses it the same way. |
| Type | What kind of value the field holds: text, number, date or boolean. See Metadata types below. |
| Private | Whether the field's values contain personal data that should be anonymized under your data retention settings. See Private metadata below. |
Naming rules
The name is the part your integration code depends on, so it follows strict rules:
- Use only lowercase letters, digits and underscores — no spaces, capitals, hyphens or accents.
order_valueandordervalueare valid;Order Valueandorder-valueare not. - The name is fixed once the field is created. It identifies the field across all the data already collected, so it can't be renamed later — only the title, description, type and privacy setting can change.
- Names must match exactly when you push values. A value sent as
orderValuewon't land in a field namedorder_value.
Settle on names before you integrate
Pick clear, consistent names up front and reuse them everywhere — the same store or transaction_value on every survey. Consistent names are what make responses line up when you segment and compare them later, and since names can't be renamed, it's much easier to get them right before your developers start pushing data.
Metadata types
Every field has a type. The type tells the platform how to understand the value, which in turn decides how you can compare it in conditions and filters across the suite.
| Type | Holds | Example values | Useful for |
|---|---|---|---|
| Text | Any string of characters. The default type. | Athens Central, gold, A-10428 | Matching exact values or parts of a value — equals, contains, begins with. |
| Number | A numeric value. | 18, 199.90, 3 | Ranges and thresholds — greater than, less or equal. |
| Date | A date, or a date and time. | 2026-02-25, 2026-02-25 15:20:32 | Comparing when something happened — before or after a given moment. |
| Boolean | A yes/no value. | true, false | Simple on/off facts, such as whether a customer is a loyalty member. |
Choosing the right type makes a real difference. Store an order value as text and "greater than 100" can't behave the way you'd expect, because the platform compares it as characters rather than as an amount. Store it as a number and you can target high-value orders precisely.
Types guide comparisons, not what you can send
The value you send is always kept exactly as it was sent, and the platform also stores it in the form its type expects — a number as a number, a date as a date. It's that typed form that filters and conditions compare against, so a number field sent n/a, or a date field sent last Tuesday, won't compare the way you'd hope. Keep values in the format the type expects.
Levels: global, workspace type and organization
Metadata is defined at one of three levels, which decide where a field is available and who manages it. The Admin Panel shows each field's level in the Level column.
| Level | Available to | Managed by | Can you edit it? |
|---|---|---|---|
| Global | Every workspace on the platform. | e-satisfaction | No |
| Workspace type | Only workspaces of a particular business type — shown by the type's name. | e-satisfaction | No |
| Organization | Every workspace in your organization. | Your organization | Yes |
Global metadata
Out of the box, e-satisfaction provides a set of global metadata that every workspace can use without any setup. These cover the details almost every survey benefits from, such as the responder's email and phone_number, or a transaction_id and transaction_date for the interaction. Some global fields are filled in automatically by the platform; see Read-only metadata.
Workspace-type metadata
Some fields only make sense for a certain kind of business. Workspace-type metadata is provided by e-satisfaction for workspaces of a specific business type only — so fields that only suit one industry appear for the workspaces in it without cluttering the list for everyone else. Which of these you see depends on the type of your workspaces.
Organization metadata
Organization metadata is the custom metadata you create for your own business — a loyalty tier, a region code, a sales channel, whatever your reporting needs. A few things are worth knowing:
- A new field is created on every workspace in your organization at once, so the same key is ready to use wherever you collect feedback.
- Editing a field updates it across all your workspaces together.
- Deleting a field removes it from every workspace. Responses already collected keep their values — deleting only stops the field being available from then on.
Use what already exists first
Before creating a field, check the global and workspace-type lists. If a platform field already captures what you need — an email, a transaction date — use it rather than creating your own duplicate. Built-in fields are the ones other features, like messaging pipelines, already know how to use.
Read-only metadata
Some global metadata is used by the platform itself, to track where each response came from and to make the rest of the suite smarter. These fields are read-only: the platform fills in their values automatically, so you can read, filter and segment on them, but you shouldn't set them yourself.
| Field | What the platform records |
|---|---|
channel | The channel the survey reached the responder through, such as email, SMS or Viber. |
pipeline | The messaging pipeline that sent the survey. |
responder_channel_identifier | The address the survey was sent to on that channel — the email address or phone number. |
invoker | What triggered the survey, for example a specific pipeline queue item. |
referrer | The web page the responder came from before reaching the survey. |
country | The responder's country, derived automatically. |
Don't push read-only metadata
Read-only fields are for internal use. Avoid sending them from your integration script or through the API — any value you push will be overwritten by the one the platform records. If you need to capture something similar in your own words, create an organization field with a different name.
Because the platform owns these values, they also aren't copied forward when one survey leads to another. When a follow-up sequence sends a new survey, the follow-up carries over your own questionnaire metadata, while its channel, pipeline and similar read-only fields are recorded fresh for the new send — so each response always describes how it was delivered.
Alongside the read-only fields, the web integration also collects a few details automatically, such as the responder's browser and the page the survey was answered on.
Private metadata
Some metadata holds personal data — an email address, a phone number, a name. Mark a field Private and its values are treated as personal information: when data anonymization is turned on, private values are hashed once they reach the age you've chosen, alongside the rest of your personal data.
- Fields that aren't private show as Public and are never anonymized — they keep their values for as long as the data itself is retained.
- Anonymization hashes values rather than blanking them, so features that depend on recognizing the same person, such as frequency caps, keep working.
- Anonymization only happens when it's switched on for your organization. Marking a field private on its own changes nothing until then.
Mark personal fields private from the start
If a field could ever contain something that identifies a person, mark it Private when you create it. That way its values are covered as soon as your retention policy applies, instead of relying on someone remembering to change it later.
How metadata values arrive
Metadata values are attached when a survey is created for a responder — its questionnaire instance. There are a few routes, and the same field names work on all of them:
- On your website — push values with the web integration while the survey is shown. See Pushing metadata.
- Through the API and the Events Router — send values with the transactions you pass from your own systems. See Developer & API and the events router.
- With queue items and imports — include metadata when you add recipients to the dispatch queue, whether one by one, from a file, or through a data bridge.
- Automatically — read-only and automatically collected fields are filled in by the platform.
Define the field first
Values are matched to fields by name, so create the field — with the right type — before you start sending it. That way every value lands in a field your team can see, filter and build conditions on from the very first response.
Where metadata is used
Once values are flowing, metadata becomes the raw material for almost everything that slices or targets your feedback:
- Insights — break results down and filter by any field, in charts, Raw Data, comments and the performance reports.
- Segments — group responders by who they are and what they did.
- Router conditions and pipelines — decide which messages send, and through which channel.
- Follow-up sequences — only follow up when the metadata matches.
- Alert rules — raise issues for the customers and transactions that matter most.
- Customers — see responder metadata on each customer's profile.
- Data pipelines — take metadata with you into your own data warehouse.