Section 13
Tracking and Recipient Profiles

Among the four tracking types, LISTSERV Maestro offers two types that involve recipient profiles: personal tracking and anonymous tracking. With personal tracking, each recipient is identified uniquely by a recipient ID that can be traced back to the data associated with this recipient (the recipient's profile). With anonymous tracking, each recipient is identified with an anonymous ID that cannot be traced back to the actual recipient data, but only to an anonymous profile. This is usually a subset of the actual recipient data that contains only anonymous data, no personal data like name or address is included.

When anonymous tracking is chosen, LISTSERV Maestro always creates and stores an anonymous profile for each recipient. For higher efficiency, if several recipients have the same anonymous profile, only one profile entry is created and this is shared by all of the recipients. The anonymous ID is then included in the tracking data maps to one of these anonymous profiles stored in LISTSERV Maestro.

The storage of personal profiles is very similar. For each recipient, a profile entry with this recipient's data is created. Usually there will be one entry for each recipient, but should several recipients happen to have exactly the same profile, only one profile entry will be generated and this will be shared by those recipients. Both anonymous and personal profiles are stored in the database to which the Maestro User Interface is connected (either the internal database or the external database, see also Section 9 Database Connection).

Anonymous profiles always need to be created and stored by LISTSERV Maestro, because they simply do not exist anywhere else. However, with personal profiles, this is usually different. The personal profile of a recipient contains the full set of data associated with that recipient. It maps to one row in the uploaded recipients file (in CSV-format), or to one row in the result set that was selected from the database. Each column in the row constitutes one field of the profile data, where the column headers from the uploaded file or the database table are the labels of these fields.

For personal tracking, the recipient data must also contain one column with a unique recipient ID - a column with values that can be used to uniquely identify the recipient from all other recipients.

More often than not, the recipient data already comes from some type of database. Either it was exported from the database and then uploaded as a recipients file, or the Maestro User Interface selected it directly from the database. In both cases, there is already a table in a database that contains the full recipients' profiles, including the unique recipients' IDs. In some cases, when the Maestro User Interface is used with an external database, and that database happens to be the same database as the one where the recipients originally came from (either by an export or an explicit select in the Maestro User Interface), the original recipient profiles exist in the same database where the Maestro User Interface will store them. So, under certain circumstances, it seems redundant to allow the Maestro User Interface store personal profile information in its database, when the same information already exists in another database (or even in the same database, if the database is shared as explained above).

To avoid this circumstance, the Maestro User Interface offers an option to switch off the storing of personal profiles in the database to which the Maestro User Interface is connected. To do this, edit the following file:

\Program Files\L-Soft\Application Server\lui\lui.ini

Add this entry:

CreatePersonalProfileTables=false

If the entry is set to "false", then the Maestro User Interface will not write personal profiles into the database to which it is connected. If it is set to "true" (or missing, which is the default after installation), then the Maestro User Interface will create personal profiles. Restart the Maestro User Interface after the change to make the entries effective.

The actual difference between permitting and not permitting the Maestro User Interface to create personal profiles is that if the Maestro User Interface creates personal profiles, then the match between the recipient ID that is collected with the tracking event and the corresponding recipient (that recipient's profile) can be made directly in the Maestro User Interface.

If the report type "Details Report" is run, the resulting table will have one entry for each recipient for which one of the events selected was registered. Optionally, with a count that details the amount of these events that were registered. One row per recipient is generated, including the recipient's profile as values in the row, as shown below:

The "count" column is optional.

With this table, it is immediately apparent which recipients reacted to the message (and how often, if the "count" column is included), as the details of each recipient are included in the form of a profile.

If the version of this table without the "count" column is chosen, the same table can also be used, without any modifications, to upload the recipients list for another job (for example to send a follow-up mail to all recipients that reacted to the previous mail). The data is already in the CSV-format that the Maestro User Interface understands, and since all recipient profiles are already in the Maestro User Interface database, the profiles will not be recreated, but instead the existing profiles are reused.

In contrast, if the Maestro User Interface does not create personal profiles, then it is necessary to make the match between the recipient IDs and the actual recipients behind them with a tool outside of LISTSERV Maestro, because the Maestro User Interface does not contain the information to do so itself. To help make this match, the Maestro User Interface will output a table with the recipient IDs in question when the "Details Report" is run. The result is one row per recipient with the recipient's ID as the value in the row, as shown below:

Again, the column "count" is optional.

Here, only the IDs of the recipients that reacted (and how often, if the "count" column was included) are apparent, but any further details regarding the recipients are not. This data would have to be brought into context with the original source of the recipients, by whatever reporting or analysis tool preferred to discover more details about the users.

The type of handling of the personal profiles depends on the requirements of the feedback desired:

• If immediate and simple-to-get feedback is desired about which recipients trigger the events, and there is not much concern about saving storage space (for example keeping possible redundant versions of the profiles in different databases - or even the same database), then choose the option of permitting the Maestro User Interface to create personal profile entries (set the INI-file entry to "true" or leave it out, which is the default after installation).
• If there is not much concern about receiving feedback on the identify of the recipients quickly, because the tracking information will be imported into some other tool or database anyway, and keeping redundant sets of data is not desired, then choose the option of not storing profile entries in the Maestro User Interface database (set the INI-file entry to "false").

The choice between allowing and not allowing the Maestro User Interface to store personal profiles in its own database is really an advanced administration feature. If there is any concern over this choice, keep the default of letting the Maestro User Interface store the profiles. Only change this setting after thoughtful consideration of the requirements and the impact this will have.