The Tables screen is also used to manage tables used for the platform's Load and Send feature. Load and Send allows you to import "campaign-ready" files containing all the information needed to build and deploy the Campaign (such as personalization fields, and contact information like Email Address). This data is loaded into a special table dedicated specifically to the Load and Send feature, rather than into the regular relational database tables. Tables that are intended for use in a Load and Send Campaign differ slightly from regular relational database tables, as follows:
Table joins, calculated fields, and restricted fields aren't supported.
Certain Data Types aren't supported.
The table MUST have a Unique Identifier defined.
Create a New Load and Send Table To create a new table for use in a Load and Send Campaign:
|
View or Edit a Load and Send Table To view or edit an existing Load and Send table:
|
Create a New Load and Send Field In database terminology, a field (or "column") represents a single type of information that you're storing in your database, such as email addresses or ZIP codes, for example. A Load and Send table consists of one more fields, which can be populated with data received through an import file. Fields can be limited to the type of data that the field will accept. A "ZIP Code" field, for example, should only contain numbers. To create a new field for a Load and Send table:
Note: The "Display Name" and the "Column Name" don't have to match. Column Names can be reused across tables, if for example, you have a situation where different Display Names are desired, but the Column Names should be the same.
The next step is to select the "Data Type" for your new field. The different types allow for proper formatting and handling of data when it is saved into that field. Once a Data Type has been set, it can't be changed, so it's important to know what the field will be used for in order to make the correct choice. As an example, creating a Date/Time field will allow you to use that field for date calculations. Data fields can be formatted for use in Campaigns such as formatting of dates, padding, decimal places, dollar signs, etc.
In addition to the standard options, the platform supports the following "advanced" data types, which are used for more specific purposes within Messaging:
Note: Import performance is enhanced when fields that don’t require indexing are not indexed during the update process. Some fields such as names or parts of the postal address may not require such indexing. Indexing should be disabled only by database experts who have discussed the potential performance impact. Disabling indexing on a field will significantly slow down performance of Campaigns and Filters that use that field.
The "PURL Options" section allows you to set various options if this field is going to be used to generate a Personalized URL, or "PURL." A PURL utilizes data from a user’s record to customize a URL specifically for that recipient. When creating a PURL field, users have the option to select if the PURL will exist at the beginning or the end of the domain (ex. John.company.com or company.com/John). This option allows for the field prefix to be a given domain in order to create a personalized URL to send out to each recipient. This option is available only at field creation time and can't be changed later.
|
View or Edit a Load and Send Field Most information about a field is "locked" and can't be modified once you save that new field. The only editing options available for a field are its "display name" and indexing. To view or edit an existing field within a Load and Send table:
|
Define the Unique Identifier In order to ensure that records in your table are created and updated properly, each table can be set up with a Unique Identifier (also referred to as the "Alternate Key"). The Unique Identifier can be based on a single field, or on a combination of more than one field. Note: A Unique Identifier is required for a Load and Send table. For example, let's say you create a new "Customer" table to store consumer information, and you decide that you want to use a combination of the Customer ID and the Email Address as the two fields that will uniquely identify each customer. You would assign these two fields (in that order) as the Unique Identifier. When you save the table, the system performs several actions. First, the system assigns an "Alternate Key Sequence Number" to both of those fields. In this case, Customer ID would be "1" and Email Address would be "2," since that's the order in which you defined the Unique Identifier. Second, the system creates a new String type field on this table called "ak_<tablename>" that concatenates the Customer ID and Email Address fields. The combination of these two values now serves as the unique value that will identify each consumer. For example: Consumer A: ak_customer = '234567+john.smith@yahoo.com' Consumer B: ak_customer = '112234+jane.doe@gmail.com' Consumer C: ak_customer = '765432+bobjohnson@aol.com' Third, the system creates a new Numeric type field called "pk_<tablename>_id" that stores the "Primary Key ID," or "PKID." The PKID is largely hidden from the platform's end-user, as it's not anything that you would use in a Filter or in personalizing your message content. A new PKID is generated and assigned to each unique Alternate Key. Continuing the above example: Consumer A: ak_customer = '234567+john.smith@yahoo.com' pk_customer_id = '1' Consumer B: ak_customer = '112234+jane.doe@gmail.com' pk_customer_id = '2' Consumer C: ak_customer = '765432+bobjohnson@aol.com' pk_customer_id = '3' Note: The Alternate Key field and the Primary Key ID field are both displayed within the "Inactive Fields" section of the Table detail screen. These fields are marked as "inactive" so that they don't appear within any "views" of this table, such as the list of fields available when selecting a Personalization field, for example. These two layers of identifiers (sometimes called "surrogate IDs") are needed because the primary key on a record can never be changed. However, customers can, and often do, change their email address. The surrogate ID design accommodates the flexibility needed for something like an email address. If Consumer A in the above example gets a new email address, his Alternate Key would change, but his PKID would not. In this manner, you keep the consumer record intact (name, postal address, purchase history, etc.), but are still able to update the email address. Unique Identifiers are not required. If you create a new table, and don't define a Unique Identifier, the system will simply utilize the PKID as the sole unique identifier for this table. In this situation, the system utilizes the PKID as the table's Global Unique Identifier (GUID). The step below describe how to define a Unique Identifier. When performing these steps, please note the following:
To define the Unique Identifier:
|