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

# Products and fields

> Define the information an interest must carry for qualification and delivery.

# Products and fields

A product describes what a person is interested in. Its fields define the information Airlead stores on each interest for that product.

## Three kinds of fields

Airlead separates:

| Field type         | Stores                                  | Examples                            |
| ------------------ | --------------------------------------- | ----------------------------------- |
| **Person fields**  | Identity, contact, address, and consent | Email, phone, postal code           |
| **Product fields** | Answers that qualify one interest       | Property type, roof type, timeline  |
| **Capture fields** | Attribution and acquisition context     | Partner, campaign, source reference |

Do not store campaign metadata as a product answer or repeat person contact data in every interest unless an integration contract explicitly requires it.

## Why products come first

Sources, interests, buyer criteria, and field mappings all depend on the product definition.

Example fields for a solar product might include:

* property type
* owner status
* postal code
* roof type
* desired installation date

The person record still holds contact and identity data. Product-specific answers belong to the interest.

## Create or review a product

1. Open **Settings → Products**.
2. Create a product or select an existing one.
3. Add the fields needed to qualify and distribute its interests.
4. Mark a field as required only when every valid source can provide it.
5. Define options consistently for select fields.

## Choose stable field keys

Each field has a human-readable label and a technical key. Integrations and buyer criteria may depend on the key.

Before going live:

* use clear, stable keys
* avoid partner-specific names for shared concepts
* agree on units and allowed values
* document whether empty values are accepted
* test source mappings and buyer criteria together

Changing a key after go-live can break mappings or make existing criteria evaluate different data.

## Product fields and buyer criteria

Product fields describe the interest. Buyer criteria describe which values a buyer accepts.

For example:

```text theme={null}
Interest: postal_code = 40210
Buyer criterion: postal_code is in Düsseldorf delivery area
Result: buyer may be eligible
```

Eligibility can still be blocked by other settings such as capacity, pool access, activation, or delivery limits.

## Common questions

### Should contact fields be product fields?

Usually no. Name, email, phone, address, and consent belong to the person or capture data. Use product fields for qualification information specific to the request.

### Can two products use similar fields?

Yes, but each product owns its definitions. Keep keys and value formats consistent when partners send the same concept for multiple products.

### What happens to existing interests when a field changes?

Existing values remain tied to their stored definitions. Re-test mappings and buyer criteria before relying on changed definitions for live delivery.

Next: [Persons and interests](/guides/records/persons-interests) · [Understand sources](/guides/channels-delivery/sources) · [Buyers, pools, and criteria](/guides/channels-delivery/buyers-pools-criteria)