Subscriber List Definition
-
To access the definition wizard for a subscriber list, open the node of the parent dataset of the desired list in the
Subscriber Datasets
subtree, to show its subnodes.
- For a standard dataset (in subscriber area mode), proceed to open the Lists subnode, to show the subtree with all the lists in the dataset. Select the desired subscriber list node in this subtree.
- For a "single list mode" dataset, there is no such "Lists" subnode. Simply select the node for the single list from the subnodes of the dataset node.
- To create a new subscriber list, select the desired parent dataset in the Subscriber Datasets subtree and select New -> Subscriber List from the menu (or go via the right-click menu of the dataset node in the explorer tree).
- To convert an existing Classic LISTSERV list into an advanced subscriber list in the LISTSERV Maestro Subscriber Warehouse or to create a clone (copy) of an existing Classic LISTSERV list as a new advanced subscriber list in LISTSERV Maestro, select the desired parent dataset in the Subscriber Datasets subtree and select New -> Convert or Clone Classic LISTSERV List from the menu (or go via the right-click menu of the dataset node in the explorer tree).
The Subscriber List wizard lets you define the settings of a subscriber list or edit an existing list.
Note: A subscriber list is only fully editable while it is "empty", meaning that there are no subscribers on the list. For a non-empty list, only certain settings are editable.
The wizard has eight pages:
General, Profile Fields, Profile Field Details, List Type, List Options, Posting Restrictions, Topics, and Summary
The top row of the wizard displays links to these pages. The page that is currently open is marked with a highlighted background color. 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.
The LISTSERV Maestro admin may configure a user account or group so that it is only allowed to create standard announcement subscriber lists, but not advanced subscriber lists. If this is the case, then the wizard has only four pages and the "List Type", "List Options", "Posting Restrictions" and "Topics" pages are not shown.
Profile Fields Page: Subscriber List Field Settings
Each profile field is displayed as a row of Profile Field Settings.
A subscriber list always shares the profile fields that are already defined in the dataset that the subscriber list belongs to. These shared profile fields are not editable in the list wizard, but they are displayed on this screen as read-only in an italic font. The subscriber list can optionally add its own profile fields to the ones already inherited from the dataset.
Profile Field Settings
Each profile field in a dataset 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 choosen for the field.
- Display Name: This is the display name (the label) of the
profile field as it will be seen by the subscriber. It can be any non-empty text string.
There cannot be two fields in the dataset or list with the same display name.
- Data Type: The data type can be any of the following:
- Text: This profile field contains text strings.
Any text with a maximum length of 100
characters is valid (unless specific input field validation is specified). For
the subscriber, the profile field will be 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 profile field contains numbers. Any
number in the range of -9223372036854775808 to 9223372036854775807 is valid
(unless specific input field validation is specified). For the subscriber, the
profile field will be rendered as a text input field, although usually shorter
than the input field for the Text type.
- Boolean: This profile field contains a Boolean
flag that can be "true" or "false". The value actually
stored for the field will be the letter "T" for "true" and
"F" for "false". For the subscriber, the profile field will
be rendered as a checkbox, where a checked box means "true".
- Date: This profile field contains text strings that
are formatted in date format (with year, month and day values, according to
the specified format). For the subscriber, the profile field will be rendered as
a text input field, with validation to make sure that the input conforms to the date format.
- Single Select: This profile field contains 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). For the subscriber, the
profile field will be rendered as a drop-down menu or as a grid of
option buttons (radio buttons).
- Multiple Select: This profile field contains 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). For the subscriber,
the profile field will be rendered as a multiple value selection list or as a
grid of checkboxes.
- Derived: This profile field is a derived field.
Usually a derived profile field is derived from one or several other profile
fields in the same dataset or list (the source fields). This is
defined by a special derivation rule. The value of the derived field will
then automatically be 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.
- Tracking Permission: This is a special profile
field type that is only available in a subscriber dataset, not in a list. Also, each
dataset 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 "Boolean" (see above), but with the additional semantics that the field is meant for querying from the subscriber the permission for personal tracking. If a subscriber checks the checkbox that corresponds with this field, then he gives his permission to be included in personal tracking. If he unchecks the checkbox, then he revokes this permission.
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: If the subscriber changelog is activated, then any changes to this profile field will be logged. That way, you can later reconstruct if and when a subscriber gave or revoked his permission for personal tracking.
- Text Only: This is a special profile
field type that is only available in a subscriber dataset, not in a list. Also, each
dataset 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 "Boolean" (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 he specifies that he prefers text emails.
This has the following effect: If a mail job is targeted to a subscriber dataset that contains such a profile field (or to a list in such a dataset), 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 will automatically be set up 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.
- Birthday: This profile field is similar to a "Date" field (see above),
but is meant specific for birthday dates. Just like a "Date" field, the field will contain 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 will have age specific filtering options,
in addition to the standard from/to filtering options for a normal date field.
- Text: This profile field contains text strings.
Any text with a maximum length of 100
characters is valid (unless specific input field validation is specified). For
the subscriber, the profile field will be rendered as a text input field.
- 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 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).
- 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.
To add a new field to the list, click on the Add Field link. This will create 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 row in the display state has two associated links, Edit (sets the row into the edit state) and Remove (deletes the row after confirmation). Any row in the edit state appears with the corresponding edit controls so that it can be edited. It also has four associated links, Reset (forgets the changes made to the row and resets all row values to their state when the edit mode was last entered), Up (moves the row up in the ordering), Down (moves the row down in the ordering), and Remove (deletes the row, after confirmation).
For a dataset that already contains subscribers or lists, or for a list that already contains subscribers, the settings which can be edited on this page are limited:
Such a non-empty dataset or list knows two change modes, Normal and Advanced. If the wizard of a non-empty dataset or list is entered, it is initially always in Normal change mode and the Enable advanced changes link must be clicked to set it into the Advanced change mode.
Depending on the change mode, for a non-empty dataset or list the page is limited to the following changes:
- Normal Change Mode: Only the display names of the fields may be changed (click on a name to change it). No new fields can be added, no fields can be removed, and the ordering of the fields cannot be changed.
- Advanced Change Mode: Names and display names of the fields both may be changed, but data types and input types cannot be changed (the data type and input type of a field in a non-empty dataset or list can never be changed - to be able to change these types, the dataset or list needs to be empty). New fields can be added, existing fields can be removed, and the ordering of the fields can be changed.
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 dataset or list, even if there are already subscribers in the dataset or 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 subscriber dataset or 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 a mail 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 mail 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.