Using WhatCounts Publicaster Edition To Send
Transactional Emails
1 DEFINITION
Transactional email by definition is any message in which the primary purpose “facilitates an already
agreed-upon transaction or updates a customer about an ongoing transaction.” If the message contains
only transactional or relationship content, then its primary purpose is to facilitate a relationship
established by the transaction. Because of this distinction, transactional email is exempt from most
provisions of the CAN-SPAM Act. Transactional email includes any email triggered by a user’s interaction
with a web application, including: signups, password changes, subscription renewal or expiration
notices, notifications, friend or follower requests etc. These emails typically contain information a user
wants or needs. There is no limit to the number of transactional emails one could define.
2 SHOULD TRANSACTIONAL EMAILS BE SENT THROUGH AN EMAIL SERVICE
PROVIDER (ESP)?
It’s true that almost every website, CRM and e-Commerce product have support for sending
transactional emails, and in most cases this is out-of-the-box functionality. So why spend extra time and
send them through an ESP?
1. Tracking. Using an (ESP) for transactional emails allows you to view reporting on all aspects of
your transactional messages just like you have for marketing messages. Opens, clicks,
engagement -- any metric that is recorded by your ESP for marketing messages is available for
transactional messages.
2. Everything in one place: templates can be modified by people who know how to design
templates using the same platform tools they are used to using for editing. The template
content is not hard coded in some proprietary developer code or platform that only a
programmer knows how to access. A transactional email can be just as effective, or even more
so, than a strictly commercial or marketing email.
3. Testing: Any tools provided by your ESP for testing are available for use with your transactional
messages.
4. Same IP Infrastructure: Optimize your delivery by sending email messages over the same IP
addresses that you use to send your marketing messages. Most ESPs will also handle all your
bounce processing for your transactional messages automatically; if your ESP doesn’t, you may
want to have a conversation with them and ask, “Why not?”
3 ARE TRANSACTIONAL EMAILS SUPPORTED BY WHATCOUNTS PUBLICASTER
EDITION?
Yes, transactional emails are fully supported by WhatCounts Publicaster Edition and do not require an
extensive amount of work to setup. Once prepared, many aspects of the transactional email campaign
can be modified by anyone with access to the WhatCounts Publicaster Edition platform and will not
necessarily require development time from a programmer.
4 HOW DO WE SETUP A TRANSACTIONAL EMAIL IN WHATCOUNTS
PUBLICASTER EDITION?
The following instructions can be used to demonstrate how one might go about setting up a
transactional message in WhatCounts Publicaster Edition.
4.1 DEFINE WHAT TRANSACTIONAL MESSAGES YOU WANT TO SEND
Start by determining what message you want to start sending. Create a list of all the different elements
in each message that are dynamic, i.e. that would change from recipient to recipient each time they
receive this email.
4.2 SET UP A SUBACCOUNT DEDICATED TO TRANSACTIONAL EMAILS.
We ask that all transactional emails be sent out of a dedicated account. We do this for a couple of
reasons.
1. Given that transactional messages are not promotional, they are not subject to CAN-SPAM
regulations. Therefore, we can disable the requirement that these messages must contain a
working opt out link because you don’t want your subscribers to opt out of transactional
messages and potentially miss future messages you send to them that they are expecting.
2. You want to send transactional messages to any user regardless of whether they are signed up
in your main marketing list or not, and you want to be able to send to them even if they have
previously opted out of your marketing emails. By setting up a dedicated sub account for these
messages, the subscribers are physically separate, meaning opt outs and unsubscribes in your
main account will not affect the ability of these subscribers to receive transactional messages.
4.3
MAILING LIST SETUP
Create one or more new mailing lists in your transactional account. The first decision to make is whether
you need to create multiple lists, one for each transactional message template, or if you can use a single
list with multiple attributes. There isn’t necessarily a right or wrong way to answer this question. The
mailing list is used as a holding ground for the subscriber’s data so it can be inserted into the email
message via personalization variables.
If, for example, one of my transactional emails was a ‘Password Reset’ email that is sent to website users
when they can’t remember their passwords, the dynamic fields I might wish to include could look
something like this:
Here we’ve defined three custom fields: First name, the current date the action was requested, and a
space for the reset password URL for the user to click.
Repeat this process of creating lists and/or adding custom fields to a single list for each dynamic field in
each transactional email you wish to set up.
4.4
EMAIL CREATIVES
The next step is to define the email creative template for each transactional message you wish to send.
This is done in the Creative Manager and is performed just like you would create any other email
message you send in Publicaster. Copy or write the necessary HTML template code in the editor and
substitute in the dynamic fields using personalization snippets. Using our reset password example, our
email template might look like the following:
Here you can see that we’ve substituted the dynamic portions of the email with personalization snippets
that will pull content from the mailing list we created in 4.3. The password reset link has also been
configured to use a snippet for the hyperlink.
Continue editing the HTML, Text & Mobile versions of your template until everything in the email is the
way that it needs to be. Repeat these steps for each different transactional email that you wish to
configure.
4.5
PUTTING IT ALL TOGETHER
Once you’ve defined the different types of transactional messages you wish to send, created the mailing
list to store the personalization variables and created the email templates with personalization
variables, it’s time to put this all together, to be able to associate the subscriber being added to a list
and the sending of the email template. In WhatCounts Publicaster Edition, the way this is accomplished
is through Opt-In Forms. Opt-In Forms are the mechanism that allows a user to be added to a list and
trigger an immediate one-time email to that subscriber that is both track-able and personalize-able.
Opt-In Forms are used behind-the-scenes only. The end-user / recipient will never see or interact with
the actual Opt-In Form. Instead, we use HTTP POST in order to send the necessary data elements to the
unique Opt-In Form URL for that form (which means the data is sent into WhatCounts Publicaster
Edition, as well). Before we dig into those details let’s look at setting up the Opt-In Form.
4.6 OPT-IN FORMS
Creating an Opt-In Form in WhatCounts Publicaster Edition will walk you through a short wizard, asking
you for various pieces of information along the way. The first important step is to make sure you
indicate on Step 1 that this form is a “Notified Single Opt-in” form. This selection is critical because this
is what allows you to configure, and WhatCounts Publicaster Edition to ultimately send, an email to that
user after the data has been received.
On Step 2 you’ll be asked to select the list to which the user should be added. This is the list that you
created previously in Section 4.3. In this case, when we’re working with transactional emails, the list is
simply a place to store the data for the subscriber, so it can be inserted into the email for
personalization purposes. Additionally on Step 2 you are asked to choose from a selection of redirection
options. Normally if the user is filling out a physical form this is where the user would be redirected
after the form is submitted. For the purposes of a transactional email where there is no direct
interaction with the form by the user, choose “Transactional Email, No Redirect Required” from the
drop-down menu.
Lastly on Step 2, choose the confirmation email to send to the user. This is the email creative that we
designed for this transactional email in Section 4.4.
On Step 3 of the Opt-In Form Builder you’ll be asked to map all the fields from the list that should be
included on the form. Choose all the fields from the list that you created that are necessary for
personalization in the email creative. None of the selections on Step 3 are essential for Transactional
Emails other than the “Included” checkbox on the left of each row. This selection tells the Opt-In Form
processor what fields are expected for a form and how the fields from the form map to fields in the
mailing list.
When all the fields have been filled in with values on this screen, press the ‘Finished’ button, and
proceed to the final page of the wizard. The final page shows the sample HTML code for this form.
Normally you would take this and make some cosmetic changes and paste it to a page on your website.
But since this is for a transactional email, we’re interested instead in the information shown on the right,
in the “Integration Details” section. Here we see two important pieces of information:
1. POST URL – This is a unique URL that identifies the account/form that was just built.
2. Data Field Mappings – This section shows all the fields that were just mapped on Step 3, and it
shows what the name those fields should be called in the form post.
Here we see that the field “FirstName” that we included on the form is named field6. So when
the form data is submitted it will be submitted as “field6” and that will map the value in that
field to the FirstName field in the list.
4.7
BUILDING AN INLINE FORM POST
As mentioned previously, the way that the email message is triggered to the recipient is via a HTTP POST
to the Opt-In Form Post URL that was previously discussed. Every modern day programming language
supports the ability to perform an inline HTTP post. Included below are some links to show examples of
performing such posts in various modern day programming languages:
Java: http://www.mkyong.com/java/how-to-send-http-request-getpost-in-java/
C#: http://stackoverflow.com/questions/5401501/how-to-post-data-to-specific-url-using-webclient-in-csharp
VB.Net: http://stackoverflow.com/questions/8222092/sending-http-post-with-system-net-webclient
PHP: http://www.php.net/manual/en/function.http-post-fields.php
Python: http://stackoverflow.com/questions/8061280/how-to-perform-a-http-post-directly-in-python
Ruby: http://stackoverflow.com/questions/13152264/sending-http-post-request-in-ruby-by-nethttp
JavaScript: http://stackoverflow.com/questions/133925/javascript-post-request-like-a-form-submit
This is not a definitive list of links, but we hope it services as a reference to support the notion that this
programming is easily doable in many different programming languages, and to illustrate that this
feature isn’t limited to use by a certain subset of technologies.
When the data is posted to the custom HTTP POST URL, it must be formatted just as if it was an HTML
form that was being submitted. This includes ensuring the POST request has the correct MIME type, and
that the data is formatted and encoded correctly as name/value pairs. More information about HTTP
POST data can be found here: http://en.wikipedia.org/wiki/POST_%28HTTP%29#Posting_data
You can even test your configuration right from within the platform, using the Opt-In Form preview
feature. Here you can manually enter in sample data and submit the form to see what the end result
email will look like. If this has been done correctly, you’ll be well on your way to sending real-time
personalize-able, trackable transactional messages in no time at all.
5 FREQUENTLY ASKED QUESTIONS.
Q: Do I need to implement the WhatCounts Publicaster Edition API to send transactional emails through
Publicaster?
A: No. Instead of using the API, this feature is implemented using WhatCounts Publicaster Edition Opt-In
Forms. WhatCounts Publicaster Edition Opt-In Forms already offer all the capabilities required to
programmatically implement and support transactional emails so additional, duplicate technology has
not been added to the API to support this process – nor is it necessary.
Q: Are transactional emails sent via WhatCounts Publicaster Edition deployed in real-time?
A: Yes, these emails are sent in real time.
Q: Are Publicaster Transactional Emails personalize-able and trackable?
A: Yes, they are trackable. Any tracking and reporting feature that can be applied to a marketing
message sent via WhatCounts Publicaster Edition is applied to a transactional email as well.
Q: Are there any limits to the number of transactional email message campaigns that can be created or
limit on the number of emails they can send?
A: No, there are no limits at this time. Each email sent counts towards your monthly/annual allotment
of allowed emails.
Q: Does the Opt-In POST URL support https://?
A: WhatCounts Publicaster Edition maintains dozens of different click-through URLs. Not all of these
URLs support https://. However, if this is a feature you require your Strategic Account Manager /
Technical Account Manager can provide you with necessary instructions for using https:// with your
transactional emails.
Q: Does the HTTP POST require any type of authentication?
A: No, each POST URL is unique and the query string of the URL includes all the information necessary to
identify a specific account and Opt-In Form.
Q: Do I need to include working Opt-Out links in my transactional email creatives?
A: No. Because these emails are transactional and not marketing related they do not fall under CANSPAM compliance. It will actually work against you to include Opt-Out links in transactional emails
because this could prevent the user from receiving other additional messages in the future.
Q: What about the physical mailing address?
A: As with the Opt-Out link, including a physical mailing address is not necessary, because the message is
not required to be CAN-SPAM compliant. If you have concerns about the Canadian Anti-Spam Law
(CASL), please contact our delivery team at delivery@whatcounts.com.
Q: Can WhatCounts Publicaster Edition send transactional messages to a batch of subscribers on a set
schedule instead of one-at-a-time to individual subscribers?
A: Yes, but the implementation details will differ from what is laid out in this document. If you do not
wish to send the emails in real-time and instead would like to send the emails in bulk at set intervals
throughout the day, then you would follow all the same steps laid out above with the exception of
creating an Opt-In Form. Instead of using an Opt-In Form, you would create a segmentation in the
segmentation manager to somehow target the subscribers who should receive the specified email, and
then create a Time-based Auto-Response Campaign to check for new subscribers to receive that email at
specific frequencies. This approach requires that you use some method to import the subscribers in
bulk, which may include some work implementing methods of our API.
Q: Couldn’t you just use a time-based Auto-Response Campaign to send all transactional messages? Is
the Opt-In Form method described here really necessary? What are the pros and cons of each method?
A: Yes, you could use a time-based Auto-Response-Campaign (ARC) to send a transactional message
instead of using the Opt-In Form approach laid out in this document. However the solution in this
document that describes how to perform this functionality has a number of advantages over using a
time-based ARC. Namely:
1. The emails are sent immediately and there is no delay. The minimum execution schedule
for a time-based ARC is 15 minutes.
2. The Opt-In Form approach handles adding the user to the list or updating his or her existing
data in the list. There is no additional work that must be performed to have the user added
to a list.
3. By default, time-based auto response campaigns will not send the same email to the same
subscriber twice, whereas the Opt-In Form solution doesn’t care how many times the user
has received the specified email. This makes it easier to implement campaigns like order /
shipping confirmation, password reminders, etc., that can happen over and over repeatedly
for the same subscriber.
4. Using the Opt-In Form method described in this document, you’ll find that reporting on your
transactional emails is much easier to digest. With a time-based Auto Response Campaign
each time the schedule executes a new campaign distribution record is created in reporting.
Often, time-based Auto Response Campaigns send to very small numbers of subscribers, if
any at all, and this quickly creates a large amount of distribution reports in reporting. Using
the Opt-In Form approach described in this document, reporting is aggregated into the same
campaign distribution, and that campaign distribution only changes if significant edits are
made to the Opt-In Form details in the wizard. But even then, you are only dealing with a
small number of campaign distributions instead of an enormous number of distributions
generated by a time-base Auto Response Campaign.
5. Time-based auto response campaigns work well for transactional messages that are
processed in bulk, for which time is not of the essence when sending the message. If your
internal systems processed shipping notifications once per day, then it would probably be
more suitable to send that data to WhatCounts Publicaster Edition in one import call and
have a time-based Auto Response Campaign send out that campaign distribution on a set
schedule. This would be opposed to having your automated process iterate through your
data one subscriber at a time sending an HTTP POST to a URL.
Q: How should I structure my email creative / mailing list field definition for an email that
contains a large amount of dynamic data, such as an order confirmation email?
A: For emails that are highly dynamic, we recommend (and have had great success with clients)
that users create only a couple of text fields in their list named body1, body2, body3, bodyX… all
with the max size of 4,000 characters. Then, they send over the pre-formatted HTML content for
each of those fields, using as many fields as necessary to display the preformatted dynamic data.
The email template for these transactional messages often looks just like this:
[~Body1~][~Body2~][~Body3~][~Body4~][~Body5~]...
Q: Do WhatCounts Publicaster Edition Opt-In Forms support your Relational Database Feature?
A: At this time they do not. WhatCounts Publicaster Edition Opt-In Forms can only add data
directly to a mailing list as opposed to a Relational Database data table list.
Q: Do WhatCounts Publicaster Edition Opt-In Forms support mailing lists with Primary Key other
than Email?
A: No. Currently, these forms only support mailing lists with an email primary key.