How To Store Addresses in LISTSERV Maestro (and use them as recipients of a message)
You can make the best use of LISTSERV Maestro's features, if you store your recipients' addresses and profiles (like names, hobbies, customer numbers, etc.) directly in LISTSERV Maestro itself.
The Subscriber Warehouse is the topmost organizational unit where the recipient email addresses are stored. It has no further specific features but simply acts as the repository for all subscriber datasets. There can be one or several datasets in the subscriber warehouse.
A Dataset is the main organizational unit for email addresses. Each address can be subscribed to an individual dataset only once, i.e. in each dataset, there are no email address duplicates, but two different datasets can very well contain subscriptions of the same and/or different email addresses. The dataset in turn contains one or more subscriber lists.
A Subscriber List is a sub-unit of its parent dataset. Each individual email address in the dataset can be subscribed to any of the lists, even to several lists at once or to none at all, but each email address can only be subscribed once to each list, i.e. there are no address duplicates in the individual lists.
If at this point you are asking yourself how you should employ this structure for your own lists, and how to decide which datasets and lists to create, and how to group lists into datasets, then please be patient. This will be explained in more detail a bit further below. For now, let us first continue with a description on how to actually create datasets and subscriber lists, and how to use them:
To create a new dataset, select New -> Subscriber Dataset from the menu. The definition of a new dataset (as well as editing the settings of an existing dataset) happens in the Dataset Definition wizard.
To create a new subscriber list in an existing dataset, select the desired parent dataset in the Explorer Tree, then select New -> Subscriber List from the menu. Similarly to datasets, the definition of a new subscriber list (as well as editing the settings of an existing list) happens in the Standard Subscriber List Definition wizard, respectively the Advanced Subscriber List Definition wizard.
Once your subscriber dataset (or list) is created, you can then populate it with subscribers. You can either add subscribers manually, one by one (menu Edit -> Add Subscriber). Or you can import subscribers from an external source (a spreadsheet file, text file, from a database or an LDAP directory) with the Subscribers Importer.
With your subscriber dataset and list populated, you can now browse through the list of Dataset Subscribers or List Subscribers, which also allows you to search/filter, edit, download or delete the existing subscribers. You can also save your search filters as predefined Subscriber List Segments.
The final step is to then use your subscribers as the recipients of a Mail Job. For this, you can either create a new mail job that is pre-populated with the desired recipients, or you can edit the recipients definition of an existing mail job, to target one of your subscriber lists or datasets:
-
To create a new mail job that is sent to all subscribers of a dataset, subscriber list or segment:
In the Datasets Tree, select the "All Dataset Subscribers" node of the desired dataset, or the "All List Subscribers" node of the desired list, or below one of these nodes, select the desired subscriber segment node. Then select Edit -> Create Mail Job Based On This from the menu.
-
To create a new mail job that is sent to only some subscribers of a dataset, subscriber list or segment:
In the Datasets Tree, select the "All Dataset Subscribers" node of the desired dataset, or the "All List Subscribers" node of the desired list, or below one of these nodes, select the desired subscriber segment node. Then use the search/filter options in the subscribers table that is shown in the right pane to search for exactly those subscribers that are supposed to be the recipients of the job. Then select Edit -> Subscribers Matched By Filter -> Create Mail Job Based On This from the menu.
-
To define the recipients of an existing mail job to be sent to all subscribers of a dataset, subscriber list or segment:
On the mail job's Workflow page, click the "Define Recipients" step and on the Options page of the recipients wizard, select the "Send to a List or Dataset in the Subscriber Warehouse" option. Then on the Source page, select the "All Dataset Subscribers" node of the desired dataset, or the "All List Subscribers" node of the desired list, or below one of these nodes, select the desired subscriber segment node. Then proceed with the recipients wizard.
-
To define the recipients of an existing mail job to be sent to only some subscribers of a dataset, subscriber list or segment:
On the mail job's Workflow page, click the "Define Recipients" step and on the Options page of the recipients wizard, select the "Send to a List or Dataset in the Subscriber Warehouse" option. Then on the Source page, select the "Advanced Recipient Selection" node of the desired subscriber dataset or list. Then on the Source Details page, select the "Recipients Selected by segment and Search" option and proceed to define your own search condition using the links below this option. Then proceed with the recipients wizard.
Note: When sending to a dataset or one of its subscriber segments, only those subscribers of a dataset that are also subscribers of at least one list will be the recipients of the job. It is not possible to send a mail job to subscribers that have unsubscribed from all lists.
How To Structure My Datasets and Subscriber Lists?
The structure of your subscriber warehouse depends on your needs, especially on how many subscriber lists you need, and if these lists are related to each other or not. Usually, you would put related lists into the same dataset, but create separate datasets for unrelated lists. The following illustrates this with a few examples:
-
If you require only one single list, then the setup is very simple: You create only one dataset in single list mode (this mode is the default for a new dataset) and in that dataset your one single list.
-
If you require several unrelated lists, then you create a separate dataset for each list, with each dataset in single list mode. For example for three unrelated lists, you create three single list mode datasets, with one list each.
-
If you require several related lists, then you create only one dataset, but in multiple list mode, with all lists in the same dataset. For example for three related lists, you create one multiple list mode dataset with three lists.
-
If you require a mix of several related and unrelated lists, then you create a separate dataset for each group of related lists, and in each dataset those lists that are related to each other. For example for six lists, of which lists 1 and 2 are related to each other and lists 3, 4 and 5 are related to each other too, and list 6 is not related to any other list, you create three datasets. In the first dataset (in multiple list mode) you create the two lists 1 and 2, in the second dataset (also in multiple list mode) the three lists 3, 4 and 5 and in the third dataset (which is in single list mode) the single list 6.
But what makes two lists "related"?
When trying to decide if two of your subscriber lists are in fact related (and should therefore be created in the same dataset) or not, consider the subscriber page user interface (UI) that LISTSERV Maestro presents to the end-user:
For each dataset, LISTSERV Maestro automatically creates a UI with subscriber pages through which the end-user can subscribe to your lists, or unsubscribe, or otherwise edit his subscription profile. Such a UI is created separately for every dataset, with separate logins, and the UI's of different datasets are not connected to each other and the login for one UI cannot be used for another. So as far as the end-user is concerned, each dataset gets a totally separate UI that has nothing to do with any of the other datasets.
But inside of the UI of a specific dataset, the end-user will be able to see all (public) subscriber lists that are defined in that dataset. The end-user sees which lists he is currently subscribed to and which not, and can then subscribe to or unsubscribe from any of these lists - all with a single login. He does however not see any of the lists of the other datasets.
So if you want this behavior for two of your lists that the end-user can see both lists in the same UI, then you should consider these two lists as related and put them into the same dataset. Otherwise they are not related and should be put into separate datasets.
Examples:
Example 1: A hardware producing company who wants to have two newsletters, one targeted to its customers and another to
its suppliers. So we need two subscriber lists, one for each newsletter. In such a situation, it would probably be undesirable
if the customers who subscribe to the customer newsletter would also see the supplier newsletter in the
subscription UI, and vice versa. So these two subscriber lists would not be related and would therefore
be created in two separate datasets.
Later, the company decides to create a third newsletter for "best deals" that is also targeted to its customers.
Here it would be desirable that all subscribers of the customer newsletter would also see the new "best deals"
newsletter in their UI, and vice versa, as it is likely that the subscribers of the one newsletter would also
be interested in the other. So the customer newsletter and the "best deals" newsletter are related, which means
that the new "best deals" newsletter should be created in the same dataset that already contains the
customer newsletter.
Example 2: A university with several departments. Each department has several newsletters and other subscriber lists
that it uses to keep in contact with its current students and alumni. It is fine if a member or student of a
department who uses the UI of that department sees all the newsletters and subscriber lists of that department in
the same UI, but he should not see the lists of the other departments in this UI.
The solution is a separate dataset for each department, where then each department creates its own newsletters
and subscriber lists (all of which are defined as "related") in its own department specific dataset.