Table of Contents Previous Next Index

Section 2 Data Administration in LISTSERV Maestro

Section 2 Data Administration in LISTSERV Maestro
The data administrator account can simplify and streamline the use of recipient data and databases for email jobs to the point where users do not need to know anything about how and where data is stored in order to define recipients for a mailing. This can be done in several ways. LISTSERV Maestro can be set up to collect and store recipient data using its own interface. Once configured, it is not necessary to interact directly with the database within the DBMS. Recipient lists can be created from this information for users to employ when sending email jobs.
LISTSERV Maestro can also use an existing external database to select recipients for email jobs. The collecting and storing of recipient data takes place independently of LISTSERV Maestro. To utilize this method of selecting recipients requires a working knowledge of the DBMS involved, as well as knowledge of how the data is organized and how to query the database. A web form or other means to gather recipient data and populate the database is also necessary. This may entail HTML coding and scripting, depending on the individual needs of each organization.
Once a source for collecting recipients and recipient data is established and connected to LISTSERV Maestro, end users need a simple means of selecting recipients and creating personalized messages. The data administrator can build and save reusable and parameterized queries within LISTSERV Maestro; these reusable queries are called recipients target groups. End users can then use these target groups to select the recipients for their jobs from a variety of places including external databases, internal hosted lists, uploaded text files and more. The data administrator builds the recipient target groups by writing SQL statements to retrieve data from a data source. The data administrator also designs the methods end users employ to select the data (in a series of check boxes, drop-down menus, or text boxes).
There are many advantages to using recipient target groups.
Parameters can be inserted into recipient target groups so that end users have some control over what recipients are retrieved from the database for each job. Using parameters also reduces the number of individual SQL statements that need to be written for jobs.
2.1 Role of the Data Administrator
In order to assume effectively the role of a data administrator in LISTSERV Maestro, it is necessary to have access to, and information about, the systems involved. It is also helpful to understand the types of recipient data being collected and how it may be used in email jobs. All data administrators need is a LISTSERV Maestro user account with the administer target group and hosted recipient data option selected. The LISTSERV Maestro administrator can create this type of account. For more information, see the Administrator’s Manual for LISTSERV Maestro 2.1.
2.2 External Database Requirements
Data administrators who set up connections with an external database and send queries through LISTSERV Maestro or through LISTSERV in order to retrieve recipients need:
To understand how the institution’s data is stored and organized, including table names and relationships as well as column types and names. This impacts the ability to write SQL statements and parameters within SQL statements to retrieve specific data.
To know the type of database and specific name of the database used.
This determines the database plugin that LISTSERV Maestro uses to communicate with the specific type of database, for example IBM DB2 or MySQL. For more information on database plugins, see Section 5.2 Registering a Database Plugin in the LISTSERV Maestro Administrator’s Manual.
Access to the database user account that is set up to work directly with LISTSERV Maestro including the username and password for the account.
Tip: For more information on preparing specific databases for use with LISTSERV Maestro, see the Administrator’s Manual for LISTSERV Maestro 2.1.
Name of the Email column.
Name of the Name column (this is optional).
Being familiar with Section 15.2 Creating and Managing Drop-In Content Elements and Section 16 Advanced Use of System Drop-Ins in the LISTSERV Maestro User's Manual can also be helpful to data administrators. The concepts used in defining and creating drop-in elements are very similar to defining and creating parameters in SQL statements. Both use special tags to set the name of the element or parameter off from the rest of the text. Tags for drop-ins and parameters follow very similar rules.
2.3 Hosted Data Requirements
2.3.1 Hosted Data Requirements
The data administrator’s role in collecting recipient data hosted within LISTSERV Maestro is to establish the types of data collected and design the way this information is gathered. The data administrator also creates and designs mailing lists used to send email messages to recipients.
LISTSERV Maestro takes the hard work out of creating a dataset and lists, but it cannot do the planning. Before creating a dataset and lists, the data administrator needs to think about the answers to these questions:
What data will the subscribers need to provide so that the mailings can be precisely targeted and customized? What data will they be willing to provide? What data will need to be collected for all members, and what data are needed only for particular lists?
Will subscribers be allowed to manage their own subscriptions and subscribe and unsubscribe themselves, or will only the database administrator have access to the membership data?
For each data item to be collected (for the dataset or the list) the data administrator needs to think about the answers to these questions:
What type is it? (Text, Number, Boolean, Single Select, Multiple Select)
If Single Select or Multiple Select, what are the possible selections?
Is it optional or mandatory? If optional, should the subscriber be able to enter and change it? If not, should it be shown to the subscriber as a read-only or hidden field?
Are there any legal requirements associated with the kind of data to be collected? That is, are they subject to various financial, health, and other privacy laws of the country or state where the data will be stored as well as where the subscribers themselves are located (for example HIPAA, GLB Act, European Commission’s Directive on Data Protection, and so on)? If so, does the facility meet the data protection requirements? If it does not, reconsider the data to be collected or upgrade the facility to meet legal requirements.
It is important to think about the data that will be collected before creating the dataset. Careful dataset design includes consideration of ease of creating target groups as well as making it easy for subscribers to enter and maintain their data. The dataset should contain all data fields that are shared by multiple lists, so that the subscriber does not have to enter or update the same information in several places. Data fields that are specific to a single list should be in that list. Careful consideration should be given to limiting the number of data fields that the subscriber must enter: subscribers faced with several pages worth of data entry fields may decide that they are not that interested in subscribing after all.
Important: From the technical point of view, one choice that must be decided before creating the dataset is whether there will ever be a need to support traditional LISTSERV lists. LISTSERV lists currently have two restrictions: there must be at least one name field, and there cannot be any selection menus in the base dataset or in the list data for the LISTSERV list.