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.
· Using recipient data stored in a database can save time and system resources.
· The database can be continually updated until the time the job is sent, ensuring that the most current data is used for the job.
· Recipient target groups are shared among group members and can be reused for multiple jobs.
· 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.
· The data administrator does not need to be involved with any other parts of email jobs.
· Specific recipient target groups can be removed from use without deleting them. They can be reinstated whenever desired.
· Recipient target groups can be organized into categories for easy recognition.
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.
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.
· Working knowledge of SQL.
· In the case of LISTSERV Maestro accessing an external database:
o
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.
o Access to the database user account that is set up to work directly with LISTSERV Maestro including the username and password for the account.
For more information on preparing specific databases for use with LISTSERV Maestro, see the Administrator’s Manual for LISTSERV Maestro 2.1.
· In the case of LISTSERV accessing the database:
o Database server name, if not the default.
o Name of the Email column.
o Name of the Name column (this is optional).
o Names of any additional columns in the database to be used for mail merging.
Being familiar with Section 5.1 Drop-In Content and Section 11.2 Creating and Managing Drop‑In Content Elements 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.
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:
· How will this dataset be used?
· 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?
· What kinds of target groups will be needed? What questions will the job reports need to be able to answer?
· What types of lists will be needed? Only announcement lists or will there also be a need for discussion lists?
· For announcement lists, will mailings always be sent to all subscribers or will there be a need to target subsets of the lists?
· Will archives be needed for any LISTSERV lists?
· Will auto-deletion of bouncing addresses be needed?
· 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?
· Will the subscriber pages need to be customized or is the “out-of-the-box” look acceptable?
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.