> ## Documentation Index
> Fetch the complete documentation index at: https://greatquestion.co/support/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom Candidate and Study Attributes

> Add your own structured fields to candidates and studies for segmentation, organization, and reporting.

Custom attributes let you add your own structured fields to candidates and studies, beyond what Great Question tracks by default, so you can segment, filter, and organize research your way.

## Candidate Attributes vs. Study Attributes

Both use the same underlying mechanism, but they describe different things:

* **Candidate attributes** describe a **person**, role, company, plan tier, anything you want to track about a candidate. They live on the candidate's profile, carry across every study they're part of, and power filtering and segmentation on the Candidates page.
* **Study attributes** describe a **study**, a product area, a quarter, an internal tag. They're for organizing, filtering, and sorting your **Studies list**, not for tracking anything about individual participants.

> **Note:** A study attribute will never show up as a column in a study's Participants list, it describes the study as a whole, not each participant in it. If you want a field that shows up per-participant, you want a **candidate attribute**, not a study attribute.

## Default (System) Fields

Every candidate already has a set of default fields before you create a single custom attribute:

| Field                          | Type          | What It Tracks                                                        |
| ------------------------------ | ------------- | --------------------------------------------------------------------- |
| Name                           | Text          | A candidate's full name.                                              |
| First name / Last name         | Text (hidden) | Used internally to build the full name.                               |
| Email                          | Text          | Used for contacting a candidate, and as their unique identifier.      |
| Phone number                   | Text          | The candidate's contact number.                                       |
| Timezone                       | Text          | Automatically collected from the candidate's location at signup.      |
| Opt-in                         | True/False    | Whether the candidate has agreed to be contacted for future research. |
| Opt-in date                    | Datetime      | When the candidate opted in.                                          |
| Unsubscribed at                | Datetime      | When (if ever) the candidate unsubscribed from communication.         |
| Opt-out URL                    | URL (hidden)  | The link a candidate uses to unsubscribe.                             |
| # of studies                   | Number        | Total studies associated with the candidate.                          |
| # of completed studies         | Number        | Studies the candidate has completed.                                  |
| # of invited studies           | Number        | Studies the candidate was invited to.                                 |
| # of responded studies         | Number        | Studies where the candidate started, applied, or booked.              |
| Incentives Paid (All Time)     | Number        | Total incentive paid to the candidate, all time.                      |
| Incentives Paid (Current Year) | Number        | Total incentive paid to the candidate this year.                      |
| Average rating                 | Number        | The average rating assigned to the candidate.                         |

If a candidate was sourced through **External Recruitment**, Great Question also auto-populates additional third-party fields once they respond. These appear automatically for candidates recruited that way, you don't create or manage them like a custom attribute.

**Respondent-sourced fields:**

| Field            | Type            |
| ---------------- | --------------- |
| LinkedIn         | URL             |
| Skills           | Multiple values |
| Job Title        | Text            |
| Job Functions    | Multiple values |
| Company          | Text            |
| Company Size     | Text            |
| Country Code     | Text            |
| Location         | Text            |
| Gender           | Text            |
| Age              | Text            |
| Education Level  | Text            |
| Ethnicity        | Text            |
| Household Income | Text            |
| Industry         | Multiple values |
| Seniority Level  | Text            |

**User Interviews-sourced fields:**

| Field            | Type            |
| ---------------- | --------------- |
| Skills           | Multiple values |
| Job Title        | Text            |
| Company          | Text            |
| Company Size     | Text            |
| Country Code     | Text            |
| Location         | Text            |
| Gender           | Text            |
| Age              | Text            |
| Education Level  | Text            |
| Ethnicity        | Text            |
| Household Income | Text            |
| Industry         | Text            |
| Seniority Level  | Text            |

> **Note:** User Interviews doesn't provide a LinkedIn or Job Functions field the way Respondent does, and its Industry field is plain text rather than multiple values.

Study attributes don't have an equivalent default set, every study attribute is one your team creates. There's no built-in system-generated study attribute today.

## Why It Matters

**Track what actually matters to your research.** Go beyond Great Question's default fields to capture whatever is relevant to your team — role, industry, product usage, or anything else.

**Power segmentation and targeting.** Candidate attributes are what segments and filters are built on, so richer attributes mean more precise recruiting later.

**Organize studies at scale.** Study attributes let you filter, sort, and group your Studies list by product area, initiative, or whatever organizing scheme your team uses.

**Feed eligibility rules with your own criteria.** On Enterprise plans, custom eligibility rules can use candidate attributes as criteria, see [Candidate Eligibility Settings](/support/support/candidates/candidate-eligibility-settings).

## Common Use Cases

| Use Case                                                      | Attribute Type                             |
| ------------------------------------------------------------- | ------------------------------------------ |
| Track a candidate's role, company, or plan tier               | Candidate attribute                        |
| Capture campaign or referral source automatically from a link | Candidate attribute, set via URL parameter |
| Tag studies by product area or quarter for reporting          | Study attribute                            |
| Build segments to target recruiting                           | Candidate attribute                        |
| Feed custom eligibility criteria                              | Candidate attribute                        |

## Data Types

Both candidate and study attributes support the same set of types:

| Type            | Behavior                                                                                                             |
| --------------- | -------------------------------------------------------------------------------------------------------------------- |
| Text            | An autocomplete field that suggests values you've already used elsewhere — closer to a "pick or type" single-select. |
| Free text       | A plain, unstructured text box with no suggestions.                                                                  |
| Number          | Numeric values only.                                                                                                 |
| URL             | A web address.                                                                                                       |
| Multiple values | True multi-select, shown as chips.                                                                                   |
| Datetime        | A specific date and time.                                                                                            |
| True/False      | A simple boolean toggle.                                                                                             |

## Creating an Attribute

1. Go to **Settings → [Custom attributes](https://greatquestion.co/support/candidates/candidate-eligibility-settings)**[.](https://greatquestion.co/support/candidates/candidate-eligibility-settings)
2. Choose the **Candidates attributes** or **Study attributes** tab, depending on which you're creating.
3. Click **New candidate attribute** or **New study attribute**.
4. Set a **Name**, **Attribute type**, and optional **Description**.
5. Turn on any relevant toggles: **Unique** (candidate attributes only — see note below), **Personally identifiable information (PII)**, **Health Information** (requires the HIPAA add-on), or **Can be set via a url parameter**.
6. Save.

> **Note:** The attribute type, and its underlying key, can't be changed once created; only the label can be edited afterward. Plan the type out before creating one, since switching later means creating a new attribute rather than converting the existing one.

> **Note:** Attribute names are unique across your **whole account**, not just within a team. If creating an attribute fails, check whether another attribute, of any type, created by any team, is already using that name.

> **Note:** **Unique** is a beta feature (may require Great Question to enable it for your account) intended to let an attribute act as a matching identifier during candidate import, similar to email. As of today, uniqueness isn't actually enforced, treat it as a label for future matching rather than a working deduplication mechanism.

**Who can create or edit attribute definitions** depends on your account's permission settings, not a fixed role — check **Settings → Governance → [Permissions](https://greatquestion.co/governance/permissions) → "Creating custom attributes"** to see or change who has access.

## Populating Attribute Values

**Candidate attributes** can be set:

* Manually, from a candidate's profile using **Add attribute**.
* In bulk, from the Candidates list using **Add or update attributes**.
* Through CSV import, by mapping a column to an existing (or new) attribute.
* Through a signup form or screener's **Attributes** mapping, which writes responses back to the candidate's profile. Question and attribute types need to be compatible, multi-select questions only map to **Multiple values** attributes, date questions only to **Datetime**, and yes/no questions only to **True/False**.
* Automatically via a URL parameter, if **Can be set via a url parameter** is enabled, see [URL Parameters](/support/support/candidates/using-url-parameters).
* Through a connected CRM integration (Salesforce, Databricks, or Snowflake field mapping).

**Study attributes** are set directly on the study, from the Plan step during setup, or from the study's custom attributes panel afterward.

## Filtering and Displaying Attributes in Tables

The account-wide **Candidates** list and a study's **Participants** tab use the same filter and column controls, so once you know one, you know both.

### Filtering by an Attribute

1. Click **Filter** (or the **Add filter** input, shown automatically if no filters are applied yet).
2. Search for and select the candidate attribute you want to filter by.
3. Click the resulting filter chip to choose an operator (for example, "is equal to," "contains," or "includes any of" for Multiple values attributes) and enter a value.
4. Click **Apply**.

> **Note:** Study attributes can't be used to filter a study's Participants tab, they're only filterable on the Studies list itself.

### Adding an Attribute as a Column

1. Click **Add column** (the "+" button at the right edge of the table).
2. Search for the attribute, or scroll to find it in the list.
3. Check the box next to it.
4. Click **Save**.

The attribute now shows as its own column, labeled with its name.

## Using Attributes for Segmentation

Candidate attributes are what segments and Candidates-page filters are built on. A segment is a saved, reusable filter, build it once from your attributes, then apply it whenever you need that group of candidates again.

### Creating a Segment

You can build one two ways:

**From the Candidates list:**

1. Apply the filters you want using **Add filter**, this can include any custom attribute.
2. Click **Save segment** in the filter bar.
3. Name the segment and click **Create**.

**From Candidate segments directly:**

1. Go to **Candidate segments**.
2. Click **Create a new segment**.
3. Name the segment.
4. Under **Criteria**, click **Filter** to add a field, any custom attribute, a core field, or even another saved segment.
5. Click the filter chip to choose an operator (for example, "is equal to," "contains," or "includes any of" for Multiple values attributes) and enter a value.
6. Add more filters as needed, and use the **All/Any** toggle to control whether a candidate must match every filter or just one.
7. Click **Create** to save.

> **Note:** Segments are account-wide, there's no way to scope one to a specific team. If you're working inside a team-restricted candidates view, segment controls won't appear at all.

### Editing or Deleting a Segment

From **Candidate segments**, use the pencil icon to edit or the trash icon to delete. Deleting a segment doesn't delete any candidate records — only the saved filter set. If you delete a **candidate attribute** that a segment filters on, that criterion is automatically removed from the segment, the segment itself stays, just without that filter.

### Using a Segment

* Apply it directly on the Candidates list by selecting it from **Add filter**.
* Reference it inside a study's own Participant Segments (Plan step) as one of your filter criteria, see [Candidate Segments](/support/support/candidates/participant-segments) for the full per-study targeting workflow.
* Add candidates to a published study directly from a segment via the study's **Add** menu → **Add from \[segment name]**.

## Best Practices

**Decide the type before you create it.** Since type and key are locked in after creation, take a moment to plan rather than needing to recreate the attribute later.

**Use candidate attributes for anything per-participant.** Study attributes are for organizing the Studies list only, they'll never appear in a study's Participants view.

**Coordinate naming across your account.** Since attribute names are unique account-wide, check with other teams before creating one to avoid a naming collision.

**Don't rely on "Unique" to prevent duplicates today.** It's a beta option, and uniqueness isn't currently enforced, treat it as a label for now, not a guarantee.

***

**Still need help?** Contact us at [support@greatquestion.co](mailto:support@greatquestion.co) — median response time is 19 minutes during [support hours](https://greatquestion.co/features/about-our-support-team).