Form: Input Field & Input Number Field element

The Input Field is the element that lets visitors type things — their email address, their name, their company, their date of birth. It's the single most-used Collect element in the tool, and it's the one that powers every Known Profile in your Audience: without at least one Input Field mapped to the Email or Mobile Attribute, a submission can't create a Known Profile.

The Input Number Field is a close variant — the same element, pre-configured to only accept numeric input. On mobile devices it triggers the numeric keypad automatically, which removes friction for any field where visitors are entering digits (phone numbers, postcodes, ages, quantities).

This article walks through both elements, what each option does, how the data lands on a Profile, and how to avoid the handful of common mistakes that catch people out.

Repeat for every piece of information you want to collect. Always include at least one Input Field mapped to the Email or Mobile Attribute, plus a Terms & Conditions or Consent element and a Submit button — otherwise the Form cannot collect consent or create a Known Profile. See Create New Form.

Both elements live in the Collect panel, side by side, and share the same option set (Label, Required, Map to Attribute, Style, alignment, margins and everything else).

The difference is simple:

Use Input Number Field whenever the expected answer is a number and a mobile-friendly keypad makes sense:

For everything else — including fields where a number could appear but text is expected (e.g. "address line 1" which might include a number and a street name) — stick with the regular Input Field.

On a regular Input Field, the placeholder text ("Write something...") is a powerful way to guide the visitor. You can type something like "Add your email address here" or "+46 70 123 4567" so the visitor knows exactly what format you expect.

The Input Number Field behaves differently. Because the field only accepts digits, text-based placeholder guidance doesn't work the same way — you can't use the placeholder to explain what to fill in with a sentence.

What this means in practice:

This is the single most common source of confusion with Input Number Field: visitors tap in, see a blank numeric field with no helpful placeholder, and aren't sure whether to include a country code, hyphens, or leading zeros. A strong label plus a one-line hint solves it.

Everything else in this article (options, labels, validation, mapping, styling) applies identically to both elements. Read on with that in mind.

The internal name that will name the Row or Column in the Structure panel to the left. Visitors never see this — it's just to help you find the field later.

The internal field name doesn't just appear in the editor's Structure panel — it also appears in the Form – Submit Event on every Profile who fills out the Form. The Event data shows each collected field as a label followed by an internal ID:

The second version is nearly unreadable — you can see the value, but you have no idea what field it came from. On a Form with a dozen fields, the Profile form submit events becomes a guessing game.

Keep Input as the input mode (default), or switch to Text area to insert a larger text field with several rows and support for line breaks.

Text area is useful for open-ended questions — feedback, suggestions, "what is your main concern" — where a single-line box would feel cramped.

Text area fields are different from single-line inputs because of the volume of text visitors can produce. A Profile Attribute is designed to hold structured, segmentable data — a name, a country, a number, a single choice. Storing a 500-word feedback paragraph there works technically, but it's the wrong tool for the job.

Think carefully before mapping a Text area to an Attribute. A few guidelines:

A useful mental test: if this field were in a spreadsheet, would I want it in its own column, or would it fit better as a free-text note attached to the row? Column → Attribute. Free-text note → Form response only.

Select the value type of the Input Field in the Validation dropdown. Your Form can verify that the visitor fills in your input field with the data of your choice — for example, using only numbers for a phone number field, a valid email format for an email field, or a valid date for a date field.

Validation protects your data quality. An email field without email validation will accept anything a visitor types — including typos that silently pollute your Audience with unreachable addresses.

Tick the Map to Attribute dropdown and select where to store the information. The value the visitor enters will be fed into their Profile as a value for the selected Attribute.

This is the single most important technical step when building any Collect element. A field not mapped to an Attribute collects data that lives only in the Form – Submit Event — it can't be used for segmentation or personalisation on the Profile itself.

The accepted date formats in the Input Field element correspond with Apsis One's supported data format. Regardless of the format your visitors use, Apsis One converts it to YYYY-MM-DD.

Important limitation: the Input Field element will not accept a date with a time zone.

Labels are the text that explains what information the visitor should fill out in the field. They matter for two reasons:

Place the label on top, under, to the right or left of the input field. Top placement is the most accessible and the most common pattern on modern web forms.

Labels also come with their own inline styling options:

Toggle Confirm field to create an additional input field where the visitor must enter their information a second time to make sure it's correct.

This is especially useful for confirming email addresses — keeping the quality of your Subscriptions high by catching typos before they become invalid addresses in your Audience.

Each field has its own label and settings for it.

Toggle Required field on if the field should be mandatory. If toggled on, visitors will not be able to submit the Form without filling this field out.

Remember: validation errors (the "missed field" and "wrong format" messages you configured in Forms: Settings) only trigger if the field is set to Required or if a Confirm field doesn't match the original.

How a response is stored in Audience depends on whether you mapped the field to an Attribute or to Form response only.

When the Input Field is mapped to an Attribute (for example, First Name), the value becomes part of the Profile — visible in the Profile view, usable in Segments, and available for personalisation in Emails, SMS and Marketing Automation.

If the Input Field is mapped to Form response only, the value is saved as Event data. You can find it in Profile view under Form & Page Interactions — click the Submit activity in the timeline.

This is useful when you want to analyse a response (for example, in Segments by Event Property) but don't need it stored permanently as an Attribute on the Profile.

A good acquisition Form typically has three Input Fields: email, first name, and one qualifier that helps with future nurturing. The qualifier might be role, industry, interest area, or company size — whatever lets you branch a welcome flow in Marketing Automation.

Resist the temptation to collect more than that at the acquisition stage. Progressive profiling (later Forms triggered by Marketing Automation) is where the rest of the data comes in.

A "keep your details fresh" Form should pre-select Attributes that genuinely need updating — name, company, country, maybe a preference. Use the Confirm field toggle on the email address field so Profiles catch typos when they change their email.

A campaign registration Form often needs a few more fields than a newsletter sign-up — perhaps job title, company, city for an event. Keep the fields focused on what the campaign actually needs to deliver. Use validation types (Email, Number, Date) so the data you collect is clean and usable.

For loyalty programmes, a deeper Form (distributed only to existing Profiles) can collect richer data — date of birth for birthday campaigns, preferred language, favourite product category. Use the Date of Birth pattern with Date validation and a YYYY-MM-DD placeholder.

Cause. The field is set to Form response only, not mapped to an Attribute. Data lives in the Form – Submit Event but doesn't populate the Profile.

Fix. Open the Form, click the field, and set Map to Attribute to the correct Attribute. Fixes only affect future submissions — existing submitters would need to resubmit or be enriched via API/CSV.

Cause. The Form doesn't contain an Input Field mapped to the Email or Mobile Attribute. A Profile becomes "Known" only when at least one of those identifiers is provided.

Fix. Add an Email (or Mobile) Input Field, map it correctly, and republish.

Cause. Validation isn't set to Email, so the field accepts anything.

Fix. Set Validation to Email on the relevant Input Field. Consider also turning on the Confirm field toggle so visitors have to type the address twice.

Cause. Dates are normalised to YYYY-MM-DD on save, but if visitors can type in any format without a hint, you'll see conversion surprises. Also note: dates with time zones aren't accepted.

Fix. Turn on Date validation and include a clear format hint under the label (e.g. "DD/MM/YYYY" or "YYYY-MM-DD" depending on your market).

Cause. Validation errors only trigger if the field is set to Required, or if a Confirm field doesn't match the original.

Fix. Toggle Required on. See Forms: Settings for styling the error messages themselves.

Cause. Input Number Field only accepts numeric characters. Content like phone numbers with spaces, brackets, or "+" prefixes won't be accepted.

Fix. If the field needs to accept formatted numbers (e.g. international phone numbers with "+" and spaces), use the regular Input Field with Phone number validation instead. Input Number Field is best suited to pure-digit inputs — postcodes, age, quantities, ratings.

Cause. The placeholder text that would normally guide them (e.g. "Add your email address here") doesn't work the same way on Input Number Field because the field only accepts digits.

Fix. Use a clear, explicit Label above the field (e.g. "Phone number — digits only, no spaces or + sign"), and add a Paragraph design element underneath with any formatting hint. See the Important to know section earlier in this article.

Cause. The Input Number Field is mapped to a text-type Attribute rather than a number-type Attribute. Text Attributes compare values alphabetically, so "Age greater than 9" would incorrectly match values like "10" as less than 9 (because "1" comes before "9" in string comparison).

Fix. Create a number-type Attribute for the data and re-map the field. Existing data may need to be migrated — talk to support if you have significant data in the wrong Attribute type.

For a wider set of Form issues, see Forms & Pages: Troubleshooting.