Transact adds the addresses after it sends an email. After you first set up your database, it doesn't contain any email addresses. This new database is not a permanent collection of contact data. The database updates with information such as contact email addresses, opt-in dates, and other system-generated fields.
The XML file sent to Campaign updates the contact information columns in the XML Submit document, marked as SAVE COLUMN. You can save data to the database and not use it in the template. Alternatively, the fields must exist in the database but not the template.
Database fields in Transact
Database fields store valuable information about your contacts, such as customer email address, postal code, or account number. They can also store data (not used in the message) submitted in the XML Submit document. Campaign uses two types of database fields: system-generated and custom.
System-generated database fields
When you create a shared database in Campaign, your database already contains system-generated field types. They appear first in the database in the List fields table. Campaign requires that you enter system field types.
Note: You can't change the system field types after you save the database.
Custom database fields
Create custom database fields based on your organization's needs, such as First_Name, Last_Name, LAST_PURCHASE_DATE, or CUSTOMER_ID. You can add up to 400 fields by using any combination of field types.
You can add fields to a database associated with an automated message at any time. But you must add the new fields before you submit XML with tags for that field.
Note: Because recipients typically get multiple emails (flight booked, flight soon, gate change, etc, for example) and a row is added to the Transact db for each email, the list cannot be email-keyed.
Attach a seed list to your database to send a copy of all of the emails to members in your seed list. Enable the seed list from the Settings button on the database summary page.
What happens to seed list bounces in Transact
Seed list recipients that bounce during a Transact send are immediately marked as undeliverable. The recipient will cycle through the Bounce Retry procedure and may be copied to the master suppression list if it's set to accept undeliverables. This process reduces blacklisting risk and performance issues associated with Transact sends using seed lists.
Tip: Set up a mailbox that only collects copies of your transactional emails. If you send to one or more individual mailboxes, they may become overloaded, rendering it ineffective. You can also rotate to a new group mailbox once a month to expedite the search for detailed information.
MyCopy for Transact XML and Transact SMTP allows one or more individuals (or an assigned mailbox) to receive a single copy of all emails sent from Transact. This is similar to Blind Carbon Copy (BCC) that is used in email applications.
In traditional email marketing, you use seed lists to receive sample emails to ensure that the formatting is correct and that the messages send at the specified time. You can use seed lists to set up MyCopy for Transact.
Note: This seed list will receive a single copy of all emails that are sent from Transact. Seed lists set up and configured for traditional emails will continue to work as intended. If you have different Automated Messages that require different people to receive copies of the transactional mailings, you must create separate main databases and separate seed lists. You can associate only one seed list to one main database.
Create the seed list
- Create a seed list.
- Add contacts to the seed list.
- Associate the seed list to your Transact database.
How MyCopy works
When you use MyCopy, each address on the seed list records a send for each individual Transact message sent. For example, if your MyCopy seed list contains two contacts, and on a given day you send six messages for a particular transactional message group, Transact reporting shows that there were actually 18 sends. This behavior is normal and applies to any email in which a seed list is applied.
Transact XML supports FCC, domain, prefix, and global- level suppression. You’ll find the FCC, Domain, and prefixes that aren't allowed for your particular organization within the Email blocking section. Go To Settings > Administration > Email blocking.
Transact XML doesn't support organization level suppression
Transact XML only supports global suppression as the design of Transact is to send an email based on some sort of recipient action.
It is up to you to handle your opt-outs and undeliverables by exporting these metrics from your reports, exporting the master suppression list manually or by using the Export list API.
Note: The suppression list is based on opt-outs and undeliverables. If a contact’s email address is undeliverable (or if they mark your email as abuse via their email service provider), Transact adds their email address to a dedicated list of undeliverable and suppressed email addresses (also referred to as an organization master suppression list).
Duplicate contacts within a Transact list
Trying to prevent duplicate contacts is somewhat counterproductive to the purpose of a Transact database. Transact is not intended to be used for non-transactional based communication. As such, each entry in your database is a receipt of that particular transaction, not a contact. If a contact makes multiple transactions, you'll want the records for each instance saved within your Transact database.
Send Transact messages from one or more domains
Transact supports multiple custom domains within the same Transact organization. If you support multiple brands and domains, you can manage and send all of your Transact messages from one Transact organization, regardless of the number of custom domains.
Provision the custom domains in Organization settings > Domain settings.
To send Transact messages from multiple custom domains in the same organization, you must assign the correct custom domain to the appropriate Transact database. You can set this value in Database settings.
Transact sends the message from the custom domain specified in the database assigned to the transactional automated message group (also called Transact campaign). If a custom domain is not specified in the database, then Transact sends the message from the organization default domain, specified in Domain settings.
You can add Personalization tags from the fields that are created in your database. However, you can also personalize your email template without having those fields in your database, by adding Personalization tags to the body of an email template. They correspond to Personalization tags defined in the database fields in Campaign or in the Transact XML Submit document.
Personalization in the XML Submit Document
You can also pass the content for Personalization tags in the XML Submit document. However, you must include the content as fields in the template if you use them to substitute values from XML tags. In addition, if you want to save the values for these fields, you must also include them in the database fields.
In the example below, the user defined the personalization tag %%WORLDAIR_CONFIRMATION_BODY%%
The personalization tag is the only content in this email template. The content for the tag is passed in the XML Submit document in the TAG_NAME / VALUE element as HTML in a CDATA section. The HTML can include the entire email body. Information in the submitted XML document must correspond to the template field (personalization) tags, which are shown in the following XML Submit document example:
<VALUE><![CDATA[This is the <b>body</b> of the email.]]></VALUE>
Separate marketing and transactional organizations
We recommend keeping marketing and transactional organizations separate. Transact sends typically generate high engagement rates which can skew the reporting if marketing and transactional sends are sent from the same organization. Transact is a programmatic environment where things are rarely changed. Keeping marketing and transactional organizations separate is preferred because it reduces the chances of someone changing something that could cause Transact to stop functioning properly. Separate IP addresses should be maintained. Marketing emails with a higher volume could negatively impact deliverability of the transactional mailings.