LISTSERV Maestro 8.1-4 Help

Forward >> << Back Table Of Contents

Target Group Definition: Based on Subscriber List

This Target Group Definition wizard lets you define a target group of the type Subscriber List that can be used in the recipients wizard to define the recipients of a job.

The wizard for a target group of the type "Subscriber List" has multiple pages:
General, Source, Source Details, Parameters, Input Layout, Input Preview, and Summary.

The top row of the wizard displays links to each of 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.


Source Details Page: Define Subscriber Subset

A filtering condition is entirely optional. If no condition is supplied, then the target group always addresses all current subscribers of the dataset or list.

The following sections describe the available variants of filtering conditions.

Post as Standard Message: Only for advanced subscriber lists

This special subscriber subset variant is only available if the selected list is an advanced subscriber list. Important: Choosing this variant not only means that LISTSERV Maestro sends to all subscribers of the selected list, but that a different method of delivery is used. Only use this option if you know what you are doing and if you explicitly wish to employ LISTSERV's web archival and indexing capabilities.

Viewing Subscriber Data And Setting Filters

The majority of filtering conditions can be written as "Send to all subscribers who have a certain value in FIELD1 and a certain other value in FIELD2", e.g. "Send to all male subscribers in the eastern sales region". For such cases, the filtering condition of the target group can be defined visually in a manner similar to how a mail job owner would define the recipients:

Selected Segments: Define if the subscriber subset shall be constrained via a subscriber segment selection. Clicking Select Segments opens a dialog listing all available segments of the selected subscriber dataset or list. Pick any number of segments from the list and decide if you wish LISTSERV Maestro to consider subscribers in any, all or none of the segments. (Use the usual keyboard commands to perform multiple-entry selection.) Click the OK button to apply your segment choice. (See here for an explanation of what the choices "any", "all" and "none" mean for a segment condition.)

Additional Search: Clicking the Edit Search Condition link opens a special variant of the list subscribers pane. See the List Subscribers help for details on how to define a suitable filter and how to apply it to the target group.

Custom Condition Nodes on Fields

This advanced method of supplying the filtering condition gives you full control on the actual logic of the condition, including the ability to freely define combination logic using the known boolean operators AND, OR and NOT, each operating on a list of nested conditions which you can define freely using tree operations, all detailed below.

As an aid for constructing the filtering condition, all profile fields available in the dataset or subscriber list are displayed in the upper part of the screen. Each profile field is listed with its name and data type. Any mandatory fields are rendered in bold. Use this list as a reference when deciding on which fields to define conditions.

The condition itself is based on Boolean logic. When the condition is applied to a certain subscriber, the result of the condition is always either "true", in which case the subscriber becomes a recipient of the job in question or "false", in which case the subscriber is not a recipient of the job.

The condition is defined visually in the form of a "condition tree", which is displayed in the lower part of the screen.

The condition tree consists of hierarchically ordered nodes of various types. Each of the nodes has, for a given subscriber, a certain Boolean "true" or "false" state. For nodes that have sub nodes, the Boolean state of the node itself is derived by combining the Boolean states of all sub nodes in a certain manner (how they are combined depends on the type of the node itself). The root-node of the whole tree is equivalent to the whole condition. The Boolean result of the condition is determined by looking at the Boolean state of the root node, which in turn derives its state by looking at its sub nodes and combining them accordingly, and so on.

Nodes in the condition tree can be of one of two main types:

The following sections describe different aspects of editing the condition tree.

Editing the Condition Tree

This section describes general concepts about how the condition tree is edited.

The area in which the condition tree is edited is separated into a left and a right section. The tree with all its nodes is shown in the left, while a description of the currently selected node, together with an Actions on Selected Node link, is displayed in the right. Below the two sections, a textual representation of the condition is displayed at all times. It mirrors the condition that is currently defined in a textual form, using pseudo syntax with commonly used elements. With this representation, the condition defined by the tree can be verified as the intended condition.

The tree itself always consists of various elements. The top element, the root, is labeled with "Subscribers of XYZ" (for a subscriber list or dataset), where "XYZ" is the name of the dataset or list the target group is based on.
For a target group based on a subscriber list, the root always contains one single child node that is always a combination operator node. This is the "top level operator" for target groups based on a subscriber list.

For a target group based on a dataset, the root always contains a single AND-combination operator node that can not be changed or deleted. This node in turn always contains two sub nodes (which are combined via "AND"): A special ActivelySubscribedToAnyList node (which can not be deleted or changed) and another combination operator node. This second combination operator node is the "top level operator" for target groups based on a dataset. The top level operator described above can not be deleted, but its type can be changed (see Combination Operator Nodes for details about changing the type of a combination operator node).

Initially, the top level operator is empty, meaning that it does not contain any sub nodes. For a target group based on a subscriber list, this is equivalent to an empty condition that is "true" for all subscribers of the list.

For a target group that is based on a dataset, things are a bit more complex: The top level operator is always AND-combined with a special "ActivelySubscribedToAnyList" node. The logic of this node is as follows: It is "true" for all dataset subscribers which currently are also subscribed to at least one list in the dataset, and this subscription must be an "active" subscription (i.e. not "suspended"). Therefore, whatever condition is defined below the top level operator, is always AND-combined with this special node, which means that the whole condition tree is true only for subscribers which are currently "actively" subscribed to at least one list in the dataset and which fulfill the condition below the top level operator. While the top level operator is empty, this is equivalent to a condition that is "true" for all subscribers of the dataset which are currently "actively" subscribed to any list.

If a node in the tree has sub nodes, then the node itself can be closed (hiding the sub nodes) or open (displaying the sub nodes). In this case, the node is shown with a little icon (if the node is closed) or icon (if the node is open). Click on the icon to close or respectively open a node (double-clicking the node name does not work).

If a node is selected by clicking on it, a detailed description of the node is displayed to the right. In addition, an Actions on Selected Node link is displayed. Clicking on the link opens a popup menu containing all currently possible actions that can be executed on the selected node. Which actions these are depends on the node type and possibly its state, and are described in detail below:

Root Node Actions

For the root node, only one action is available:

Combination Node Actions

For combination type nodes, the following actions may be available (depending on the current state):

Condition Node Actions

For condition type nodes (both for normal and job-based conditions), the following actions may be available (depending on the current state):

Combination Operator Nodes

Combination operator nodes derive their Boolean state by examining the Boolean state of all sub nodes and combining these states using a Boolean operator depending on the node's type. The following operator node types are available:

The type of a combination operator node can be changed at at any time using the Change Operator Type command from the Actions on Selected Node menu.

When doing a copy & paste of a combination node, the node and its whole subtree (including all sub nodes and their sub nodes) is copied. Similarly, when doing a cut & paste, the node and its whole subtree is removed from the original location and added at the paste location.

Note: Certain variants of nesting operator nodes are superfluous and is therefore removed ("pruned") if the Remove Unnecessary Nodes command from the Actions menu is selected on the root node.

Normal Condition Nodes

Normal condition nodes derive their Boolean state by examining a condition that is defined explicitly for the given node. The condition is defined in a dialog box when the node is first created and can later be edited at any time in the same dialog box by selecting the Edit command from the node's Actions on Selected Node menu.
The condition node is represented in the tree with the symbol and a textual representation which displays the condition in short form.

The Edit Condition dialog box shows several drop-down lists and possibly edit fields or selection boxes, which allow the defining of the condition for the node. In the dialog box, the selection controls are organized in a hierarchical order from top to bottom, where choices in the upper controls directly influence the available choices in the lower controls. As a result, define a condition in a top-to-bottom manner, first making selections in the upper controls, then proceeding to the next control, and so on, until the bottom of the dialog box has been reached and the whole condition has been filled out.

Generally, each condition consists of three parts: a left operand, an operator and a right operand. The operator is always a Boolean operator, meaning that it compares the left and right operands in a certain fashion and the result is a Boolean value of "true" or "false". This operator result is then used as the Boolean state of the condition node.

These three parts are represented by (usually) five controls, situated above each other. The first two controls define the left operand, the third control defines the operator and the last two controls define the right operand.

Which operators are available in the third control, and which kinds of right operands can be defined using the last two controls depends on the selections in the first two controls (what left operand is currently selected).

Below follows a detailed description of the possible choices for:

Left Operand

For the left operand, the following choices are available:

Operator

The available operators are shown in the third control, which is always a drop-down menu. The operators that are available depends on the type of the left operand, for example there are different operators for numbers than for text strings.

Right Operand

For the right operand, the available choices depend on which left operand has been selected. The following choices may be available:

Formulas in Conditions

Formulas can be used in conditions to calculate the left and/or right operand value at "run time" (the moment the condition is actually applied to a given subscriber) to determine if the subscriber shall become one of the recipients of a job or not.

Such a formula is typed directly into the multi-line edit field provided by the condition definition dialog box (any line breaks in the formula code do not have any effect on the result of the formula but can instead be freely used to enhance readability).

The syntax follows general mathematical formula rules, with operators like "+" and "-", parenthesis nesting and so on. There are also a number of predefined "functions" that can be used in formulas.

Examples of formulas:

15 + 4
27 * Max(17, 4, 24/8) / (19 + 22)
&NAME; + "@lsoft.com"
(ToNum(&AGE;) - 2004) * 10
ToDate(CurrentTimeMillis, "MM/dd/yyyy HH:mm")

See here for a detailed description of formulas and functions.

Note: Formulas may contain parameter placeholders. Parameter placeholders allow you to define conditions with formulas, where one or several values in the formula are not already known at the time you write the formula (and condition), but are instead supplied later by the end user who uses this target group in the recipients wizard. (See here for details about how to include parameters in formulas and read the following subsection about condition parameters in general).

Parameters in Conditions

Parameters can be used in conditions as the right operand in situations where the value of the operand is not yet known at the time the condition is defined, or is not fixed by the condition definition. The value is supplied later by the end user when the target group is used in the recipients wizard.

This way, conditions can be created that are parameterized to allow for greater flexibility for the end user (see example below).

To define a right operand of this type, select the the TYPE_VALUE supplied for the parameter entry from the drop-down menu at the fourth position, where "TYPE_VALUE" is filled out according to the type of the left operand field selected. This, therefore, already defines the type of the parameter. The entry in the drop-down menu is one of the following:

When this selection has been made, the last control becomes an edit field where the name of the parameter to define is entered. Enter only the name, without any enclosing tags (this is different than when using a parameter in a formula, a SQL statement, or LISTSERV condition, where the parameter needs to be enclosed in tags to set if off from the rest of the formula/statement/condition).

Note: If the same parameter name is specified in different condition nodes, it is interpreted as one parameter that simply appears several times in the condition tree. All appearances will have the same content value and so must also all appear in the same type context (Number, Text, and so on). This means that if in one condition node the selection is the text supplied for the parameter, and the parameter name specified is mytext, and then if the same parameter name is specified again in a different condition node, then in that place the selection must also be the text supplied for the parameter (but not, for example, the numeric value supplied for the parameter).

Similarly, if a parameter is used with the same name in a formula (see above) somewhere else in the condition tree, then all these appearances, too, reference the same parameter. All of them are replaced with the same final content during usage in the recipients wizard and must therefore have the same type.

Example: Assume that the subscriber list has a field called AGE and a target group must be defined that selects all subscribers who are of a certain age or older; for example, test for the age of 21. Specify this as a condition node as follows:

the field AGE >= the number 21

However, what if for the next mailing a different age should be used, say "18" or "40"? A new target group could be created for that purpose, with a new condition. But this will soon become tedious, so instead, a parameter could be used for the age and leave it to the end user to supply the actual age to check for. The condition node would then look like this:

the field AGE >= the numeric value of the parameter age_param

Where "age_param" is the name given to this parameter. The resulting target group could then be used to select recipients of any age or older, just by supplying the desired threshold age in an edit field, as a value for the parameter "age_param".

Job-Based Condition Nodes

Job-based condition nodes derive their Boolean state by examining the delivery of an earlier mail job, the so called "source job", and optionally also the tracking events collected for that job.
The condition node is represented in the tree with the symbol and a textual representation that displays the condition in short form.

Which source job it is that shall be examined is specified by the end user who uses the target group in the recipients wizard. Here in the condition definition, it is simply enough to know that whatever source job is selected, is in fact a job that was in turn delivered to the same dataset or list as the one one that this target group is based on (or more precisely, the source job used a target group that was based on the same dataset or list as this target group).

The Edit Job-Based Condition dialog allows the defining of how the source job is examined. There are the following options:

Examining Tracking Events of the Source Job

If the first of the two choices above is selected (that is, to filter for all subscribers who were recipients of the source job) then the tracking events that were collected for the source job may also be optionally chosen to be examined, to further filter the recipients. (Note that if this option of examining the tracking events is used, additional issues need to be considered, see below).
To enable the option, check the With the following tracked behavior option and select one of the available behavior types from the drop-down menu:

If from the above behavior types one of the four that deal with click events is selected, the URLs to look at must be specified. This is done with the options below the drop-down menu, which only become visible if such a behavior type is chosen. In this case, the following choices are available:

If from the above behavior types one of the four that deal with action tracking events is selected, the tracked actions to look at must be specified. This is done with the options below the drop-down menu, which only become visible if such a behavior type is chosen. In this case, the following choices are available:

Additional Issues with Job-Based Conditions and Tracking Events

If the option of examining the tracking events of the source job is selected, (see above) the following additional issues must be considered.

With this option enabled, the choice for the "source job" becomes more limited. Normally, for job-based conditions, a possible source job is one that has been delivered to the same subscriber dataset or list as the one the target group is based on.
When using the examine tracking events option, the choice for the source job is narrowed to all the above jobs that also had personal tracking enabled at the time of delivery. Because only the information collected with personal tracking is sufficient for the job-based condition node to determine if the condition is "true" or "false".

© 2002-2017 L-Soft Sweden AB. All rights reserved.