Interview links

An AskEngine study collects interviews through a shareable link. You send someone a link, they talk to the interviewer, and the transcript flows back into your studies and signals. This page covers the two things worth understanding before you start sharing links: how the links themselves behave, and how participant metadata gets attached.

Two kinds of link

Every link lives at /i/{slug} and is one of two kinds:

Channel — a reusable, public link. Share it in a tweet, an email blast, a help-doc footer. It's uncapped by default, and every study gets a "Default" channel link automatically.
Personal — a single-use link for one specific person. It's capped at one interview by default, and it can carry that person's details baked in (more on that below).

Links move through three states — active, paused, and revoked. Pausing is reversible; revoking is permanent. A link can also carry an optional expiry time. When someone opens a link, AskEngine checks it in order: revoked, then paused, then expired, then whether it's hit its cap.

Two things that trip people up:

Opening a link never uses it up. A use is only counted when an interview actually starts.
Failed interviews don't count against a link's cap.

Metadata

Every interview can carry metadata — arbitrary key/value details about the participant, like their plan tier, signup date, or role. Metadata is how you slice signals later ("what do enterprise users think?"), so it's worth getting on every interview you can.

There are two ways to attach it: query params on the link, and baked-in values on a personal link.

Field keys

Your study defines its fields with human labels like First name or Email address. Under the hood each label becomes a field key by a simple, predictable transform:

lowercase it
replace every character that isn't a letter, number, or underscore with _
collapse repeated underscores
trim any leading or trailing underscore

So First name becomes the key first_name. To pass a value in a URL, prefix the key with f_:

https://yourteam.askengine.app/i/{slug}?f_first_name=Ada&f_email_address=ada@example.com

If a field is prefilled this way, the participant never sees it — they skip straight past that question. Anything not prefilled, they'll be asked for. A couple of details: passing an empty value (?f_first_name=) clears a query-param prefill (it can't touch a baked-in value), and if two labels happen to reduce to the same key, the first one wins.

Only fields your study actually declares are ever stored. Unknown f_* params are quietly ignored, so you can't smuggle in extra data by adding params.

Baked-in values

When you create a personal link, you can fill in that person's details up front. Those values are stamped onto the link itself — you don't put them in the URL, and the participant can't change them. This is the right tool when you already know who you're inviting.

Which value wins

When the same field is set in more than one place, the more authoritative source wins. From lowest to highest priority:

lowest   query param (?f_…)
         what the participant types
highest  personal-link baked-in value

In other words, query params are a suggestion, the participant can override them by typing, and a baked-in personal-link value beats both. Query params can add new fields, but on a conflict the link's own value is the source of truth.

Identity keys

A few field keys are special — AskEngine uses them to recognize who a participant is and how to label them, so the same person across two interviews resolves to one participant. These are ordinary fields: declare them on the study and pass them like any other f_* param or baked-in value.

Match keys decide identity, in order of preference: uid, then email, then email_address.
Display keys are just for showing a friendly name: name, then first_name, then username (falling back to email).

If you can pass a stable uid or email, do — it's what lets AskEngine tie repeat interviews back to the same person.