Email Manager - LIST MANAGEMENT

 HOME

Troubleshooting Lists

This section describes some common problems that you may encounter when managing lists, and offers possible solutions.

  1. Too many fields in the recipient database

  2. Orphaned recipients

  3. Excessive Primary Keys

  4. Overwritten data fields

  5. Primary Key misuse

Too Many Fields

The Symptoms

  • You’re mapping a creative variable to a field. The variable is “Zip” and you want to map it to the correct field in EM. You find that there are actually three fields that could be what you’re after: “Zip”, “ZipCode” and “PostalCode”. If you don’t pick the correct one you’ll get no value for the “Zip” variable and you will have to go back and edit the field mapping until you get it right.
  • You’re importing a new list. The file you’re importing contains a column header “Name”. The import wizard suggests many potential fields you might map this column to. The existing fields are: “FirstName”, “First (space) Name”, “Nombre”, etc. The field you select is the field that will be updated for the recipients you’re about to import – if you select the wrong one the old values will be left unchanged and you may be inserting new values for a different field.
  • The Quick Totals reports are showing unexpected results when using Group by 'Field'.
  • List Queries are returning incomplete or no results when using an incorrect field in the field criteria.

Underlying Issues

  • Lax process for importing data into EM. Importing data from many different data sources into EM without mapping common columns to common fields.
  • EM makes it very easy to import data, creating new fields and/or mapping to incorrect fields. The resulting list may be usable for an immediate campaign and the negative effects are not apparent until later.

Addressing the Problem

  • If you are experiencing any of the above symptoms, the damage is already done. There are too many fields in your EM account. They have become ambiguous and therefore useless. The fields should be completely purged by deleting every list in the account. It may be easier to abandon the account altogether and create an empty account that you can migrate to while managing the fields properly from the start.
  • This pitfall is easily avoided by approaching imports with care. Administrators should first plan how data will be introduced into EM, and then train their users on how to execute the plan using tools like the import wizard and drop folders. If users are trained on these tools without an overall plan, they can very easily cause the problems described above. This is especially the case when the users doing the importing are not the users executing the campaigns. Symptoms can go unchecked allowing the issue to compound until the account cannot be salvaged.

Orphaned Recipients

The Symptoms

  • You want to perform a list query for all recipients who received messages but didn’t respond in the last week. Some of the lists used to deploy campaigns in the last week have been deleted so you cannot include them in your list criteria in the query tool. The results of your query are incomplete since not every list was included.
  • You select every list in the query tool using the [Select All] button. Assuming every recipient will be evaluated, you execute a query for recipients who have received messages but haven’t responded in the last week. The query takes very long because of the large list selection and the results are still incomplete.

Underlying Issues

  • There may be the perception that recipient lists are no longer needed after campaign execution and so users may delete them.
  • EM allows for lists to be deleted at any time. It will not raise alerts if the lists were recently used for a campaign or are currently being used for a campaign.
  • If a recipient was on only one list and that list is deleted, the recipient is orphaned and will not be included in query results even if all lists are selected.

Addressing the Problem

  • If you have orphaned recipients there is no way to un-orphan them yourself unless you can import a full and complete list of recipients from an external source. The only option is for Alterian technical support to query the orphaned recipients manually and associate them with a list, effectively un-orphaning them.
  • Users should understand that lists may be the only way to refer to certain recipients in the future, and that they should not delete them, but instead move them into another category for safe keeping.
  • Every account should have a master list that contains every recipient for a given primary key field. When importing using drop folders or the API, you can always specify more than one destination list. If the master list is always included, then recipients will never be orphaned because they will always be associated with the master list. You can execute list queries against your master list instead of using “Select All” which will avoid very slow list queries and will ensure that your results are always complete.

Excessive Primary Keys

The Symptoms

  • When trying to select more than one list in the List Query Tool other lists become unselectable once you have selected a particular list.
  • Duplicate messages being sent when sending a deployment to multiple lists.
  • Complaints from recipients continuing to receive messages after they have unsubscribed.
  • Various data issues involving recipient data being out of date or out of sync.
  • You have just imported a very large file but the destination list is very small. The records appear to have been deduped by a non-unique field such as “First Name” or “City”.

Underlying Issues

  • Lax process for importing data into EM. Importing data from many different sources without choosing a common primary key.
  • EM makes it very easy to create new primary keys or use existing fields as primary keys incorrectly when importing data. The resulting list may be usable for an immediate campaign and the negative effects are not apparent until later. If a field such as “First Name” or “City” is mistakenly chosen as the primary key field, then the file will be deduped by that field reducing the number of records imported.
  • EM allows you to use any existing field as primary key without raising alerts. The untrained user can introduce an excessive amount of primary key fields.

Addressing the Problem

  • If you have excessive primary keys it is very important that you clean up your data immediately before damage is done to your reputation as a sender. Determine which field is supposed to be used as the primary key and delete every list in your account that does not use this field as the primary key. Train any users responsible for importing data to be aware of the correct primary key selection.
  • In some cases you may want to have several primary keys in your account. The users responsible for importing data into EM must know when to use the correct primary key. It is important to understand that recipient's records do not overlap between primary key fields when developing your data process.
  • In some cases you are importing data from many sources, each of which may have a unique identifier that could be used as the primary key. If there is no intent to maintain the recipient lists separately then the recipient email address should be used as the primary key. These kinds of decisions should be made up front as part of the data planning process.

Overwritten Data

The Symptoms

  • You import a recipient file containing segmentation codes specifically for “Deployment A” and execute “Deployment A”. You then import a recipient file containing segmentation codes specifically for “Deployment B” and execute “Deployment B”. After some time you run a quick totals report grouped by segmentation code and the totals for “Deployment A” do not add up whereas the totals for “Deployment B” are too high.

Underlying Issues

  • The field storing the segmentation codes is using the incorrect propagation level. Without proper training, the users responsible for importing data may not be aware of the field propagation options or know how to select the appropriate level.
  • EM defaults to “recipient” level propagation without prompting or confirming so it’s very easy for users to import report-dependent data into fields that will be overwritten on subsequent imports.

Addressing the Problem

  • If your reporting data has been overwritten there is no way to restore it. If you have the original files you can re-import them to overwrite the values with the data for a particular report.
  • Avoid this issue by planning your data process. If you know you will need to persist certain values across many deployments to support your reporting requirements then plan on using the “list” or “list+recipient” propagation levels for those fields.

Primary Key Misuse

The Symptoms

  • List queries such as “recipients who have received more than 1 message in the last week” or “recipients who have responded more than once” always return no results.
  • Complaints from recipients continuing to receive messages after they have unsubscribed.
  • List queries, imports and Quick Totals reports are extremely slow.
  • The EM account database has grown very large and continues to grow.

Underlying Issues

  • Some users when presented with the overwritten data issue or in a misplaced attempt to work around the overwritten data issue will misuse the primary key concept by generating a unique value for every record imported into EM. This forces EM to persist every value for every import and causes EM to create an excessive amount of recipient records, resulting in decreased performance and increased database growth.
  • Without proper training the users responsible for importing data into EM may be confused by the primary key concept. They could make a very poor selection for primary key such as a column containing datetime or GUID values.

Addressing the Problem

  • If an account has been affected by primary key misuse it’s very important to address the issue immediately to avoid damage to your reputation as a sender. In most cases the account is not salvageable and should be migrated to a new account while managing the primary keys properly.
  • This issue can be easily avoided by being knowledgeable of the field propagation levels during the data process planning phase. Being aware of the negative effects should prevent the use of an always-unique primary key solution being employed.
     
© Alterian. All Rights Reserved. | Privacy Policy | Legal Notice