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 such as 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 and 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 Maestro System database. See Section 10
The System Database for additional information.
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 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 (possibly by using a database backed target group). In both cases, there is already a table in a database that contains the full recipient profiles, including the unique recipient IDs. In some cases, when the Maestro User Interface is used with an external system database, and that database happens to be the same database as the one where the recipients originally came from, the original recipient profiles exist in the same database where the Maestro User Interface will store them. Under certain circumstances, therefore, 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 Maestro System Database. To do this, edit the following file:
If the entry is set to false, then the Maestro User Interface will not write personal profiles into its system database. If it is set to
true (or missing, which is the
default after installation) the Maestro User Interface will create personal profiles.
Restart the Maestro User Interface after the change to make the entry 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.
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.
Again, the column Count is optional.
Here, only the ID’s 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 choice between allowing and not allowing the Maestro User Interface to store personal profiles in the system database is really an advanced administration feature. If there is any concern about 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.
