Pushing metadata

Metadata is the extra context you attach to a response — who the respondent is and what they just did. A score of 9 out of 10 is useful; a 9 from a loyalty-card holder who just completed a €200 order in your Athens store is far more useful. Metadata is what turns raw answers into something you can slice, target, and act on.

You push metadata with a single method, Esat.updateMetadata, once collection is installed on your website or through Google Tag Manager.

Why metadata matters

Metadata is the payoff of installation. Once a response carries context, you can:

• Build segments — group respondents by who they are and what they did, not just how they answered.
• Drive routing rules — send a detractor from a high-value order down a different path than a low-value one.
• Set pipeline conditions — trigger follow-ups based on the transaction, the region, or the customer profile.

Without metadata, every response looks the same except for its answers. With it, you can ask sharper questions of your data and respond to the right people automatically.

Responder vs questionnaire metadata

Metadata comes in two buckets, and the distinction is simple:

• Responder metadata describes the person — things that are true about them regardless of this particular interaction. Gender, age, a loyalty-card ID, their region.
• Questionnaire metadata describes the transaction or context — things about the specific event that prompted the survey. An order ID, the order date, its value, the store it came from.

Here's the call with one example of each:

Esat.updateMetadata('YOUR-QUESTIONNAIRE-ID', {
  responder: {
    gender: 'male',
    age: 18,
    loyalty_card_id: '12345'
  },
  questionnaire: {
    transaction_id: '1234567890',
    transaction_date: '2018-02-25 15:20:32'
  }
});

The first argument is the questionnaire ID of the survey you're tagging; the second is an object with responder and questionnaire blocks. You can include either block, both, or as many fields as you've defined.

Define your fields first

Pushing a field that the dashboard doesn't know about won't get you anywhere — the names you send have to match names you've already defined.

Timing and case-sensitivity

Two details determine whether your metadata actually lands on the response:

• Push before or while the survey is shown. Call updateMetadata before the survey appears, or while it's on screen — not after the respondent has already finished.
• The questionnaire ID is case-sensitive. Copy it exactly from the dashboard; Abc123 and abc123 are not the same survey.

Fields collected automatically

A few useful facts are gathered for you, so you don't need to send them:

• user_agent — the respondent's browser and device.
• country — derived automatically.
• url — the page the survey was answered on.

You can override these, but it's not recommended — let collection fill them in.

How metadata feeds the rest of Survey Manager

Once metadata is flowing, it becomes the raw material for targeting throughout Survey Manager. The same region or transaction_value you push here is what you'll reach for when you build a segment, write a routing condition, or set a pipeline rule. Defining your fields thoughtfully up front — and pushing them consistently — is what makes all of that downstream targeting possible.

Related articles