List Group Definition

The list group wizard lets you edit the settings of an existing list group.

Note: A list group is only fully editable while it is "empty", meaning that there are no subscribers or any lists in the group. For a non-empty group, only certain settings are editable.

The wizard has four pages: General, Profile Fields, Profile Field Details, and Summary.

The top row of the wizard displays links to these four pages. The page that is currently open is highlighted. Depending on the choices made on some of the wizard pages, other pages may become disabled or may be shown in different versions. If a wizard page is disabled, then it means that this page is not necessary with the current choices and can safely be ignored.

Profile Fields Page: Basic List Group Field Settings

This screen defines the profile fields of the list group. A field that is defined on the list group level is shared among all subscriber lists in the group.

Each shared profile field is displayed as a row of Profile Field Settings.

In a list group, there is always at least one shared profile field, which is the email address field. This field is always the first field in the list and always has the Text type. It is always Mandatory.

Profile Field Settings

To add a new field to the list group or subscriber list, click on the New Shared Field or New List Field link, respectively. This creates a new empty field row that can be filled out.

Profile field rows are displayed in the edit state or in the display state. Any profile field in the display state has two associated icons: sets the field into the edit state and deletes the field after confirmation.

Any profile field in the edit state appears with the corresponding edit controls so that it can be edited. It also has icons to change the field order: moves the field up in the ordering, moves the field down in the ordering.

Instead of the up or down arrows, you may also see special double arrows, that allow you to move a profile field from a list group "down" to the lists or from a list "up" to the list group. See below for details.

Each profile field in a list group or subscriber list is defined with the following settings:

• Name: The database name of the field. This is also used as the merge name for the field. It must only contain letters, digits, and the underscore (_). In addition, the first character must be a letter. There cannot be two fields in the dataset or list with the same name. In some instances, selected names may be reserved as special database names. In this case, a different name must be chosen for the field.

• Data Type: The data type can be any of the following:

  • Text: This type is used for text strings. Any text with a maximum length of 100 characters is valid (unless specific input field validation is specified). The profile field is rendered as a text input field.
    Note: For some encodings, like UTF-8 or asian language encodings, the maximum character length may even be less than 100, depending on the specified value.

  • Number: This type is used for numbers. Any number in the range of -9223372036854775808 to 9223372036854775807 is valid (unless specific input field validation is specified). The profile field is rendered as a text input field.

  • True/False: This type is a flag that can be "true" or "false". The value actually stored for the field is the letter "T" for "true" and "F" for "false". By default, the profile field is rendered as a checkbox, where a checked box means "true".

  • Date: This type is used for text that is formatted in date format (with year, month and day values, according to the specified format). The profile field is rendered as a text input field, with validation to make sure that the input conforms to the date format.

  • Single Select: This type is used for a single selected value from a list of predefined values in a lookup table (the lookup table to be used is defined in a later step). The profile field is rendered as a drop-down menu or as a grid of option buttons (radio buttons).

  • Multiple Select: type is used for one or several selected values from a list of predefined values in a lookup table (the lookup table to be used is defined in a later step). The profile field is rendered as a multiple value selection list or as a grid of checkboxes.

  • Derived: type is used for a derived value. Usually, a derived profile field is derived from one or several other profile fields in the same list group or list (the source fields). This is defined by a special derivation rule. The value of the derived field is automatically calculated whenever the values of the source fields are changed. See below for more information about derived fields. Note: A derived field can only be a "Read Only" or "Hidden" field (see below), i.e. its value can not be entered directly.

  • Birthday: This type is similar to the "Date" type (see above), but is meant specific for birthday dates. Just like a "Date" field, the field contains a formatted date. But because of the additional semantic meaning of a birthday date, if this field is used for recipients filtering (for a mail job), the user has age-specific filtering options in addition to the standard from/to filtering options for a normal date field.

  • Gender: This type is similar to the "Single Select" type (see above), but is automatically connected to a pre-defined lookup table with a list of available genders. The lookup table is created automatically (if it does not already exist). You can find it in the LISTSERV Maestro explorer among your own lookup tables. It is initially filled only with the entries "Female" and "Male", which you can edit and/or add additional gender choices.

  • Country: This type is similar to the "Single Select" type (see above), but is automatically connected to a pre-defined lookup table with a list of available countries. The lookup table is created automatically (if it does not already exist). You can find it in the Maestro explorer among your own lookup tables. It is initially filled with a list of countries.

  • US State: This type is similar to the "Single Select" type (see above), but is automatically connected to a pre-defined lookup table with a list of available US states. The lookup table is created automatically (if it does not already exist). You can find it in the Maestro explorer among your own lookup tables. It is initially filled with a list of all US states.

  • Email Domain: This is a special type that is only available in a list group or standalone list. Also, each list group can only have one single field of this type (or none at all). This type is similar to the "Derived" type (see above), but is pre-configured with a derivation formula that extracts the domain part from the subscriber's email address (i.e., the part after the "@" character), converted into uppercase.

  • Only Text Email: This is a special type that is only available in a list group or standalone list. Also, each list group can only have one single field of this type (or none at all).

    A field of this type behaves just like a field of type "True/False" (see above), but with the additional semantics that the field is meant for querying from the subscriber if the subscriber prefers to receive emails in plain text format and not in the richer HTML format. If a subscriber checks the checkbox that corresponds with this field, then this means that text emails are preferred over HTML.

    This has the following effect: If a mail job is targeted to a subscriber list that contains such a profile field (either directly by being a standalone list or indirectly by inheriting it from the list group), and if the message of this job is configured to be a HTML email with plain text alternative, then the "conditional content" definition of the message is set up automatically in such a way that the full HTML email is only sent to subscribers who have not checked this profile field, and all subscribers with the field checked receive only a plain text email with the alternative text as the content.

  • Consent to Personal Tracking: This is a special type that is only available in a list group or a standalone list. Also, each list group can only have one single field of this type (or none at all).

    A field of this type behaves just like a field of type "True/False" (see above), but with the additional semantics that the field is meant for querying the subscriber's consent to personal tracking. If a subscriber checks the checkbox that corresponds to this field, then this is considered as consent to be included in personal tracking. Un-checking the checkbox revokes this consent.

    This has then the following effect: If a profile field of this type is added to a dataset, then for any mail jobs that are sent to this dataset or a list in this dataset, the normal "Personal Tracking" is no longer available as a tracking type. Instead, it is replaced with the new "Permission-Based Personal Tracking" tracking type. See there for details. The other tracking types ("Anonymous", "Unique" and "Blind") are not affected by this.

    Note: Any changes to this profile field are logged. That way, you can later reconstruct if and when a subscriber gave or revoked the consent for personal tracking.

• Input Type: The input type can be any of the following:

  • Mandatory (non-boolean fields only): A field of this type behaves the same both for the subscriber and for the data administrator. It is visible as an input control and the user must provide a value or selection.

  • Visible (boolean fields only): Same as mandatory.

  • Optional (non-boolean fields only): A field of this type behaves the same both for the subscriber and for the data administrator. It is visible as an input control, but the user does not have to provide a value. Instead, they can leave the field empty or make no selection.

  • Read-Only (text, number, date and single-select fields only): A field of this type is displayed differently for subscribers and the data administrator. For a subscriber, it is displayed as a read-only text (i.e. the subscriber can see the value but cannot change it or input a new value). For the data administrator, it behaves exactly as if it were of the type optional.

  • Hidden (all field types): A field of this type is displayed differently for subscribers and the data administrator. For a subscriber it is not displayed at all (i.e. the subscribers do not know that the field even exists nor do they see its value). For the data administrator, it behaves exactly as if it were of the type optional (for non-boolean fields) or visible (for boolean fields).

Moving Profile Fields Between List Group and List

While you are editing the shared profile fields of a list group that already contains one or more lists, you have the option to move profile fields down from the group to the lists. To do so, first move the profile field down (using the icon while the field is in edit mode) until it is the very last field. The icon now shows a double down-arrow . If you click this double arrow, you tell Maestro that you want to convert this profile field from a shared profile field in the list group to an individual profile field in one or more of your lists. You can select which lists you want the field to be moved to. You can move it to only one list, or even to several lists. The profile values for the existing subscribers will be retained. The actual move will only be applied when you finish the list group wizard.

While you are editing the profile fields of a subscriber list that belongs to a list group, you have the option to move profile up from the list to the group and thus convert them into shared profile fields. To do so, first move the profile field up (using the icon while the field is in edit mode) until it is the very first field. The icon now shows a double up-arrow . If you click this double arrow, you tell Maestro that you want to convert this profile field from an individual list profile field into a shared profile field in the list group. The profile values for the existing subscribers will be retained. The actual move will only be applied when you finish the list wizard.

Note, that fields with certain types can only exist in list groups or in individual lists and can therefore not be moved in this fashion.

When to Use Derived Fields and When Not

Derived fields require additional storage space in the system database and additional processing power by the server when their values are calculated. Therefore, a derived field should only be used if there is actually a need for it. Some situations where a derived field seems like a solution can actually be solved without a derived field, in which case this other solution should usually be preferred.

You should also be aware that you can always add an additional derived field to an already existing subscriber list, even if there are already subscribers on the list. Therefore, you should usually refrain from creating a certain derived field if you have any doubts about if you will later actually be using this field. Instead, you should only add it once it turns out that you actually require it.

A derived field is the correct solution for the following situations:

• Include Field in Subscriber Profile: The value of the derived field is supposed to appear as a visible value in the subscriber profile, so that the subscriber can view this value on the corresponding profile page in the subscriber area.

  For example, a derived field that displays the service phone number that matches the country that a subscriber has selected. For this, a "read-only" derived field is the correct choice (in contrast to a "hidden" derived field, which a subscriber does not see in the profile).

• Include Field in Tracking Reports: The derived field is supposed to be available in a Recipient Details tracking report (for a job with either personal or anonymous tracking).

  For example, a derived field that extracts the domain name from the subscriber's email address would allow a tracking report that can show you how many recipients clicked on a certain link (or opened the email, etc.), broken down by recipient domains. For this, usually a hidden derived field is the correct choice (although you can also use a read-only field, if you also want to display the value in the subscriber profile, see above).

• Include Field in Demographic Breakdown Reports: The derived field is supposed to be available in a demographic breakdown report of a list group or subscriber list.

  For example, a derived field that extracts the domain name from the subscriber's email address would allow a demographic breakdown report that can show you, how many subscribers you have per subscriber domain. For this, usually a hidden derived field is the correct choice (although you can also use a read-only field, if you also want to display the value in the subscriber profile, see above).

• Include Field on Browse/Edit Page: The derived field is supposed to be included in the subscriber list on the browse/edit page, so that you can see the various values there, and also filter the list over these values.

  For example, a derived field that determines the zodiac sign depending on the value in another profile field that contains the subscriber's date of birth. For this, either a read-only or hidden derived field is the correct choice (depending on if you want this value to also be displayed in the subscriber profile or not, see above).

In contrast, a derived field is usually not the correct solution for the following situations:

• Mail Merging: A certain derived value is supposed to be included as a merge value in the body of an email message. For this, you should not use a derived field (unless you also need the derived field for other situations anyway, see above). Instead, simply include a *Calc system drop-in in your email message, with the same calculation formula that you would also have used for the derived field.

• Target Group Condition Tree: A certain derived value is supposed to be used to filter the recipients in the condition tree of a target group. For this, you should not use a derived field (unless you also need the derived field for other situations anyway, see above). Instead, simply use the same calculation formula directly in the condition tree that you would also have used for the derived field.