Custom fields
Custom fields are your own visitor profile fields, such as "Skin type", "Company size" or "Preferred store", added on top of the default visitor fields. You collect their values with widget forms and surveys, from your own code or with parsers, and then use them to target visitors with the Visitor fields filter, show them with dynamic text, and send them to your integrations.
Available on: all platforms.
How it works
- You create the field in Settings → Custom fields, with a name and a type. Personizely gives it a numeric ID.
- Visitors get values when they submit a form or survey that uses the field, when your code calls ply.identifyVisitor with customFieldValues, or when a parser writes to it.
- The value is saved to the visitor's profile and kept across visits. A new value replaces the old one.
- You use it in targets, dynamic text, the contacts list and exports, webhooks and email integrations.
Create a custom field
- Go to Settings → Custom fields and click Add a custom field.
- Enter a Name, for example "Interest".
- Choose a Type. It can't be changed after you save.
- For select, radio and multiple, add the Choices.
- Save. The field's Id appears in the list.
Option | What it does | Values / default |
|---|---|---|
Name | How the field appears in forms, filters, contacts and exports | Text |
Type | The kind of value the field holds. Fixed once saved | See Field types |
Choices | The options visitors pick from | For select, radio and multiple. Editable later |
To remove a field, Archive it. Archived fields disappear from the list and from the Visitor fields filter menu. Values already collected stay on visitor profiles.
Field types
Type | Holds | Visitor fields filter operators |
|---|---|---|
text | Short text | is, is not, contains, does not contain, is empty, is not empty |
textarea | Longer text | Same as text |
An email address | Same as text | |
number | A number | is, is not, is higher than, is lower than |
checkbox | Checked or not (true/false) | is checked, is not checked |
select | One choice from a dropdown | is, is not, is empty, is not empty |
radio | One choice from radio buttons | Same as select |
multiple | Several choices (checkbox group) | includes, does not include, is empty, is not empty |
date | A date | is on, is not on, is before, is after, was yesterday, is today, is tomorrow, is this week, last week, is next week, is this month, last month, is next month |
For multiple, "includes" with several values selected matches only visitors who chose all of them; "does not include" matches visitors who chose none of them.
Using the field ID
The ID connects the field to code and dynamic text. It's the number in the Id column.
Where | Syntax |
|---|---|
ply.identifyVisitor | ply.identifyVisitor({ customFieldValues: { '42': 'wholesale' } }) |
Dynamic text | {visitor.customField[42]}, with a fallback: {visitor.customField[42] or 'our range'} |
Parsers | Choose the field by name in Field; the ID is used behind the scenes |
Values sent with identifyVisitor are merged with the visitor's existing custom field values, so sending one field doesn't clear the others.
Collecting values
- Your code. Call ply.identifyVisitor with customFieldValues. Use the same format as the type: a number for number fields, true or false for checkboxes, one of the choices for select and radio, an array of choices for multiple, and YYYY-MM-DD for dates.
- Parsers. A parser with destination Visitor can fill a custom field from a JavaScript variable, cookie, local storage, URL parameter or page element on every page load.
Behavior details and limitations
- Values belong to identified profiles. A value saved for an anonymous visitor stays with that browser's profile and moves to the existing profile if the visitor is later identified by email or phone.
- The type can't be changed. To change it, archive the field and create a new one. Values in the old field don't move.
- Changing choices doesn't change saved values. If you rename a choice, visitors who picked the old name keep it, and filters on the new name don't match them.
- Matching is exact and case-sensitive for text, select and radio values.
- Archiving hides, it doesn't delete. Targets that already use an archived field keep working.
- Empty values. Visitors who never got a value match is empty and is not checked, and {visitor.customField[ID]} renders its fallback.
Examples
- Quiz-based personalization: a survey widget saves "Skin type" (radio: Dry, Oily, Combination). A personalization shows matching product recommendations to visitors with "Skin type is Oily".
- Wholesale pricing banner: your login code sends customFieldValues: { '42': 'wholesale' }; a target with "Account type is wholesale" shows a bulk-order bar.
- Birthday offers: a date field "Birthday" collected by a form; a target "Birthday is this month" shows a birthday discount.
Troubleshooting
- Field doesn't appear in the filter menu → it's archived.
- Filter never matches → the value's capitalization or spelling differs from what you typed in the filter, or the visitor hasn't submitted it on this device and isn't identified.
- identifyVisitor doesn't save the value → the key isn't the field's numeric ID as a string, or the value doesn't fit the type: text for a number field, a string instead of true/false for a checkbox, a date that isn't YYYY-MM-DD, or a string instead of an array for multiple. A value that doesn't fit is rejected, together with the other fields in the same call.