What is a metadata?

Before analyzing your results, learn what a metadata field is and discover how it enriches the context and the use of your feedbacks.

Table of contents

Understand metadata

Use metadata

Configure metadata

Best practices  

Understand metadata

Overview of metadata

Metadata, also called "additional data", refers to all supplementary information related to a contact or a respondent. It may sometimes correspond to data coming from survey feedbacks.

In the SatisFactory platform, each contact (and therefore respondent) is identified by a unique identifier: their client_id or customer_id. At the same time, a single contact may have experienced one or several interactions with the organization.

Therefore, for each new experience, the same client_id may have several specific linked experience_id values. This may correspond to an order number, but it can also be automatically concatenated with the date of the experience, for example.

Beyond these two mandatory pieces of information, all other metadata enrich the context of each feedback.

There are 5 metadata categories:

*The "System" and "Experience" categories are reserved for the internal functioning of the platform. They cannot be selected when creating a new metadata field.

Detailed overview of metadata

While natively integrating the metadata essential for technical processing and the display of elements in the interface, the platform also provides flexibility for customized configuration.

You therefore have the option, either independently or with SatisFactory support, to create optional fields to perfectly align collection with your project needs.

The different types (or formats) of metadata

Although the default format is suitable for the majority of uses, you have the power to define a specific type. The important thing is to guarantee consistency between the chosen format and the nature of the data collected by the metadata.

⚠️ If the value of the metadata is not received in the expected format, the entire contact linked to this metadata will be rejected.

The different statuses of metadata

Metadata statuses govern the display and use of your metadata in certain key features of the platform. These options can be activated or deactivated freely and at any time from the administration center (learn more).

• Private status of the metadata

By activating this option, you identify this metadata as Private Data. Its retention period will then be automatically aligned with that defined in the program settings (learn more).

• Mandatory status of the metadata

By activating this option, you identify this metadata as required.

If the value of the metadata is absent in the incoming flow, the entire contact linked to this metadata will be rejected.

• Filterable status of the metadata

By activating this option, you identify this metadata as filterable. It will therefore be available in the filters accessible on the platform (learn more).

• Analyzable status of the metadata

By activating this option, you identify this metadata as analyzable. It can therefore be analyzed in the platform (in the "Indicators details" section as well as in the widgets).

• Multiple values option for the metadata

By activating this option, you identify this metadata as being able to include several distinct values.

If this option is not activated, the multiple values collected by the metadata will be concatenated into a single string (e.g.: "Value1Value2Value3") and it will be necessary to perform a history recovery to separate the values.

Metadata integrity constraints

To guarantee the reliability of your data, you can define integrity constraints. This validation mechanism allows you to control data compliance and protect yourself against potential errors by filtering the incoming flow to reject non-compliant values.

SatisFactory offers several integrity control mechanisms:

• "Mandatory" status of the metadata: Requires the presence of data; if the value of the metadata is absent or empty, the contact is rejected in its entirety
• Metadata type compliance: Verifies that the data respects the defined format if it is specific (Date or Numeric); if the value of the metadata is in an inappropriate format, the contact is rejected in its entirety
• Closed list of values: Restricts the accepted data to a predefined list during the program launch; if the value of the metadata does not strictly correspond to the defined list (including case sensitivity), the contact is rejected in its entirety
• "Multiple values" status of the metadata: Allows several distinct values to be accepted for the same metadata; values must be separated by "@@@" (example: "site1@@@site2@@@site3")

💭 The integrity constraint is unitary and acts contact by contact. Thanks to this selective processing, only contacts in error are rejected when the file is processed in the incoming flow, which ensures the successful integration of the rest of the valid contacts into the platform.

Native metadata categories

The "System" and "Experience" metadata categories are dedicated to the internal functioning of the platform. They are predefined and cannot be chosen when creating new metadata on the platform.

System metadata

Only the "client_id" metadata is mandatory, all other system metadata are optional and structural. These can be defined at the launch of the program to enrich and illustrate the header of customer files during interaction processing or during customer relationship monitoring. Most are therefore specific to each account and adapted to the specific needs of the organization.

• client_id or customer_id (type "String"): Unique identifier related to a specific contact
• name (type "String"): Contact first name
• lastname (type "String"): Contact last name
• tel (type "String"): Contact phone number; must be populated to allow logging a call and distributing a survey via SMS or IVR
• email (type "String"): Contact email address; must be populated to allow sending a reply email and distributing a survey via email

💭 If a contact is imported several times with the same client_id, their metadata will be replaced by those of the latest experience.

Example:

• Experience 1 10/01/2024 - client_id "123456" ; experience_id "20240110_order" : name "Durand"
• Experience 2 21/11/2025 - client_id "123456" ; experience_id "20251121_order" : name "Dupond born Durand"

→ The "name" metadata of the contact will be automatically updated in the platform for Experience 1 and 2.

Experience metadata

Only the "experience_id" metadata is mandatory, however the others are required to correctly associate the contact with the targeted survey, both at the data flow level and the platform interface level. The experience metadata setting the reference date of the contact is defined at the program launch: it can correspond either to the feedback date, the experience date, or even the import date (during external data integration).

• experience_id (type "String"): Unique identifier relative to the experience of a contact with the organization (visit, purchase, subscription, order, contact, etc.)
• channel (type "String"): Distribution channel used to solicit the contact or retrieve feedbacks; the accepted values are "email", "sms", "web", "svi", "google", "trustpilot", "tripadvisor", "booking", "facebook", "expedia", "thefork", "googleplaystore" and "appstore"
• source (type "String"): Name of the survey, type, subject or survey segment; accepted values are free to allow increased customization of monitoring except for social networks where the source is imposed by the original platform
• feedback_date (type "Date"): Contact feedback date; displayed as the contact return date in the customer file if it is configured as such; accepted values must be in ISO 8601 format
• experience_date (type "Date"): Date of the experience lived by the contact; displayed as the contact return date in the customer file if it is configured as such; accepted values must be in ISO 8601 format
• date_analyse (type "Date"): Contact import date; displayed as the contact return date in the customer file if it is configured as such; accepted values must be in ISO 8601 format

⚠️ Since the experience_id is not anonymizable, it is imperative that it does not contain any personal data.

Use metadata

By bringing context and granularity to your data, metadata are essential drivers to:

Identify and route

• Ensure automatic routing of contacts to the appropriate surveys and channels
• Follow precise customer interactions in surveys and the steps of the customer journey they followed
• Clearly identify the contact in their customer file

Personalize the experience

• Adapt invitations (Email, SMS) to the contact profile
• Script the survey and condition the display of questions in real time

Analyze and monitor

• Segment respondents (by typology, location, behavior, etc.)
• Filter dashboards and compare performance between different sites or services

Configure metadata

Access metadata management

From the platform's administration center, you can create, modify, and delete the metadata of your account.

⚠️ The administration center is only accessible to users whose profile holds administrator privileges ("Manage").

To do this, from the platform's left sidebar, access the administration center by clicking on the "Administration" tab.

Then, in the administration center's left sidebar, expand the "Data and indicators" section, then click on the "Metadata" sub-section.

Manage metadata

Master the creation, modification, and deletion of metadata (additional data) for your account by consulting our dedicated article: Manage metadata.

Hide metadata for certain user profiles

In order to guarantee the confidentiality of the information shared, the platform allows you to define visibility scopes specific to each user profile (headquarters, region, etc.). However, you also have the possibility to exclude specific metadata deemed sensitive, strategic, or irrelevant for certain user profiles. To do this, it is necessary to access the platform's administration center, expand the "Users and roles" section and access the "Profiles" page.

Access the editing of the concerned profile and activate the "Metadata to exclude" option. Then simply select the metadata that you wish to hide for this user profile.

Once these exclusions are defined, metadata will be automatically hidden for the selected user profile at the level of:

• customer files
• metadata filters
• dashboard widgets
• reports
• exports
• cross-tabulations

Best practices

Validate the objective of each metadata

Focus on your analysis and usage objectives: consider each metadata as an element that must bring real value to your program, whether it is to segment the data flow, refine the analysis, or even contextualize or personalize the journeys.

Standardize metadata to guarantee information uniqueness

Metadata must provide lasting and shared information: this means that they must be defined and updated collaboratively by involving all users. It is therefore necessary not to duplicate them (examples: "survey name 1", "survey title 2", etc.).

Harmonize labels to facilitate metadata usage

Respect a writing logic in the labeling of metadata for better readability when using filters in the platform.

For further assistance or to report a specific issue, please contact our Support team.