E-mail activities

E-mail activities allow you to deliver news and promotions to customers using e-mail. This allows you to reach customers who may not have visited your site in some time, or to keep regular customers up to date regarding upcoming events or products. Optionally, you may associate an e-mail activity with a campaign, which helps organize the gathered statistics into more meaningful reports.

E-mail activities are created using the e-mail activity dialog in the WebSphere Commerce Accelerator. When creating an e-mail activity, you must select the template upon which it is based. This template can be defined either prior to creating the e-mail activity, or as part of the e-mail activity creation.

E-mail activities can be either pending or delivered. They are considered pending while being created, and while awaiting delivery. Thereafter, they are considered delivered.

E-mail activities send a single dynamic e-mail message to multiple recipients. An activity is not sent as a single e-mail with multiple target addresses, but rather as an e-mail sent multiple times, once each to every selected target e-mail address. The individual e-mail generation allows the system to target the e-mail content for each user. This includes simple elements like the customer's name, but also e-mail body text, and promotional content. The individual generation also eliminates the ability of a recipient to see the e-mail addresses of the other recipients, and should reduce privacy concerns.

In an extended site model, an extended store's e-mail activity list displays the e-mail activities created in the extended store and its asset stores. However, the e-mail activities created in the asset stores are read only. For example, if an e-mail activity named EA1 is created in the asset store, it is listed in the extended store's e-mail activity list. However, when a user selects the EA1 and clicks Change or Delete, the user receives an alert message that the action is not allowed.

Prior to e-mail activity creation, your site administrator must configure the e-mail accounts used by the e-mail activity system. E-mail configuration defines the required information about the mail servers, the time that e-mail activities should be sent, the desired soft bounce retry policy, and more.

Whenever the information defined in the e-mail configuration is needed, the following rules apply:

1. E-mail can be configured in both an asset store and a child store.
2. When an e-mail activity is created in a store, the following logic determines which store's e-mail configuration is used:
   1. If there is an e-mail configuration for the store in which the e-mail activity is created, that store's e-mail configuration is used.
   2. If there is no e-mail configuration for the store in which the e-mail activity is created, the system uses the e-mail configuration defined in the store's asset stores according to the following precedence
      1. If there is only one asset store which has e-mail configured, the configuration of that asset store is used.
      2. If multiple asset stores have e-mail configured, the closest asset store, according to the relationship defined in the database is used. Specifically, the store that has the smallest value in the SEQUENCE column of the STOREREL table. For example, consider an e-mail activity being created in an extended store that has an inherited relationship with asset store A and a direct relationship with asset store B. If both A and B have e-mail configured, the e-mail activity created in the extended store will use the e-mail configuration from store B.
      3. If there is no e-mail configuration defined in any related asset stores, the user is not allowed to create an e-mail activity.

When your Site Administrator configures e-mail activities, one of the settings is a default reply-to e-mail address. That is, an e-mail activity uses this address to populate the Reply-to e-mail address field in the E-mail activity dialog. Some sites use specific reply-to e-mail addresses for their e-mail activities so that the incoming mail is appropriately filtered to the person responsible for supporting the activity, or the parent campaign.

As with any kind of e-mail, delivery of e-mail sent as part of an e-mail activity is subject to failure for a number of reasons. Failure to deliver an e-mail results in what is called a bounce-back. A bounce-back is simply a case where an out-going e-mail fails to arrive at its destination, and ends up in the sender's inbox instead. Bounce-backs fall into two categories, hard and soft. A hard bounce-back typically indicates that the e-mail address to which you sent the message is invalid. E-mails re-sent to an address that has resulted in a hard bounce-back will always result in a hard bounce-back. Conversely, a soft bounce-back is caused by some event or situation that is typically considered temporary. For example, if an e-mail cannot be accepted due to a restriction on the size of a customer's inbox, this is considered a soft bounce-back. Resending this message to this e-mail address at a later time may result in a successful delivery. When you create an e-mail activity, you have the option of specifying how WebSphere Commerce should handle soft bounce-backs. You have the option of having the message re-sent, and if so, how long after the initial send date to wait before re-sending.

Target customers receive an e-mail if they meet both of the following criteria.

1. The customer qualifies as a member of the target customer segment. The qualifying customers for a customer segment include both the customers who belong to the store in which the e-mail activity is created, and the customers who belong to all of its extended stores with the store relation type com.ibm.commerce.segmentation. For example: A customer segment (CS1) is created in an asset store. The CS1 is set to target all customers. An e-mail activity is created in the same asset store. The list of target customers from the customer segment evaluation for the e-mail activity includes the customers registered in the asset store, and any of the extended stores. Conversely, if a second e-mail activity is created in an extended store, the customers from the customer segment evaluation for the second e-mail activity include only the customers registered in the extended store, and any store to which it might be a parent.
2. The customer has opted-in to receive e-mails from your store. A customer may opt-in for a particular store such as a single extended site, or a customer may also opt-in on a site-wide basis. Whether the customer prefers to receive promotional e-mail or not is saved in the EMLUSRRECV table.

If a customer has specified a preference regarding promotional e-mails for a store in which an e-mail activity is created, that preference is respected. If there is no stated preference for the store, the customer's site-wide preference is respected. However, if there is neither preference specified by the customer, the customer is considered to have opted-out by default.

Care should be taken in any endeavor to mass e-mail customers. There is growing concern, and in some places, laws forming, around exactly what is allowable depending on the level of consent, whether there is no consent, implied consent, or full consent. Any customer e-mail activities should ensure compliance with the latest developments in this area.