Metadata and Participant attributes

To be able to make a distinction between different customer groups, to personalize your survey etc, we advise to send metadata with your respondents. How you can do this depends on the type of touchpoint you're working with. To learn how to do this for the different touchpoint types, you can consult following sources:


IN THIS ARTICLE
  1. What is metadata?
  2. Adding and managing metadata keys per touchpoint
    1. How to get there
    2. Add a new metadata key
    3. Manage metadata: mandatory and visible
  3. Turning dumb metadata into smart participant attributes
    1. Attribute type
    2. Data type
    3. Context

1. What is metadata?

Metadata is data that describes other data. In the context of Hello Customer, it's data that describes your respondents or the interaction they had with your company. The two main reasons why you would add metadata are:

There are two main types of metadata:

  • Personal data
    • Personal information about the respondent: email address, first name, last name, telephone number, and customer ID. These specific metadata are treated a bit differently than other metadata since they are not available as filters and are mainly used to personalize your survey. On the platform, this metadata is only shown in conversations and is not even there if your touchpoint is anonymous.
    • Information that is not sensitive but is also linked to the person, for example, the gender of a person, the birth date, etc.
  • Transactional data
    • Data that describes the context of the interaction between a customer and a company Examples are:
      • In which city or country did the customer buy an article?
      • Was there a discount on the articles or not?
  • Data about the actual interaction with your company. Examples are:
    • Total amount spent
    • Number of items purchased
    • Purchase date

It is important to decide which metadata you want to send to the Hello Customer platform. Only send along data that you really want to use to personalize your survey or filter on.


... back to top


2. Adding and managing metadata keys per touchpoint

2a. How to get there

You can manage your metadata keys in the settings of the relevant touchpoint.

Option 1: Click on the touchpoint settings icon of the touchpoint of your choice.

Option 2:

Step 1: Click on touchpoints in the left navigation menu

Step 2: Choose the touchpoint you want to add or manage the metadata for. If you do not find your touchpoint immediately, try clicking "show more".

Once you are in the settings of the touchpoint of your choice, you can manage the metadata keys:

2b. Add a new metadata key

To add a new metadata key, click on "Add new metadata" in the manage metadata screen:

  • Choose a name for your new metadata key. In order to work properly, this name needs to be the same as the column name of your Excel or CSV file you use to upload your respondent (Email touchpoints) or needs to match the name you use in your integration code (Website and In-app touchpoints) or URL (Ask Anywhere touchpoints)
  • Indicate if the metadata key is mandatory. In case a key is mandatory, respondents without a value on that key will not receive an invitation email (Email touchpoints) or answers will not be added to the platform (Ask Anywhere, Website and In-app touchpoints)
  • Choose if the metadata key is visible as a filter in the platform.

2c. Managing metadata: mandatory and visible

For existing keys, you can choose whether you want to make them mandatory and if they need to be visible in the platform. You can edit these options for an existing touchpoint by clicking on the checkbox

Mandatory metadata

In Email touchpoints, there are two mandatory fields you need to add for all your respondents:

  • The email address of the respondent; otherwise, we are not able to send out an invitation mail to this person.
  • The language in which you want to survey your respondent. This is the language in which the respondent will receive the invitation email. The person can still change the language of the survey once they fill it out.
However, for each type of touchpoint, you can choose to make certain metadata keys mandatory. If a key is mandatory:
  • Participants in email touchpoints without a value for this metadata key.
  • Answers without values for the mandatory metadata keys integrated in the URL (Ask Anywhere touchpoints) or in the integration code (Website and In-app touchpoints) will not be added to the platform.

Visible metadata

When you make a certain metadata key invisible, it will not be available in the platform to filter on and it will not be displayed in the conversation manager. This is mainly useful if you add metadata to personalize your survey, but that is not handy to filter on. Example:

  • Key = Title
  • Values = "Sir", "Madam"
  • Personalized invitation mail: "Dear Sir", "Dear Madam"

... back to top


3. Turning dumb metadata into smart participant attributes

In order to make filtering on the platform easier than ever, ensure data quality and facilitate analysis across several touchpoints in the future, the concept of participant attributes has been introduced. In the general settings you can find an overview of all the metadata used throughout your organization. Here you can tell the platform of which type of values the metadata exists, so an appropriate filter can be chosen, and you can say whether it's personal or transactional data. This enriched form of metadata is what we call Participant Attributes.

Attributes that are not yet defined, will appear as 'undefined' attributes in the overview below.

3a. Attribute type

As Hello Customer, we noticed that a lot of our customers send similar data to us. Therefore, we created some predefined attributes to allow for market benchmarking in the future and to have predefined data types and context, so you need to choose less settings yourself. As a first step to define your attributes, you can indicate if your participant attribute is one of these predefined attribute types or not. In the dropdown, you will find all possible options. 

IMPORTANT

Choose a pre-defined attribute only once per environment. Otherwise, your filters will not work properly.

If no existing attribute type matches your data, you can select 'custom' to define your own type.

3b. Data type

Next, indicate the right data type, to have optimal filtering options in the platform - for example sliders for numerical data - and to have data validation when data starts flowing in. 

There are standard and custom attributes. If applicable, it is in your best interest to select standard attributes as they can later on be used to compare your results against the market/competition.

These are the standard attributes with their corresponding definitions:

Name Description Data type Context
Age The age the surveyed person had on the moment they had an interaction with the company. Number Transactional
Birthdate The date on which the surveyed person was born. Date Personal
Categories

The type of product / service the surveyed person has / makes use of. Examples:

  • The surveyed person bought clothes from the women collection. Other options would be men / kids collection.
  • In a bank context, people can have high-risk or low-risk investments

Please note that this is only valuable when a customer can only have / make use of one product / service. When they can have / make use of several, it is better to add all separate products / services as custom - boolean.

Text Transactional
Country of transaction

The country where the transaction between the company and the surveyed person took place. Example:

  • Surveyed person went to a shop in France
  • The surveyed person had an appointment in a banking agency located in Belgium
  • Etc
Text Transactional
Customer ID An internal id the company gives to the surveyed person. This is automatically seen as PII in our platform. Text Personal
Date interaction

The date on which the interaction between the company and the surveyed person took place. Examples:

  • Date the surveyed person went to the store
  • Date the surveyed person had an appointment with the bank agent
  • Date the surveyed person called customer service
  • Etc
Date Transactional
E-mail address The email address of the surveyed person. This is automatically seen as PII in our platform. Text Personal
Employee

The employee who got in touch / helped / etc the surveyed person. Examples:

  • Customer service employee that talked to the surveyed person on the phone or answered their email
  • Shop assistant that helped the surveyed person at the counter
Text Transactional
First name The first name of the surveyed person. This is automatically seen as PII in our platform. Text Personal
First time right When helping customers via email or phone, a first time right is true when you can help the person with 1 answer on the email or with 1 phone call. In all other cases, it was not a first time right, so this attribute is false. Boolean Transactional
Gender

The gender of the surveyed person. There are three categories:

  • Female
  • Male
  • Other
Text Personal
Language The language in which the surveyed person was surveyed. Text Personal
Last name The last name of the surveyed person. This is automatically seen as PII in our platform. Text Personal
Participant zipcode The zipcode of the surveyed person. This represents the place where this person lives. Text Personal
Phone number The phone number of the surveyed person. This is automatically seen as PII in our platform. Text Personal
Pieces

The amount of pieces a person bought during a certain transaction. Examples:

  • Amount of clothes a person bought in a shop
  • Amount of dishes ordered in a restaurant
  • etc.
Number Transactional
Reason of contact

The reason why someone had contact with the company. Useful in for example a customer service touchpoint:

  • Product was not delivered
  • Product does not work as expected
  • Product is broken
  • etc
Text Transactional
Team to remove The team filter Text Transactional
Title How you should address a person. This can be used to personalize survey emails, but will be less valuable to filter on. Text Personal
Transaction amount

The value of the transaction the customer had with the company. Examples:

  • Ticket value (in a shop, in a restaurant)
  • Contract value (insurance contract)
  • etc
Currency Transactional
Type of customer

The different types of customer a company has based on a criterium. Examples are:

  • B2C / B2B
  • Bronze / silver / gold
  • etc
Text Personal
Years as customer The amount of years the customer is already a customer of the company (= a measure of loyalty) Number Personal

For the custom attributes, these are the data types you can choose:

  • String: the values can not be ordered. Examples are store names, regions etc.
  • Currency: the values reflect an amount of money. Examples are fees paid, purchase amount etc.
  • Boolean: the values are either true or false. Examples are owner of a loyalty card, VIP-member etc.
  • Date: the values reflect a date in time. Examples are purchase date, beginning of contract etc.
  • Number: the values are numbers and can be ordered. Examples are age, amount of pieces bought etc.

3c. Context

Indicate if your data is personal (linked to the surveyed person) or transactional (linked to the transaction itself). This context will help you ensure that GDPR ruling will be applied correctly and that generic, personal data will be available for all future transactions.

Please not that:

  • Participant attributes mapped as personal will be overwritten every time the same respondent (same email address) is added to the platform
  • Those mapped as transactional are linked to the specific time the respondent was uploaded.

... back to top

Did this answer your question? Thanks for the feedback There was a problem submitting your feedback. Please try again later.

Still need help? Contact Us Contact Us